> For the complete documentation index, see [llms.txt](https://gabriel-j-shapiro.gitbook.io/metalex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gabriel-j-shapiro.gitbook.io/metalex-docs/protocol-explanation/dual-token-model.md). # The dual-token model The protocol's defining architectural innovation is a dual-token model that resolves the tension between **legal fidelity** and **DeFi composability**. ## The two tokens ### cyberCERT (ERC-721) โ€” the register Each cyberCERT is a single entry on the cyberCORP's onchain register of holders, encoding everything that the relevant governing law requires: holder name, unit count, class / series, restriction legends, endorsement history, authorized signatures, acquisition price, and the governing agreement URI. Crucially, **NFT transfer alone does not change registered ownership.** Metadata must be explicitly mutated through `IssuanceManager`. This maintains the distinction between *token possession* and *registered ownership* that corporate, LLC, partnership, and fund law require. ### cyberSCRIP (ERC-20) โ€” the trading form cyberSCRIPs are fungible tokens generated from cyberCERTs via `scripifyCert()` and convertible back via `convertScripToCert()`. They are the DeFi composable layer: usable in AMMs (including LiquiLeX pools), lending protocols, vesting contracts, and as collateral. The critical claim: **cyberSCRIPs are not wrappers or derivatives.** They are *securities in scrip form*. Under DGCL ยง155 (in the Delaware corp case) or the analogous contractual or statutory authority under the entity's governing law, scrip is itself an authorised form of the security. Every circulating cyberSCRIP traces, through the protocol's own logic, to a specific cyberCERT on the authoritative register. ## The plain-English version * A **cyberCERT** is your interest in the entity as it lives in the official records (a share of stock, an LLC membership interest, an LP unit, a fund interest). * A **cyberSCRIP** is what you can trade or post as collateral when you do not need to be registered as a holder of record at that moment. * Both are the same security in different forms, with bidirectional conversion always available. ## Why this works ### Composability without losing the register A cyberSCRIP can sit in a Uniswap v4 pool and trade in size all day. The register does not move. When a long-term holder wants to be the holder of record, they de-scripify โ€” and at that moment, and only at that moment, the full issuer-approval / accreditation gate runs. ### Compliance at the boundary This is what lets a LiquiLeX pool be either *whitelisted* (compliance on every swap) or *open* (compliance at de-scripification, with optional light-touch zkPassport screening at swap). The boundary is the only place that matters legally, because that is where the register changes. ### Partial scripification A holder of 1,000,000 units can scripify 250,000 to trade and keep 750,000 on the cert. The cert remains active with the reduced unit count. The Scripified Share Pool (an ERC-4626-style vault inside the `IssuanceManager`) tracks each registered holder's scripified balance so that de-scripification withdraws proportionally. ## What it isn't * Not a wrapped-token model. The scrip is the security; the wrap-and-unwrap framing is wrong. * Not a derivative model. There is no contract for difference, no shadow-asset, no offchain leg. * Not a synthetic. A cyberSCRIP is not a claim on a cyberCERT; it is the same security in a different form. ## See also * [Tutorial 3: Scripify and settle](/metalex-docs/protocol-tutorials/scripify-and-settle.md) * [`IssuanceManager`](/metalex-docs/protocol-reference/contracts/issuancemanager.md), [`CyberScrip`](/metalex-docs/protocol-reference/contracts/cyberscrip.md) * [Composability and DeFi](/metalex-docs/protocol-explanation/composability.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://gabriel-j-shapiro.gitbook.io/metalex-docs/protocol-explanation/dual-token-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.