Smart Contracts Documentation

Even though Tokery’s smart contracts repository is not public yet, we can outline the structure and functionality of the on-chain programs that power Tokery’s tokenization.

Asset Token Contracts (Solana Programs): Each tokenized asset on Tokery is represented by a set of on-chain entities:

• An SPL Token Mint that represents the asset. This mint is configured according to the asset’s structure:

  • Full Ownership: If the asset will not be fractionalized, the mint may issue a single token (or a fixed small supply) representing the entire asset.

  • Fractional Ownership: The mint’s total supply is set to a large number (e.g., 1000, 1e6, or 1e8 tokens) reflecting divisible shares of the asset​.The asset owner usually retains some portion and can distribute or sell the rest.

  • Revenue-Sharing or Debt: The token can represent a claim on cash flows (like rental income or a loan’s interest). In such cases, the token contract might incorporate a mechanism for distributing dividends or interest to token holders. This could be achieved via an associated program that periodically sends SOL/stablecoin to token holders proportional to their holdings, or via off-chain handling logged on-chain.

  • Time-Locked or Vesting Tokens: Tokery’s contracts support timelocks​.For example, an asset owner might lock up their own tokens for a period or enforce that certain tokens cannot be transferred until a date (useful for regulatory lock-up periods or vesting schedules for shareholders). This is implemented through a smart contract that can freeze transfers of certain accounts until the lock expires.

• Pre-Audited Contract Templates: Tokery has developed a suite of Solana programs that handle the above variations in token behavior. These programs are audited for security and reused across tokenizations, with parameters tailored per asset. For instance, one program might handle transfer restrictions – ensuring only KYC-approved wallets can hold the tokens (by checking a whitelist or requiring a “verified” NFT in the holder’s wallet, such as a Civic Pass). Another program might handle profit distribution for revenue-sharing tokens. By deploying standardized, audited code for each asset (instead of writing a custom contract every time), Tokery guarantees security and consistency​. Developers can trust that each asset token contract adheres to rigorous security standards.

• Metadata and Document Linking: Each asset’s on-chain record contains a pointer to its metadata and legal documentation stored off-chain. On Solana, this is often done via the Token Metadata program (a widely used program for NFT and token metadata). Tokery uses it to attach a JSON metadata file to the asset’s mint, which includes fields such as name, symbol, description, IPFS links to documents (deed, contracts, appraisal, etc.), and regulatory flags. This metadata is immutable or update-restricted (e.g., only updateable by the asset issuer or Tokery’s authority) to ensure the asset information remains consistent and tamper-proof. By storing documents on IPFS/Arweave and linking in metadata, Tokery ensures the legal provenance is permanently associated with the token​.

• Administrative Controls: In compliance with regulations, Tokery’s smart contracts may include administrative keys or multisig controls. For example, a Freeze Authority on the SPL token mint could be held by the Tokery compliance program. This allows freezing transfers if an asset needs to be halted (e.g., due to a legal dispute or sanctions on a user). There may also be an Asset Owner Authority that can issue new tokens (if the token represents an evolving asset like a fund that can grow) or revoke tokens (in case of asset redemption or burn upon buy-back). All such authorities are set up at token creation time according to the selected structure and jurisdiction (some jurisdictions might require the ability to revoke tokens representing securities, etc.). These controls are documented and transparent – for each token, one can query whether it’s freeze-able or not, who holds the authority, etc., on Solana.

Interaction from Developer Side: For developers, all Tokery asset tokens are standard SPL tokens, meaning they can be interacted with using Solana’s existing libraries (e.g., @solana/web3.js or Anchor framework) like any other token. If a developer or third-party dApp wants to support Tokery assets, they simply treat them by their Mint address. For example:

• To get an asset’s total supply or holders: use Solana RPC calls for token supply and account states.

• To transfer asset tokens: use the standard SPL Token Program Transfer instruction (transfers will succeed if sender and receiver are compliant; if not, the token’s program will reject it, e.g., if the receiver isn’t KYC-approved, a custom restriction might block it).

• To fetch asset metadata: query the Token Metadata PDA (Program Derived Address) for the mint to get the URI, then fetch the JSON from IPFS.

If Tokery has an Asset Management Program (a custom program that governs things like revenue distribution or allows only whitelisted trades), developers can also call into that. For instance, a partner exchange could integrate an instruction like tradeAsset(assetMint, buyer, seller) that checks all compliance and then uses the token program internally. All these program interfaces will be documented once open-sourced, but they follow Solana conventions.

In essence, Tokery smart contracts combine the reliability of Solana’s token standards with specialized logic for asset tokenization. They cover fractional ownership, income-sharing, vesting, and transfer control out-of-the-box, so developers don’t have to reinvent or audit these features for each new asset. This robust on-chain foundation underpins the trust in every token issued through Tokery.