Skip to content

Transfer Restrictions & Compliance Controls

One of the key benefits of an onchain equity system is that compliance rules can be built into the contracts themselves. In traditional corporate law, transferring stock often requires certain conditions to be met: for example, board approval, a right of first refusal process, or legends on certificates indicating restrictions (such as “This security is not registered under the Securities Act and may not be transferred without appropriate authorization”). CyberCORP smart contracts mirror these requirements in code:

  • Restricted Transfers: By default, a cyberCORP’s share tokens are not freely transferable without the company’s approval. If a shareholder wants to transfer a stock NFT to a new owner, the CyberCertPrinter contract can be configured to require an endorsement (permission) before the transfer is finalized onchain. This works analogous to having an officer sign the back of a paper certificate to approve the transfer. The endorsement itself can be represented by an onchain signature or a specific function call by an authorized party. Until an endorsement is recorded, the token cannot be transferred to a new address, preserving the integrity of the cap table and ensuring compliance with any shareholder agreements or securities laws.

  • Legends and Whitelists: Each CyberCertPrinter can enforce legends – essentially notes or flags on the token that indicate transfer restrictions or required qualifications. For instance, a legend might indicate that the holder must be an accredited investor, or that the token cannot be transferred until a certain date. The contracts support global or per-token restrictions and can include whitelist mechanisms (addresses approved for transfer) or require certain conditions to be met (via hook contracts) before a transfer. These legends appear in the token’s metadata and are taken into account whenever a transfer is attempted. If a transfer violates a legend (say, trying to send a Restricted stock token to an unapproved buyer), the contract will reject the transfer automatically with an error explaining the restriction.

  • WhitelistTransferHook: MetaLeX’s contract library includes a hook that checks both the sender and recipient against a board-managed whitelist. If either address is not approved, the transfer reverts. This makes it easy to enforce investor qualification or KYC requirements entirely onchain.

  • ToggleTransferHook: Another module lets the company flip transferability on or off globally or for specific certificate IDs. When transferability is disabled, the token is non-transferable until the flag is re-enabled, supporting temporary lockups or per-investor restrictions.

  • Onchain Approvals: Company officers or admins (as defined in the cyberCORP’s governance settings) have special privileges in the IssuanceManager and CyberCertPrinter contracts to manage these restrictions. They can endorse transfers, update legends, or globally toggle whether a particular class of shares is transferable. All such actions are logged via events, creating a clear audit trail. This onchain oversight replaces the need for offchain coordination for tasks like updating a cap table or issuing new certificates – the smart contracts ensure that only authorized actions occur, and nothing “slips through the cracks” without proper sign-off.

These hooks are attached to certificate contracts via the IssuanceManager, and company officers can toggle them as needed, providing an onchain analogue to paper legends and transfer restrictions.

In practice, these compliance features mean a cyberCORP can satisfy legal requirements by design. The cap table isn’t just onchain for transparency; it’s also enforcing the rules that real-world lawyers care about. For example, if a share class requires board consent to transfer, the smart contract requires an onchain signature from a board-designated account. If securities laws demand a legend on certain shares, the NFT metadata includes that legend and the contract blocks disallowed trades. This gives regulators, auditors, and the company’s lawyers confidence that the onchain records are not only accurate but also being managed in accordance with the law.