> For the complete documentation index, see [llms.txt](https://golden-shield-digital-treasury-b.gitbook.io/product-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://golden-shield-digital-treasury-b.gitbook.io/product-docs/tokenomics/interactive-blocks.md). # Token issuance mechanism This document outlines the key stages in the lifecycle of a GDB token, illustrating how GDB’s platform and smart contracts handle **issuance**, ensure **compliance**, manage **redemption** (and other investor rights events), and facilitate **trading/settlement**. These user journeys demonstrate how GDB’s framework supports a secure and regulatory-compliant digital security offering from start to finish. ### Issuance
Issuance is the process by which an issuer creates and distributes new GDB tokens to investors in a compliant manner. The high-level steps in a typical GDB token issuance are: 1. **Investor Onboarding:** The issuer begins by inviting potential investors to participate (for example, via a GDB issuance platform or portal). Off-chain, the issuer collects necessary information from investors, including identity documents for **KYC/AML** checks (Know Your Customer / Anti-Money Laundering) and verifies any required accreditation status. Investors may also need to sign subscription or token purchase agreements during this phase. *This onboarding process happens off-chain, using the GDB platform’s interfaces, and ensures only eligible investors proceed.* 2. **Registering Investors On-Chain:** Once an investor is approved through KYC/AML, the issuer (or the issuance platform on the issuer’s behalf) registers the investor’s details on the **GDB Registry** smart contract. This is done by calling a function (such as `registerInvestor()`) on the registry, storing the investor’s identity attributes relevant to compliance (e.g. country of residence, accreditation level, etc.) and associating the investor’s blockchain wallet address with those attributes. Only authorized parties (the issuer and trusted partners like certain exchanges) can add entries to the GDB registry, ensuring that unvetted wallets cannot receive GDB tokens. This registry will be used throughout the token’s life to enforce compliance in transfers. 3. **Token Creation and Allocation:** After the fundraising phase is complete and the list of eligible investors is finalized (including any final checks or discounts applied off-chain), the issuer deploys the **GDB Token smart contract**. The token contract is configured with the total supply or minting rules as needed for the offering. The issuer then assigns or mints the appropriate number of GDB tokens to each registered investor’s wallet address according to their investment. This initial allocation can be done in a single transaction or in batches, and it effectively delivers the digital securities to the investors on-chain. 4. **Linking Compliance Controls:** The newly created GDB token contract is linked to the registry and compliance modules. In practice, the token contract holds a reference to the GDB Registry contract (and a Compliance contract, if separate) to validate any future transfer. At this point, the token is live, but transfers are restricted by design – only wallets recorded in the registry can hold the tokens. The issuer may also set initial transfer restrictions (for example, to enforce a lock-up period during which tokens cannot be traded). With issuance complete, investors now hold GDB tokens in their wallets, and the compliance framework is in place to govern all post-issuance activities. ### Compliance Enforcement A core feature of GDB’s system is **built-in compliance enforcement** for all token transactions. Every GDB token transfer (whether a peer-to-peer trade or an exchange-mediated transaction) is subject to checks that ensure regulatory and issuer-defined rules are obeyed. GDB’s compliance logic is generally implemented via a **Compliance Service/Module** connected to the token. Here’s how it works: * **Pre-Transfer Validation:** When a holder attempts to transfer GDB tokens (e.g. by calling `transfer()` or an exchange calling `transferFrom()` on behalf of a user), the token’s smart contract will invoke the compliance module to approve or reject the move *before* any tokens actually change hands. The compliance module retrieves the relevant data about the parties from the GDB Registry. Both the sending and receiving addresses are looked up to confirm they are recognized investors and to obtain their classification (such as jurisdiction, investor category, etc.). * **Eligibility Checks:** The compliance rules are then evaluated. For example, the module will check that the sender’s tokens are not currently subject to any transfer lock (such as a mandatory holding period or a freeze due to a regulatory order). It will also verify that the recipient is authorized to receive the tokens – this means the recipient’s wallet must be registered in the GDB Registry (if not, the transfer is blocked) and that adding this recipient will not violate any limits (for instance, exceeding the maximum number of investors allowed or breaching a concentration limit of tokens in a certain region). The recipient’s category is checked against the token’s rules; for example, if the token is restricted to accredited investors only, the recipient’s status in the registry must reflect that accreditation. * **Approved or Rejected in Real-Time:** If all compliance conditions are satisfied, the compliance module allows the transfer to proceed, and the tokens move to the new owner. If any rule is violated, the transfer is **prevented** (the transaction is reverted) and an event can be emitted on-chain citing the reason (such as "unauthorized investor" or "regulatory transfer limit exceeded"). Because this logic executes within the token’s smart contract functions, **no GDB token can be transferred in a way that bypasses the rules**. Every transaction is vetted automatically and transparently on-chain. * **Maintaining an Updated Investor Pool:** Compliance enforcement also means that new investors can join the token’s investor pool only after proper registration. If an interested buyer hasn’t been onboarded (i.e. their address isn’t in the registry), any attempt to send tokens to them will fail. This encourages potential investors to go through the official onboarding process (either via the issuer or an authorized exchange partner) to become eligible. The issuer retains control by granting permission to certain exchange platforms or brokers to add investors to the registry (subject to the issuer’s oversight). This design preserves regulatory compliance while still allowing the investor base to grow in a controlled manner. * **Adaptability:** GDB’s compliance mechanism is modular and updatable. If regulations change or new industry-standard compliance protocols (for example, specific on-chain checks mandated by law) emerge, the issuer can upgrade or configure the compliance module of an existing GDB token to accommodate those changes. This **future-proof** approach means GDB tokens issued today can be adapted to tomorrow’s rules without needing to re-issue an entirely new token. In summary, GDB ensures that **only authorized transfers succeed**. This protects issuers, investors, and exchanges by preventing illicit or non-compliant trades at the smart contract level, rather than relying solely on off-chain enforcement. ### Redemption and Distributions
Throughout the life of a GDB token, investors may have rights to certain economic events such as periodic income distributions or redemptions of their tokens. GDB’s flexible architecture supports these **in-life events** through dedicated smart contracts or “apps” that work alongside the main token. Two common examples are **interest (dividend) distributions** and **redemption of tokens** (for example, at maturity or through buybacks). #### **Interest/Dividend Distribution Example** If the underlying asset or agreement behind a GDB token provides holders with periodic payments (such as interest on a bond or dividends from profits), the issuer can use a **distribution contract** (a type of GDB app) to automate the payout to all token holders. A typical flow for distributing a payment to token holders might look like this: 1. **Initiating the Distribution:** The issuer triggers a distribution event using the GDB platform’s console or by calling a function (e.g. `initiatePayout()`) on a **Payout smart contract** associated with the token. This might happen on a scheduled date (for a quarterly interest payment, for instance). 2. **Funding the Payout:** The issuer transfers the total payout amount into the Payout contract. The payment could be in the form of Ether or a stablecoin or other token depending on how the distribution is structured. For example, if distributing stablecoin as interest, the issuer would deposit the total due amount to the contract and call a method like `distributeInterest(amount)`. 3. **Accessing Holder Records:** The Payout contract interacts with the GDB Token contract (using GDB’s extension of ERC-20 functionality) to retrieve the full list of current token holders and their balances. Unlike a standard ERC-20, which doesn’t provide an easy way to iterate through all holders, the GDB token keeps an accessible registry of investors, enabling this contract to know *who* to pay and *how much*. This step is crucial for automating distributions across potentially thousands of addresses. 4. **Calculating and Sending Payments:** For each investor in the holder list, the contract calculates that investor’s share of the total payout based on their token balance (e.g. pro-rata for interest or dividends). It then attempts to send the appropriate amount to the investor’s wallet. This could be done as an Ethereum transfer (if Ether) or an ERC-20 token transfer (if paying in a token like a stablecoin). The compliance module isn’t typically involved here because these are outgoing payments from the issuer contract to holders, not transfers of the security token itself; however, the distribution contract might still consult the registry for info like tax-withholding rates or country codes. 5. **Handling Transfer Issues:** If a payment to a particular investor’s address fails (for instance, the address might be an exchange wallet that cannot automatically accept unexpected tokens, or the address is unreachable), the Payout contract will not lose those funds. Instead, it records an **allowance** or credit for that investor within the contract. The investor can later claim their funds by calling a `withdraw()` function from their registered address, which will release their portion of the payout. This ensures no holder misses out on the distribution due to technical issues receiving the payment. 6. **Investor Notification:** GDB’s system will notify investors of the distribution. This could be done via an off-chain communication service integrated with GDB (such as email or platform notification through a **Communications Service**). The notification typically includes details like the total amount distributed, the per-token amount, and instructions for any investors who need to manually claim their portion (if an automatic transfer failed for them). 7. **Completion:** Once completed, the distribution event is recorded (both on-chain via events and off-chain in the issuer’s reports). Investors receive their funds, and the process is transparent. Importantly, this entire procedure did not require investors to take any action (unless a manual withdrawal was needed in a failed case), underscoring how GDB smart contracts can streamline investor rights management. #### **Token Redemption Process** **Redemption** refers to repurchasing or retiring the tokens, usually in return for a payout to holders. This can happen at a bond’s maturity (return of principal), during a buyback program, or any scenario where the issuer or another party offers to redeem (i.e., buy and cancel) the security tokens. GDB supports redemption events through similar smart contract mechanisms: 1. **Scheduling a Redemption Event:** The issuer decides to execute a redemption and sets the terms (for example, each GDB token will be redeemed for a certain amount of currency, perhaps the face value of a bond). The issuer uses the platform or calls a contract (e.g. a **Redemption contract**) to initiate the event, specifying details like the redemption date, price per token, and whether the redemption is full or partial. At this point, the issuer might also toggle certain restrictions on the token – for instance, they might pause trading or restrict transfers of the token around the redemption date to freeze the holder list. This ensures clarity on who is entitled to redemption. 2. **Funding the Redemption:** Ahead of execution, the issuer deposits the total redemption funds into the Redemption contract (if the payout is happening on-chain). If the redemption is one where investors actively submit tokens to redeem (a voluntary redemption or buyback scenario), the contract will hold the funds and release them as tokens come in. If it’s an automatic mandatory redemption (like at maturity), the contract will use the funds to pay out to all holders in one go. 3. **Executing Redemption to Holders:** On the redemption date (or when triggered by the issuer), the Redemption contract goes through the list of all token holders (retrieved via the registry as in the distribution case). For each holder, it determines how many tokens they have and calculates their redemption payment (tokens \* redemption price). Then: * In an **automatic redemption**, the contract can directly transfer the payment to each holder’s address and simultaneously reduce the holder’s token balance (for example by instructing the GDB token contract to burn those tokens or by moving them to a null address). This effectively pays investors and cancels the tokens in one transaction per holder. * In a **voluntary redemption or offer**, the contract might operate on a first-come, first-served basis: investors send their tokens to the contract (calling a function like `redeem(tokensAmount)`), and the contract pays them the appropriate amount in return and burns the received tokens. The contract may be open for a window of time to accept redemptions until a target amount of tokens are redeemed or a deadline passes. 4. **Compliance Considerations:** During redemption, compliance is generally less of an obstacle since it’s typically the issuer buying back tokens from existing holders. All participants are already known and in the registry. If the redemption involves a third-party buyer or a change of ownership, the compliance module would still verify that any recipient of tokens (or replacement tokens) is allowed. However, in a standard issuer redemption, the issuer’s own wallet might be the one receiving the tokens (to retire them), and that wallet is of course authorized. Taxes or withholding could be handled if required (for example, if certain investors must have taxes withheld on redemption proceeds, the contract could be coded to adjust their payout accordingly by referencing their country info in the registry). 5. **Finalizing and Updating Records:** After a full redemption, the GDB token’s supply might be reduced or set to zero. The token contract could be locked to prevent further transfers (since the security is essentially retired). If partial, the total supply is updated to reflect the remaining tokens in circulation. The registry might mark certain investors as no longer holders. The issuer would then confirm the completion of the redemption event. Off-chain, communications are sent out to investors summarizing the outcome, and any unclaimed funds or remaining tokens are handled per the terms (e.g., unclaimed redemption funds might be escrowed or returned to the issuer after a period). 6. **Investor Experience:** Investors are kept informed via the GDB platform notifications at each stage (announcement of redemption, any action required on their part, and confirmation of completion). The goal is to make the redemption as seamless as possible—ideally automatic—so investors simply receive funds in exchange for their tokens without needing complicated procedures. Through these mechanisms, GDB provides issuers with the **flexibility to manage the full lifecycle** of the security token, from paying periodic returns to retiring the tokens, all executed in a transparent and compliant manner via smart contracts. ### Trading and Settlement Logic
Once issued, GDB tokens can be bought and sold among investors, but any such **secondary trading** must respect the compliance constraints described earlier. “Settlement” refers to the actual transfer of tokens from seller to buyer in fulfillment of a trade. GDB’s design ensures that settlement will only succeed if the trade is compliant. Different trading scenarios are supported: * **Direct Peer-to-Peer Transfers:** Investors may trade GDB tokens directly with each other without an intermediary. For example, an existing investor might know someone who wants to buy their tokens and agree on a trade privately. In this case, the seller can simply transfer tokens from their wallet to the buyer’s wallet on-chain. The GDB compliance module will check that the buyer’s wallet is registered and approved. If the buyer is a completely new investor not yet in the registry, the transfer will fail. In practice, the buyer would need to get onboarded (perhaps by contacting the issuer or via an approved process) *before* the seller can successfully transfer the tokens. Additionally, the system checks that the seller’s tokens aren’t subject to any lockup. If all is in order, the peer-to-peer transfer executes and the buyer becomes a new holder. This scenario is essentially an Over-The-Counter (OTC) trade settled on-chain, with GDB ensuring that even these private trades cannot skirt the rules. * **Decentralized Exchange (DEX) Trades:** GDB tokens can be listed on decentralized trading platforms or protocols that facilitate wallet-to-wallet trading through smart contracts. In a DEX scenario, a seller might place an order to sell tokens and a buyer places an order to buy, and a smart contract (or off-chain matching service) brings them together. Protocols like AirSwap or 0x (adapted for security tokens) operate this way. When a trade is ready to execute, typically the seller would have given the DEX’s escrow contract an allowance to transfer their tokens (using `approve()`), and the buyer would transfer their payment (in Ether or stablecoin) to that escrow contract. The DEX contract then calls `transferFrom(seller, buyer, tokenAmount)` on the GDB token contract to move the tokens from seller to buyer. At this moment, GDB’s compliance checks kick in just as with any transfer: the token contract consults the registry to verify both the seller and buyer. Assuming the buyer was pre-vetted (good exchanges will require the buyer to complete KYC and be added to the registry before trading), the transfer will go through, and simultaneously the payment from the buyer is released to the seller – achieving an atomic swap of payment for tokens. If the buyer had not been approved or any limit is exceeded, the token transfer would fail and the whole DEX trade would not execute. Thus, DEX trades settle on-chain with the same compliance guarantees, and an event log will indicate success or failure. This gives the benefits of decentralized settlement (no need to trust an intermediary with custody) while upholding all regulatory requirements enforced by GDB. * **Centralized Exchange (Individual Wallets):** Security token exchanges (often called STEs) or other centralized trading platforms might list GDB tokens and facilitate trading for their users. A common compliance-friendly model is for the exchange to provide each user with a **unique blockchain wallet** (often managed behind the scenes by the exchange). Here’s how it works: A new investor signs up on the exchange and goes through the exchange’s KYC/AML process. The exchange, being an authorized partner of the issuer, can then call the GDB registry’s `registerInvestor` function to add this new investor (if the investor isn’t already in the issuer’s registry). The exchange will supply the required information (country, accreditation, etc.) and often a cryptographic attestation that they verified the documents, as per any data-sharing agreements. Once the investor is registered, the exchange either creates a new wallet address for them or uses an existing user-specific wallet, and then associates that address with the investor by calling the registry again to link the wallet. Now the investor is cleared to hold GDB tokens. To **buy tokens**, the investor can place an order on the exchange. When matched with a seller, the exchange will handle the trade: the seller’s tokens (which might already be in that seller’s own exchange-provided wallet) are transferred to the buyer’s wallet on-chain. This transfer triggers the compliance check, but since both wallets belong to registered investors (the seller was already an investor; the buyer has just been added), it should pass as long as the trade doesn’t break any regulatory constraints (such as causing the buyer to exceed an ownership percentage limit, if one exists). If for some reason the buyer’s status or the trade size violates a rule, the transfer would fail and the exchange would abort the trade, notifying both parties. For a **sell order**, a similar process occurs in reverse: an existing investor who wants to sell might first need to transfer their tokens into their exchange-designated wallet (if they were holding them in a personal wallet). The exchange makes sure that personal wallet is also registered to that investor (generally, an existing holder is already in the registry, so they just add the new wallet if needed). The investor then sends tokens from their personal wallet to their exchange wallet (a transfer between two addresses both owned by the same investor, which GDB compliance permits since it’s the same investor identity, just different wallets). Once the tokens are in the exchange wallet, the exchange can match the sell order with a buyer and execute an on-chain transfer to the buyer’s wallet as described. After trading, investors can also **withdraw** tokens from the exchange by asking the exchange to send the tokens to another wallet address of theirs (again, that new address must be registered first either by the exchange or issuer). Throughout these steps, the exchange and issuer coordinate via GDB’s registry and compliance calls, so that even though trading feels seamless to the user, every settlement on-chain is compliant by design. * **Centralized Exchange (Pooled Wallets):** Some exchanges (especially traditional crypto exchanges) use a model where many users’ assets are commingled in one or a few blockchain addresses for operational efficiency. In a conventional cryptocurrency scenario, an exchange might have a single wallet hold all customers’ tokens and track customer balances in their internal database. However, for a regulated GDB token, this approach poses challenges to transparency and compliance. From the GDB platform’s perspective, if one omnibus address holds tokens for, say, 100 different investors, the on-chain registry would only see that one address as the holder of all those tokens, making it impossible to directly discern how many distinct investors are actually involved (which is important for things like the 100-investor limit in certain exemptions, or for sending each investor their due payments). It also complicates delivering communications or rights (because the issuer doesn’t know the actual owners). **GDB generally discourages pooled wallets for these reasons.** Nonetheless, recognizing that some exchanges may insist on using them for liquidity reasons, GDB provides a controlled mechanism to accommodate pooled accounts without breaking compliance: **“Investor Slot” reservations.** In this scheme, the issuer can explicitly authorize an exchange’s omnibus wallet to count as multiple investors up to a certain number. For example, the issuer might grant a reservation of 10 investor slots for a given pooled address in the category of U.S. accredited investors. The compliance module will then treat that single address as if it can represent up to 10 distinct accredited U.S. investors. When the exchange’s internal users deposit tokens into or withdraw from this pooled address, the exchange must ensure it never has more than 10 distinct owners’ holdings mixed there. If it approaches the limit (say 10 slots already filled and another user wants to deposit tokens into the pool), one of two things must happen: either the exchange **transfers some tokens out** to another address (e.g., creates a separate wallet for one of the investors, freeing a slot) or the exchange requests the issuer to approve additional slots. The issuer, at their discretion, can update the compliance settings to grant more slots (perhaps after further due diligence). This slot system puts a hard cap on the number of beneficial owners hidden behind a pooled address, thereby keeping the overall investor count and profile within allowed bounds. It also creates accountability: if an exchange has reserved slots, it must manage them actively or risk failed transfers once the slots are full. In practice, this complexity and the potential need for the exchange to **periodically shuffle tokens out of the pool** or ask for more slots creates an incentive to move toward the individual wallet model. GDB’s slot mechanism is a fallback to maintain compliance in scenarios where pooling is used, but it is **not a preferred long-term solution** for trading digital securities. No matter which trading route is taken, **settlement of GDB token trades is always subject to compliance verification at the smart contract level**. This ensures that even as tokens trade freely, the issuer and regulators can be confident that forbidden transactions (such as transfers to unapproved investors or in excess of legal limits) will simply not go through. In addition, GDB makes it easier for exchanges to work within this framework by offering tools such as an off-chain **“Ready For Exchange” API** (if provided by the GDB platform) where an exchange can, for example, query whether a potential investor is eligible to receive the token *before* executing a trade. Exchanges can also contribute back information (with the issuer’s approval) — for instance, sharing their KYC vetting data — to expedite adding new investors to the system. All of these integrations are aimed at balancing regulatory compliance with liquidity and a smooth user experience. In conclusion, the GDB protocol covers the full lifecycle of a digital security token: from compliant **issuance** and onboarding, through **enforced compliance** on every transfer, handling investor **distributions and redemption** events, to facilitating **trading and settlement** in various environments. GDB’s architecture is designed to be flexible and future-proof, so issuers can confidently manage their digital assets knowing that as regulations evolve or markets expand, the platform will adapt to continue ensuring trust, compliance, and efficiency at each step of the journey.