Blockchain-based subdomain system for tokenization, certification, and management of real-world, digital and identity assets

Abstract

The invention presents a blockchain-based system for the tokenization, certification, and management of real-world assets, digital assets, and verified identities. It integrates Web3 domain-subdomain tokens, distributed ledger technology (DLT), decentralized identifiers (DIDs), and AI-driven verification processes to provide secure and transparent transactions. The system employs KYC subdomain tokens linked to users' blockchain wallets for identity verification, enabling compliance with regulatory standards. Human-readable Web3 tokens enhance asset traceability. Al and manual verification ensure efficient and accurate processing. Scalable and flexible, the system supports diverse asset types and includes time-based voiding mechanisms to address incomplete transactions, ensuring effective lifecycle management. Primary tokens have metadata storing a first cryptographic commitment associated with an issuance context of at least one secondary token wherein the first cryptographic commitment and the second cryptographic commitment are generated such that they form a mutual cryptographic binding between the primary token and the at least one secondary token.

Description

[0001] Attorney Docket Number: TT-0003 Title: Blockchain-Based Subdomain System for Tokenization, Certification, and Management of Real-World, Digital, and Identity Assets with Cryptographic Binding, Access Control, and Conditional Settlement Mechanisms

[0002] Inventor and Applicant: Matthew Smith Shepley

[0003] RELATED APPLICATIONS

[0004] This patent application claims priority to U.S. Pat. App. No. 18 / 947,906 filed Nov. 14, 2024 in the United States of America, the disclosure of which is incorporated by reference herein in its entirety; and this patent application also claims priority to U.S. Pat. App. No. 19 / 382,164 filed Nov. 6, 2025 in the United States of America, the disclosure of which is incorporated by reference herein in its entirety.

[0005] FIELD OF THE INVENTION

[0006] The present invention generally relates to the field of digital certification and tokenization of real-world, digital, and identity assets, and also to blockchain-based token mechanisms for secure asset redemption, fine-grained access control, and conditional settlement.

[0007] BACKGROUND OF THE INVENTION

[0008] Current methods for managing, certifying, and transferring ownership of real-world assets such as land titles, vehicles, commodities, and artwork are often fragmented and rely heavily on manual processes. These methods are prone to human error, are time-consuming, and frequently lack adequate security measures to prevent tampering or fraud.

[0009] Current methods for managing digital assets, such as data, intellectual property, and verified identity, face similar challenges, including a lack of secure, portable, and verifiable representations. Additionally, identity verification remains a fragmented process, often relying on centralized databases vulnerable to breaches and unauthorized access.

[0010] Centralized databases, which are commonly used to store ownership records, are vulnerable to unauthorized access, data manipulation, and single points of failure, leading to potential disputes and challenges in asset ownership verification.

[0011] Despite advances in blockchain technology, current systems lack a comprehensive framework for tokenizing a broad range of asset types, including identity, digital property, and real-world assets, and fail to address incomplete transactions effectively.

[0012] With the rapid growth of digital asset markets and increasing regulatory scrutiny, there is a heightened demand for a secure, automated system that can effectively manage the tokenization, certification, and transaction processes across a diverse range of assets. Attorney Docket Number: TT-0003 Existing systems do not include a mechanism to automatically void smart contracts (selfexecuting contracts with terms written in code, running on a blockchain, which automatically enforces and executes the agreed-upon conditions) if certification is not completed within a predefined timeframe, which can lead to stalled transactions or unverified agreements.

[0013] Blockchain technology has emerged as a powerful tool for ensuring transparency and security in transactions, offering a decentralized approach to recording and managing ownership rights. However, existing systems are often limited in scope, focusing on specific asset classes or lacking integration with modem technologies such as Web3 domains, decentralized identifiers (DTDs) for identity, and artificial intelligence (AT).

[0014] For instance, U.S. 2021 / 0090189 focuses on using blockchain for land title management, while U.S. 2019 / 0080392 addresses the tokenization of commodity assets. These systems do not offer a comprehensive solution that integrates Web3, Distributed Ledger Technology (DLT), and Artificial Intelligence (AT) to manage a broad range of real-world assets.

[0015] In the evolving landscape of digital asset management, there is an urgent need for a comprehensive, secure, and automated system that can ensure the immutability of smart contracts once they have been verified. Current solutions fail to integrate advanced technologies such as Web3, DLT, and AT. This lack of integration leads to significant vulnerabilities and inefficiencies when managing real-world assets like real estate, vehicles, artwork, and commodities. As a result, current systems are prone to fraud, manual errors, and unauthorized modifications that undermine trust in the system. Additionally, existing solutions often lack scalability, making them ill-suited for managing the complex requirements of diverse asset types and high transaction volumes.

[0016] Furthermore, current methods for managing, certifying, and transferring ownership of both physical and digital assets are often fragmented, rely heavily on human data entry and execution, and prone to errors or fraud. For example, real -world asset transactions (such as land title transfers or artwork sales) commonly rely on paper certificates, notaries, or centralized databases that lack a unified standard for security and verifiability. Digital assets and identity credentials face similar challenges: there is no widely adopted mechanism to represent ownership or rights in a secure, portable, and tamper-evident manner. Consequently, there is a need for a blockchain-based solution that can tokenize various asset types and identity attributes in a reliable way, ensuring that ownership and permissions are verifiable and that income or value flows derived from these assets can be managed automatically.

[0017] SUMMARY OF THE INVENTION Attorney Docket Number: TT-0003 One embodiment of the present invention may comprise a method for tokenizing and managing assets using blockchain technology. The method comprises causing a domainsubdomain token to be created, the token having a top-level domain identifier, and one or more subdomain identifiers under the top level domain, at least one of the sub-domain identifiers associated with an asset. The method also comprises causing a smart contract to be generated on a blockchain in relation to the asset, wherein the smart contract references the domain-subdomain token.

[0018] In some embodiments, the domain-subdomain token comprises exactly one subdomain identifier. In some embodiments, the domain -sub domain token comprises exactly two subdomain identifiers. In some embodiments, the method also includes using the domain-subdomain token in a blockchain name service query to obtain an address for a smart contract associated with the asset.

[0019] In some embodiments, the method further comprises creating underlying data for a quick response (QR) code, the data having a uniform resource locator (URL), and the URL having the domain-subdomain token therein. The method may also include providing access to a webpage corresponding to the URL of the QR code.

[0020] In some embodiments, the smart contract comprises an income distribution schedule in the smart contract, wherein funds are automatically distributed by the smart contract to token holders based at least in part on ownership percentage.

[0021] In another embodiment, there is a method for tokenizing and managing real-world assets using blockchain technology. The method comprises initiating a tokenization process for an asset by staging asset parameters in a database before generating a smart contract on a distributed blockchain, the smart contract being associated with the asset. The method also comprises verifying the asset’s ownership and existence by comparing asset parameters against information obtained from one or more digital documents. The method also comprises causing a domainsubdomain token to be created after successful verification of the asset’s ownership and existence, the token having a top level domain identifier, and one or more subdomain identifiers under the top level domain, at least one of the sub-domain identifiers associated with an asset. And the method also comprises causing to be generated a smart contract corresponding to the asset, wherein the smart contract references the domain-subdomain token.

[0022] In some embodiments, the method further comprises creating underlying data for a quick response (QR) code, the data having a uniform resource locator (URL), and the URL having the Attorney Docket Number: TT-0003 domain-subdomain token therein. The method may also include providing access to a webpage corresponding to the URL of the QR code.

[0023] In some embodiments, the smart contract is immutable. In some embodiments, the smart contract makes available asset tokens representing fractional or full ownership of the asset.

[0024] In some embodiments, the method may include receiving closing or ownership documents for certification, generating a certification domain-subdomain token, and sending the certification domain-subdomain token to the smart contract, wherein thereafter the smart contract releases funds to a wallet address.

[0025] In some embodiments, the method may include generating a closing domain-subdomain token after the sale or transfer of the asset, and sending the closing domain-subdomain token to the smart contract. In some embodiments, the smart contract releases funds to a wallet address upon receipt of a token from that wallet address.

[0026] In some embodiments, the method may also include receiving closing or ownership documents for certification, generating a voiding domain-subdomain token, and sending the voiding domain-subdomain token to the smart contract, wherein thereafter further transactions with the smart contract are prevented.

[0027] In some embodiments, the smart contract will become invalidated if a certification domainsubdomain token is not received by the smart contract within a predefined period of time. In some embodiments, at least a portion of the information obtained from one or more of the digital documents is obtained using optical character recognition and named entity recognition.

[0028] In some embodiments, the smart contract comprises a payment escrow so that the smart contract holds funds until receipt of a second domain-subdomain token.

[0029] In another embodiment, there is a method for tokenizing a know-your-customer (“KYC”) process on a blockchain. The method comprises generating KYC subdomain token information, the token information having a top level domain identifier, and one or more subdomain identifiers under the top level domain identifier, at least one of the subdomain identifiers corresponding to a specific person or entity. The method also comprises causing the KYC subdomain token information and wallet information to be sent to a blockchain name service whereafter the blockchain name service generates a KYC subdomain token comprising the KYC subdomain token information and the wallet information.

[0030] In some embodiments, the method may comprise creating underlying data for a quick response (QR) code, the data having a uniform resource locator (URL), and the URL having the Attorney Docket Number: TT-0003 KYC subdomain token therein. In some embodiments, the method may also include providing access to a webpage corresponding to the URL of the QR code.

[0031] In some embodiments, the method further comprises generating a smart contract on a blockchain, the smart contract configured to interact only with a blockchain wallet associated with a KYC subdomain token.

[0032] In some embodiments, the method also comprises causing a smart contract associated with the block chain name service to send a token comprising at least a portion of the KYC subdomain token information to the wallet address.

[0033] In some embodiments, the method may also comprise causing to be updated in the block chain name service the wallet address associated with the KYC subdomain token to a different wallet address.

[0034] The present invention, in some embodiments, has a double-predictor method for cryptographically linking a primary token with one or more associated tokens of any type (financial instruments, identity credentials, loT proofs, compliance certificates, access rights, or licenses) by embedding reciprocal commitments to a shared issuance transcript. In some embodiments, validation succeeds only when the originally bound tokens are presented together, ensuring integrity of the linkage regardless of the use case.

[0035] The present invention also includes a blockchain-based tokenization system and method that includes several novel mechanisms to enhance security, flexibility, and compliance in token transactions. In one aspect (Embodiment Bl), the invention introduces a Double-Predictor Token Binding mechanism in which a non-fungible primary token (for example, an NFT representing a redemption instruction or IOU) is cryptographically bound to one or more associated tokens (for example, fungible tokens representing the underlying value) via reciprocal cryptographic commitments. Each token carries, in its metadata, a cryptographic commitment (such as a secure hash or “predictor” value) referencing the other token(s). This mutual binding allows a deterministic one-step verification of token authenticity and pairing at the time of redemption. When the primary token is presented along with candidate associated token(s) for redemption, the system recomputes and compares the commitments to confirm that the associated tokens exactly match the expected issuance context of that primary token. If the commitments correspond, the primary token is validated and can be redeemed; if not, the redemption is rejected. Notably, this verification is achieved without requiring any interactive handshake between parties or any realtime two-way protocol. By embedding a “double predictor” (i.e., reciprocal hash references in both Attorney Docket Number: TT-0003 tokens) at issuance, the integrity of the redemption process is ensured in a single blockchain transaction or operation, greatly simplifying and securing the redemption of tokenized obligations. In certain embodiments, redemption verification is a non-interactive, deterministic verification performed solely from on-chain commitments and metadata, without requiring any handshake, counterparty message exchange, or off-chain validation.

[0036] In another aspect (Embodiment B2), the invention provides a Multi -Attribute Metadata Access Control mechanism using tokens. In this embodiment, a non-fungible access token (an NFT designated to control access to a protected resource or service) contains metadata defining a set of required attributes for access. These attributes correspond to distinct attribute tokens that a user must possess simultaneously in order to gain access. For example, the access token’s policy metadata may specify that a user must hold: (i) a valid identity credential token (proving the user’s identity or membership status); (ii) a role or affiliation token (e.g., a token indicating the user’s role or permission level); and (iii) a time-restricted token or proof (ensuring that access is within an allowed time window). A decentralized verification process (which may be implemented by a smart contract on the blockchain or by a decentralized application or off-chain service) checks that the user’s blockchain address holds all of the required attribute tokens and that each token satisfies any specified condition (for instance, that the time-limited token is currently valid and not expired) before granting access. If any required attribute is missing or invalid, access is denied. This aspect of the invention essentially implements an on-chain, fine-grained attribute-based access control (ABAC) system using NFTs and fungible tokens, thereby achieving a form of decentralized multifactor authentication. Moreover, the access token’s metadata policy can be updated or the token can be revoked, allowing dynamic control over access rights. For example, an administrator could update the required attributes (or revoke the token entirely) if access rules change or a user’s privileges are revoked, and subsequent access attempts will automatically enforce the new policy. In some embodiments, access decisions are enforced by on-chain policy logic, whereby a smart contract evaluates possession of required attribute token(s) and authorizes or denies access without off-chain validation.

[0037] In yet another aspect (Embodiment B3), the invention provides a Cryptographic IOU Settlement Framework. In this embodiment, a programmable primary token (preferably a non-fungible token acting as a digital IOU or promissory note) is issued to a designated party to represent an obligation (for example, “pay $X to Alice under certain conditions”). The primary token includes rich on-chain metadata that defines a set of redemption conditions and associated Attorney Docket Number: TT-0003 payout instructions. The redemption conditions may include, among others: (a) jurisdictional compliance rules (e.g., restricting redemption to certain countries or requiring that the redeemer’s location be in an authorized jurisdiction); (b) KYC / AML identity requirements (e.g., the redeemer must present or be associated with a verified identity token of a certain level before redemption is allowed); (c) foreign exchange (FX) rate thresholds (e.g., if the obligation is payable in one currency but the payout is in another, the token might require that the exchange rate is above or below a certain threshold at the time of redemption, which is checked via an oracle feed); and (d) expiration or timing conditions (e.g., the token expires after a certain date or block number, after which it cannot be redeemed). The payout instructions typically specify the type and amount of value to be transferred upon successful redemption (for instance, “100 USD from Bank ABC to Alice’s account” or equivalently “100 USDC stablecoins to Alice’s wallet”). When the designated redeemer attempts to redeem this primary token, the system evaluates all the encoded conditions: it verifies compliance (for example, confirming the redeemer’s identity and jurisdiction via on-chain credentials or off-chain services), checks real-time data as needed (for example, retrieving current FX rates from a trusted oracle smart contract if a currency conversion condition is present), and ensures the token has not expired or been previously redeemed. Only if all conditions are satisfied will the system trigger the execution of the payout instructions. The actual settlement may be carried out via an integrated backend compliance platform or external system which is notified (for example, by a blockchain event or callback) to release the funds to the redeemer in accordance with the token’s instructions. The primary token thereby functions as a conditional IOU rather than a freely transferable bearer instrument - it effectively says “pay to the order of [authorized redeemer] under these specific conditions” and self-enforces those conditions through smart contract logic and cryptographic checks. Once redeemed, the token can be marked as redeemed or burned to prevent double redemption. This framework marries the trustlessness of blockchain tokens with the compliance controls of traditional finance, enabling automated yet regulated settlement of obligations.

[0038] Overall, these embodiments can operate together or independently, in whole or in part, within the broader tokenization system of the present invention. For example, the double-predictor token binding of Embodiment Bl may be utilized in Embodiment B3 to bind an IOU primary token to specific associated tokens that carry the promised funds, thereby ensuring that the obligated value cannot be altered or separated from the primary token without detection. Likewise, the multi -attribute access control of Embodiment B2 could be used to regulate who is authorized Attorney Docket Number: TT-0003 to redeem the primary token of Embodiment B3 (for instance, by requiring an identity token or other credentials), adding another layer of security. By introducing these mechanisms, the present Continuation-in-Part enhances the reliability, security, and versatility of the blockchain-based Web3 subdomain system described in the parent application. The technical solutions provided herein may address, in some embodiments, one or more of the identified gaps: they eliminate the need for interactive redemption handshakes by using reciprocal token commitments, enable complex on-chain authorization policies through multi-token requirements, and embed compliance and external data checks within the token redemption framework, thereby ensuring a tamper-proof and automated enforcement of conditions.

[0039] In one embodiment, a computer-implemented method cryptographically binds a blockchain-based primary token with one or more secondary tokens to ensure redemption integrity. That method comprises: causing to be issued, on a blockchain network, a primary token that includes metadata storing a first cryptographic commitment associated with an issuance context of at least one secondary token; causing to be issued, on the blockchain network, the at least one secondary token, each secondary token including a second cryptographic commitment associated with said primary token, wherein the first cryptographic commitment and the second cryptographic commitment are generated such that they form a mutual cryptographic binding between the primary token and the at least one secondary token.

[0040] In some embodiments of the foregoing method, the first cryptographic commitment and the second cryptographic commitment each comprise a hash value computed using a predetermined hash algorithm. In some embodiments of the foregoing method, the first cryptographic commitment encodes a commitment to a set comprising a plurality of secondary tokens. An additional step in the foregoing method may include verifying a redemption of the primary token by performing a non-interactive, deterministic verification based solely on on-chain commitments and metadata, without requiring any handshake, counterparty messaging, or off-chain validation. In some embodiments of the foregoing method, the primary token is a non-fungible token recorded on the blockchain network and the at least one secondary token comprises one or more fungible digital asset tokens recorded on the same blockchain network. In some embodiments of the foregoing method, the issuing of the primary token and the at least one secondary token is performed by a smart contract on the blockchain network. In some embodiments of the foregoing method, a smart contract will reject redemption of the primary token Attorney Docket Number: TT-0003 when a presented secondary token fails to satisfy a cryptographic commitment associated with the primary token.

[0041] In another embodiment, a computer-implemented method for enforcing multi-attribute token-based access control in an access policy for a protected resource comprises: causing to be issued, on a blockchain network, a non-fungible access token that contains metadata defining an access policy requiring possession of a plurality of distinct attribute tokens by a user, wherein the access token’s metadata is stored on-chain such that updates to the access policy or revocation of the access token are enforceable through blockchain transactions; receiving, from a user device, an access request for a protected resource; verifying, via a decentralized verification process, that a blockchain address controlled by the user holds the plurality of distinct attribute tokens required by the access policy; and upon verification, granting the user access to the protected resource.

[0042] In some embodiments of the foregoing method, each attribute token corresponds to a different required condition for access. An additional step in the foregoing method may include deriving a domain-subdomain token by reverse-parsing a fully qualified domain name and resolving the domain-subdomain token via a blockchain-based name service as part of the verification process. In some embodiments of the foregoing method, receiving the access request includes receiving a cryptographic proof of possession generated through a digital signature or zero-knowledge proof. An additional step in the foregoing method may include updating the metadata of the non-fungible access token to modify the access policy or to revoke the access token entirely, wherein subsequent access attempts will automatically enforce the updated access policy or prevent access if the token is revoked.

[0043] In another embodiment, a computer-implemented method for conditional settlement of a blockchain-based primary token comprises: causing to be issued, on a blockchain network, a primary token comprising metadata defining one or more redemption conditions and payout instructions, wherein redemption of the primary token is performed by a smart-contract on-chain wherein the smart-contract: receives a redemption request for the primary token; automatically verifies that each of the one or more redemption conditions is satisfied; and responsive to all redemption conditions being satisfied, triggers execution of the payout instructions.

[0044] In some embodiments of the foregoing method, the smart contract’s verification of the one or more redemption conditions comprises retrieving external data from a blockchain oracle. In some embodiments of the foregoing method, at least one of the one or more redemption conditions includes an identity verification requirement. In some embodiments of the foregoing method, at Attorney Docket Number: TT-0003 least one of the one or more redemption conditions includes an expiration time orblockchain block number after which redemption of the primary token is disallowed. In some embodiments of the foregoing method, the one or more redemption conditions include at least one of: (i) confirmation of a supply-chain event recorded by an Intemet-of-Things (loT) device, or (ii) verification of an environmental parameter recorded by an Internet-of-Things (loT) device. In some embodiments of the foregoing method, the one or more redemption conditions are satisfied in multiple stages recorded on-chain before execution of the payout instructions. In some embodiments of the foregoing method, triggering execution of the payout instructions causes a release of funds or assets through a bank, a payment rail, or a system external to the blockchain. In some embodiments of the foregoing method, the smart-contract’s automatic verification does not require an off-chain validation step.

[0045] BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Fig. 1 depicts a high-level system architecture diagram for an exemplary embodiment of the invention.

[0047] Fig. 2 depicts a first set of steps involved in an exemplary tokenization process.

[0048] Fig. 3 depicts a second set steps involved in an exemplary tokenization process.

[0049] Fig. 4 depicts an income transfer process for tokenized assets.

[0050] Fig. 5 depicts various embodiments of web3 domain-subdomain tokens.

[0051] Fig. 5A depicts various embodiments of web3 domain-subdomain tokens.

[0052] Fig. 6 depicts a high-level view of one embodiment of a tokenization process.

[0053] Fig. 7 depicts various steps of an exemplary embodiment of a web3 KYC tokenization process.

[0054] Fig. 8 depicts an exemplary embodiment of a web3 KYC subdomain token structure. Fig. 9 depicts an exemplary embodiment of a web3 KYC subdomain token structure. Fig. 10 depicts a schematic diagram illustrating an example Double-Predictor Token Binding mechanism, showing a primary token and one or more associated associated tokens each containing reciprocal cryptographic commitments, and a verification flow for token redemption in accordance with Embodiment Bl of the invention.

[0055] Fig. 11 depicts a block diagram of a Multi -Attribute Metadata Access Control system according to Embodiment B2, in which a non-fungible access token encodes a policy requiring multiple attribute tokens (such as an identity token, time-based token, and role token) for access, and a verification process (via smart contract or off-chain service) that checks the presence of all Attorney Docket Number: TT-0003 required tokens before granting access to a protected resource.

[0056] Fig. 12 depicts a flowchart depicting a Cryptographic IOU Settlement process as per Embodiment B3 of the invention. The figure illustrates the lifecycle of a primary token with conditional payout metadata: from issuance with embedded conditions (jurisdiction, KYC / AML, FX rate, expiration), through the redemption request by the designated redeemer, the evaluation of conditions (including oracle calls for exchange rates and identity verification checks), to the triggering of a compliant payout via an external settlement platform once all conditions are met.

[0057] FIG. 13 illustrates an embodiment of a condition-verification subsystem for the Primary Token redemption process.

[0058] Fig. 14 depicts an integrated embodiment combining reciprocal token binding, multiattribute access control, and conditional redemption checks.

[0059] DETAILED DESCRIPTION

[0060] Various embodiments of the present invention are described with reference to the attached figures herein. It should be understood that numerous specific details, relationships, and methods are set forth to provide an understanding of the invention. One skilled in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details or with other methods.

[0061] The present invention also relates to a blockchain-based system for securely managing the tokenization, certification, and transaction processes of real-world assets, digital assets, and verified identities. By integrating Web3 domain-subdomain tokens, distributed ledger technology (DLT), and Al-driven verification processes, the system helps ensure the immutability of smart contracts, protects client funds, and facilitates transparent asset management. This combination of technologies provides a secure and automated framework that enhances the efficiency and accuracy of managing real-world assets, both tangible and intangible.

[0062] Fig. 1 depicts a high-level system architecture diagram providing an overview of some components involved in an exemplary blockchain-based tokenization, certification, and asset management process. Item 100 is a facilitator’s internal system. The internal system has a client web interface 101, a blockchain interface 102, a public web interface 103, a web server 104, a database 105, and document processor system 108. Item 110 is a distributed blockchain. The distributed blockchain has a blockchain name service 111, a tokenizer’s wallet 112, a token buyer’s wallet 113, third party wallets 115, and a smart contract with tokens 114. Also shown is a tokenizer 106 and a token buyer 107. The assets may include physical and digital assets as well Attorney Docket Number: TT-0003 as identity verification. Also present in Fig. l isa Web3 know-your-customer (“KYC”) client 120 with a Web3 KYC blockchain wallet 121 associated therewith.

[0063] The public web interface may provide a website and various web services and / or an API for interacting with visitors seeking information from the facilitator’s internal system, as well as provide an internal interface and / or an API for the Internet 116 so that systems like the document processor system 108 may gather data from websites and web related services on the Internet 116.

[0064] The facilitator’s internal system may also have various security layers that help ensure that operations are protected. These layers may include encryption of sensitive data and multi-factor authentication (MFA) for access control, preventing unauthorized access and tampering.

[0065] The system may also employ advanced encryption protocols to ensure that document submissions and token generation are highly secure, maintaining data privacy throughout the certification process. Such encryption techniques safeguard sensitive information, preventing unauthorized access and ensuring the integrity of all data exchanges.

[0066] Fig. 2 depicts various steps involved in an exemplary tokenization process. (The related KYC verification process of Fig.7 may also be run in parallel or in series with this process of Fig.

[0067] 2.) In step 200, a tokenizer 106 enters asset parameters into a tokenization facilitator’s 100 internal system via a secured web2 data collection interface (e.g., the client web interface 101) for storage in database 105. Exemplary asset parameters may include but are not limited to:

[0068] • Asset Type

[0069] • Asset Value

[0070] • First Token Type

[0071] • Second Token Type

[0072] • Number of Tokens for Each Type

[0073] • Cost Per Token

[0074] • Tokenizer’s Wallet Address

[0075] • Certification Time Limit:

[0076] • Identification of Asset Owner

[0077] • Identification of Asset

[0078] • Legal Documentation References

[0079] A unique asset ID for the asset (e.g., US0000000000.ASSET01) is also created and stored in the database 105. This ID is used to track the asset through subsequent processes and is later used in connection with the verification token. Attorney Docket Number: TT-0003 In step 205, the tokenizer submits the appropriate transaction documents (e.g., asset ownership documents, identification documents, financial documents, contract documents, etc.).

[0080] In step 210, the facilitator’s internal system performs document verification against the asset parameters. The facilitator’s document processing system 108 utilizes Artificial intelligence (“Al”) and related technologies like Optical Character Recognition (OCR) to scan and digitize the documents uploaded by the Tokenizer to the extent needed for that document type. The facilitator’s document processing system 108 then uses Natural Language Processing (NLP) and Named Entity Recognition (NER) to identify and extract details such as the owner’s name, asset location, and serial numbers, and so forth. Extracted data is then cross-referenced by the document processing system 108 with the asset parameters provided by the Tokenizer to verify correctness and consistency. In some cases, this may be done manually.

[0081] In step 215, extracted data is compared against external authoritative databases (such as chain of title records at a county property website) to verify authenticity and ownership. This can be done via Al agents utilized by the document processing system 108 to gather web data, or through manual verification performed by humans. In some embodiments, both Al agents and manual verification are used. In a preferred embodiment, there is an optional manual audit 216 of Al generated verification results.

[0082] In step 220, if the verification process fails, then the tokenizer is notified of discrepancies and is invited to edit or resubmit the asset data and documentation whereafter the verification process is performed again. If the verification process is successful, then in step 225 the facilitator’s internal system updates the asset status in the facilitator’s internal system to “Verified,” and a subdomain ID token (e.g., US0000000000.ASSET01.XYZ) is generated. Note that the use of XYZ as a web3 top level domain label is arbitrary and exemplary herein. The domain label may or may not correspond to a web2 top level domain. Other top level domain labels may be used, for example, a company name, acronym, or trademark.

[0083] In step 230, in some embodiments, a binary quick reference (“QR”) code is generated by the facilitator’s internal system upon asset verification. The QR code uses 0’s and l’s (bits) to represent black and white pixels in a pixel frame, the bits create a scannable black and white QR code. The QR code is linked via a uniform resource locator (“URL”) to a web3 asset metadata reference page 231, created by facilitator and accessible through the public web interface 103, that incorporates the subdomain ID token (e g., https: / / example.eom / US0000000000.ASSET01.XYZ). When scanned, the QR code directs users to a webpage (e.g., Attorney Docket Number: TT-0003 https: / / example.eom / US0000000000.ASSET01.XYZ) provided through the public web interface 103 containing real-time asset information, such as verification status, token count, and smart contract details obtained from the blockchain through the blockchain interface 102 (in some embodiments, the web server 104 is able to directly read the blockchain or in other embodiments it utilizes a third-party API to do so, e.g., the Etherscan API).

[0084] In step 235, the facilitator creates a smart contract is created on the blockchain (e.g., Ethereum) using the various appropriate asset parameters. The subdomain ID token (e.g., US0000000000.ASSET01.XYZ)is added to the blockchain name service 111 by sending the token information to a smart contract (which in some embodiments may be controlled by the facilitator) within the blockchain name service 111 which creates the token within the blockchain name services and then creates and sends a corresponding token to the smart contract 114 on the blockchain 110 and the token is thereafter embedded into the smart contract 114. (The blockchain name service 111 is, for example, a name-lookup smart contract that provides a domain-to-smartcontract lookup table, e.g., the Ethereum Name Service, a domain name service built on the Ethereum blockchain. Other similar systems exist in, for example, the XDC “XinFin Digital Contract” network.) The QR code’s binary data is stored in connection with the smart contract on the blockchain, ensuring immutability and a tamper-resistant reference to the asset.

[0085] Utilizing a distributed blockchain enables the distributed recording of transactions across a decentralized ledger, ensuring transparency and immutability. The blockchain stores the history of asset-related transactions, token ownership, and certification records, making them accessible and verifiable by all parties involved. Utilizing a distributed blockchain also helps ensure that every transaction and ownership change is recorded on a decentralized ledger, providing a transparent, tamper-proof audit trail of all contract conditions and ownership histories. Decentralization eliminates single points of failure, significantly reducing the risk of unauthorized access or data manipulation. By storing ownership records across multiple nodes, the system ensures that transaction data remains secure, immutable, and accessible to all parties involved in the transaction. A distributed blockchain also enables real-time audits of ownership records, ensuring full transparency and promoting trust in the system.

[0086] The smart contract mints the appropriate number of tokens and makes them available for purchase through the smart contract. A token buyer 107 can purchase tokens for a specified price using native cryptocurrencies of the smart contract network or other supported cryptocurrencies (e.g., XDC, ETH, BTC, or stablecoins such as USDC or other bridged cryptocurrencies). Attorney Docket Number: TT-0003 As tokens are purchased, the smart contract holds the funds until certification, discussed later, is completed. While the tokenizer is heavily involved in the process steps shown in Fig. 2, different entities may be involved. For example, one person or entity might submit asset parameters, and a second entity (or multiple entities) may submit documentation for verification.

[0087] In some embodiments, the smart contract may mint multiple different types of tokens, each token having certain rights or features with respect to the transaction. For example, some tokens may provide preferential asset income distributions. Some tokens may provide certain voting rights. Some tokens may provide only asset ownership with no rights to income distributions.

[0088] Fig. 3 depicts various steps involved in an exemplary tokenization process. In step 300, a certification process (e.g., a process to verify the transfer or sale of the tokenized asset) begins with the tokenizer 106 indicating to the facilitator that a sale of the tokenized asset has occurred or will occur via a web2 data collection interface (e.g., the client web interface 101) for storage in database 105. The tokenizer 106 also submits the transaction parameters (such as buyer / seller names, transaction amount, proposed closing dates, and other details) and identifies documents to be submitted. In step 305, the tokenizer 106 submits digital copies of the appropriate closing documents (e.g., final sale contract, buyer’s and seller’s ID, deeds, etc.).

[0089] In step 310, the facilitator’s internal system performs document verification against the transaction parameters. The facilitator’s document processing system 108 utilizes Al and OCR to scan and digitize the documents uploaded by the Tokenizer to the extent needed for that document type. NLP and NER are then employed by the document processing system 108 utilizes to identify and extract the relevant details. The document processing system 108 then cross-references the extracted data with the transaction parameters to verify correctness and consistency.

[0090] In step 315, extracted data is compared against external authoritative databases (such as chain of title records at a county property website) to verify the transaction. This can be done via Al agents utilized by the document processing system 108 to gather web data, or through manual verification performed by humans. In some embodiments, both Al agents and manual verification are used. In a preferred embodiment, there is a manual audit 316 of Al generated verification results.

[0091] In step 320, if the verification process fails but is found to be recoverable (e.g., in the case of incomplete or incorrect documentation), then the tokenizer is notified of discrepancies and is invited to edit or resubmit the transaction data and documentation whereafter the certification verification process is performed again. If the verification process is successful, then in step 325 Attorney Docket Number: TT-0003 the facilitator’s internal system creates a certification domain-subdomain token (e.g., CERT_US0000000000.ASSET01.XYZ) and the token information is added to the blockchain name service 111 by sending the token information to a smart contract (in some embodiments, controlled by the facilitator) within the blockchain name service 111 which creates the token and sends the token to the smart contract 114 on the blockchain 110. In step 330, the receipt of the certification subdomain token triggers the smart contract 114 to release its stored funds to the tokenizer’s wallet 112, completing the transaction. (This destination wallet could also be set to an arbitrarily appropriate wallet or wallets such as those for co-owners, agents, brokers, tax agencies, title companies, and so forth.) After releasing funds, the status of the transaction associated with the smart contract is set to “Certified” in the facilitator’s internal system.

[0092] In step 335, after a successful completion of a sale, the smart contract becomes inactive after the asset is sold or transferred, helping to ensure that no further transactions can occur. After the sale is certified, the facilitator’s internal system generates a web3 closing domain-subdomain token (e.g., CLOSE_US0000000000.ASSET01.XYZ). The closing subdomain token is sent to the smart contract 114 on the blockchain 110 via the blockchain name service 111 as discussed earlier with respect to other subdomain tokens. Upon receipt, the smart contract 114 enters an inactive state and becomes flagged as closed on the website linked to by the smart contract’s QR code (and also in the facilitator’s internal system). In one embodiment, if any funds are sent to the contract after closure, the smart contract automatically returns them to the sender, thus largely disabling further interactions with the smart contract post-closure.

[0093] In step 340, if the certification’s verification process irrecoverably fails or the certification time limit (e.g., the certification time limit asset parameter) expires, one option is to void the smart contract and return funds to token buyers. In one embodiment, if certification is not completed within 30 days (or some other predefined timeframe), or otherwise irrecoverably fails, the facilitator’s internal system generates a web3 voiding domain-subdomain token (e.g., VOID_US0000000000.ASSET01.XYZ). The voiding subdomain token is sent to the smart contract via the blockchain name service 111 as discussed earlier with respect to other subdomain tokens, canceling the transaction.

[0094] In step 345, upon receipt of the voiding subdomain token, the smart contract returns funds to the token buyer’s wallet 113, and the tokens are recalled and / or burned. The facilitator’s internal system updates the asset’s status to “Voided” as would be reflected on the webpage linked to by the QR code and in the facilitator’s internal system. This voiding process helps ensure that no Attorney Docket Number: TT-0003 incomplete or failed transactions remain active, protecting all parties involved.

[0095] In some cases, an asset may generate ongoing income, for example, rental income or royalties. Fig.4 depicts an income transfer process for tokenized assets. In step 400, income from the asset (e.g., monthly rental payments) is generated. In step 410, funds (e.g., cryptocurrency) are transferred from a third-party wallet (or wallets) 115 into the smart contract 114. This may happen, for example, through renters sending funds directly to the smart contract 114 or via an asset manager or other third-party receiving rental payments in a national currency and then transferring corresponding funds in the form of cryptocurrency to the smart contract 114 on the blockchain 110. In some embodiments, the smart contract is configured such that only a wallet having a KYC subdomain token (discussed with respect to Fig.7) is permitted to send funds to the smart contract.

[0096] In step 420, the smart contract calculates each token buyer’s revenue share based on, for example, the token buyer’s ownership percentage of all of the smart contract’s 114 tokens. In step 430, the smart contract 114 distributes the income to the respective token buyer 107 wallets 115.

[0097] This process continues for each income event until the tokenization process is closed as discussed above. In some embodiments, the smart contract is configured such that only a wallet having a KYC subdomain token (discussed with respect to Fig. 7) is permitted to receive funds from the smart contract.

[0098] In some embodiments, funds received by the smart contract (that are not for the purchase of minted tokens) are added to the funds to be distributed to the tokenizer upon certification. In some embodiments, the funds are distributed to the token buyer(s) upon certification. The manner of calculating distributions may also vary based on the number of token buyers and the types of tokens minted by the smart contract.

[0099] Fig. 5 depicts various embodiments of web3 domain-subdomain tokens. Note that in web2, the top-level domain is sometimes called the “domain extension” and the combination of the second-level domain and an extension comprise a “domain name” such as google.com or supremecourt.gov. In web2, the top-level domain is generally inaccessible, meaning that “com” or “gov” standing alone will not resolve to an IP address. With respect to web3 domains, the combination of the top level domain / extension and the second level domain is often called a “primary domain” and the second-level subdomain simply “the subdomain”. For example, in typical web3 nomenclature, with respect to US0000000000.ASSET01.XYZ, the ASSET01.XYZ label can be considered to be a “domain” or “primary domain” with the US0000000000 label Attorney Docket Number: TT-0003 acting as the subdomain. Note also ERC-137’s definition of a domain and label:

[0100] <domain> ::= <label> | <domain> <label>

[0101] <label> ::= any valid string label per [UTS46]

[0102] However, the use of the word “label” herein is in the more general sense. Fig. 5A provides alternative nomenclature with respect to Fig.5 as discussed above. Various embodiments of Web3 domain-subdomain tokens include identifiers for physical assets (e.g., real estate) as well as digital assets (e.g., intellectual property) and identity (e.g., userl234.kyc.xdc).

[0103] In Fig. 5, the top or first level web3 domain is labeled XYZ (item 501). XYZ has various second level web3 subdomains, ASSET01 (item 502) and ASSET02 (item 503). These two web3 subdomains in this embodiment indicate an asset type, for example, ASSET01 corresponds to real estate, and ASSET02 corresponds to collectable coins. In some embodiments, the second level web3 subdomains could also have more specific labels with respect to the asset such as, such as AUTO or UNDEVELOPED LAND.

[0104] Each of these (502, 503) second level web3 subdomains have additional web3 subdomains underneath them, each of them a third level web3 subdomain (e.g., US0000000000 and VOID_US0000000000). By utilizing a web3 domain and two web3 subdomains, a web3 domainsubdomain token may be defined (e.g., US0000000000.ASSET01.XYZ and VOID_US0000000000.ASSET02.XYZ). For example, a web3 domain-subdomain ID token (items 502a, 503a), a certification web3 domain-subdomain token (items 502b, 503b), a void web3 domain-subdomain token (items 502c, 503c), and a closing web3 domain-subdomain token (items 502d, 503d).

[0105] Each web3 domain-subdomain token resolves to a single smart contract associated with that specific token. Not all third level subdomains can exist at the same time, for example, in this embodiment, simultaneous associations of a void and close web3 domain-subdomains tokens are mutually exclusive. These web3 domains and subdomains are present in the blockchain name service 111 which associates each third level subdomain with a specific smart contract 114 address. Each smart contract 114 also has its own list of subdomain tokens associated with it.

[0106] In one embodiment, the various web3 domain-subdomain tokens are generated with a unique ID that guarantees both its security and immutability in the blockchain name service 111.

[0107] This ensures that once the token is created and added to the blockchain name service, its correspondence to the designated smart contract address cannot be altered (assuming immutable blockchain name service records), providing a tamper-proof record of ownership and transaction Attorney Docket Number: TT-0003 details.

[0108] By knowing the name of the third level subdomain token, a user may utilize the blockchain name service 111 to find the corresponding smart contract 114. The blockchain name service 111 and / or the smart contract 114 may also be queried for the presence of a specific subdomain token (e.g., VOID_US0000000000.ASSET01.XYZ) and information about the lifecycle or state of the smart contract 114 inferred therefrom (e.g., a void subdomain token is present and therefore the smart contract and the transaction has been voided). Additionally, in some embodiments, funds may be sent to the smart contract using either the subdomain name (as opposed to the hexadecimal address of the smart contract), offering a user-friendly and human-readable option for income distribution.

[0109] While Fig. 5 depicts subdomain tokens as having a top level, a first level subdomain, and a second level subdomain, multiple levels of subdomains may be used. For example, USOOOOOOOOOO.MA.BOSTON.FENWAY.ASSETOEXDC might be used, where each of the USOOOOOOOOOO.MA.BOSTON.FEN AY subdomains are additional subdomains with geographic information utilized to indicate location information for a real-estate asset. And in some simplistic embodiments, only one subdomain may be utilized, e.g., US0000000000.XDC.

[0110] Fig. 6 depicts a high-level view of one embodiment of the tokenization process. At the Tokenization Initiation step 601, various aspects of the token and smart contract are initially defined. At the Verification step 605, the asset being tokenized is authenticated and the documents substantiating the asset parameters are verified against the asset parameters and external databases. At the Smart Contract Creation step 610, a smart contract corresponding to the asset is created and the subdomain ID token is associated with the smart contract. At the Token Minting step 620, the smart contract mints tokens and made available to token buyers. In some embodiments, token buyers are limited to those wallets that have a (generally or in some embodiments a specifically identified) KYC subdomain token associated therewith, ensuring that those who participate in the process are known to a service provider such as the tokenizer and / or other service providers like banks or cryptocurrency exchanges.

[0111] Next, an asset sale or transfer transaction is certified in step 630 (and a certification subdomain token is generated and associated with the smart contract) or voided in step 640 (and a void subdomain token is generated and associated with the smart contract which causes the smart contract to enter a void state). Income distribution step 650 happens repeatedly until the smart contract is closed in step 660. In some embodiments, income distribution is limited to those wallets Attorney Docket Number: TT-0003 having a (generally or in some embodiments a specifically identified) KYC subdomain token.

[0112] In some embodiments, token holders can resell their tokens on secondary markets, and the blockchain updates token ownership records accordingly. For example, token holders may list their tokens for resale on supported secondary markets or conduct peer-to-peer sales. Once the tokens are sold, in some embodiments, the smart contract updates ownership records to reflect the new token holders. Future income distributions or asset sale proceeds are then directed to the wallets of the new token holders, ensuring accurate record-keeping. This allows token holders to resell their ownership stakes while the blockchain maintains accurate ownership and income distribution records.

[0113] Detailed Use Cases

[0114] Various embodiments of the present invention are useful in certification processes and have broad applicability, making it ideal for industries requiring secure, immutable transactions. Sectors such as real estate, finance, legal, supply chain, intellectual property, and digital rights management can benefit from the system’s web3 subdomain token mechanisms and time-based voiding features.

[0115] The following example provides a step-by-step breakdown of the end-to-end process for tokenizing, verifying, certifying, and managing real-world assets (here, real estate) using a blockchain-based system. In this simplified example, a property owner wants to sell real estate to a set of one or more buyers via a tokenization process where the buyers will also be token owners / holders. A KYC process as discussed later with respect to Fig. 7 may also be incorporated into the example below.

[0116] Stage 1: Tokenization Initiation (Preliminary Data Staging). The process in a real estate tokenization and sale scenario starts with the Tokenizer (e.g., the property owner, but in other examples may be a party other than the property owner such as a property manager or a real estate agent) entering asset parameters into a web2 data collection interface (here the interface is controlled by the facilitator, a single company herein known as “TokenTEQ” which in this example mediates various steps in the asset tokenization process), including the asset type, value, and desired number and type of tokens to be issued.

[0117] In this example, the Tokenizer inputs one or more of the following asset parameters:

[0118] • Asset Type: Real estate, vehicle, artwork, digital identity, intellectual property, or other tangible and intangible asset classes, here in this example, real estate.

[0119] • Asset Value: $500,000 (e g., for the property at issue). Attorney Docket Number: TT-0003 • First Type of Tokens: ownership tokens.

[0120] • Second Type of Tokens: N / A.

[0121] • Number of Tokens for First Type: 1,000 tokens are to be issued, each token representing 0.1% ownership of the asset.

[0122] • Cost Per Token: Given an asset value of $500,000 and 1,000 tokens, each token is valued at $500. This will be the amount that buyers pay to purchase each token through the smart contract. (A price may also be specified in a stablecoin via bridging.)

[0123] • Owner’s Wallet Address: 0xl234A...C5678 (the wallet where funds will be sent post-certification).

[0124] • Certification Time Limit: 30 days from initiation.

[0125] • Identification of Property Owner

[0126] • Identification of Property

[0127] • Legal Documentation References: Property deed, vehicle title, artwork provenance, or other supporting documents. (This may include specifying the documents to be provided, and may also include an upload of the specified document in some embodiments.)

[0128] Aunique asset ID (e.g., US0000000000.ASSET01) is created and stored in the TokenTEQ internal system database. This ID is used to track the asset through all subsequent processes and will later be used in the subdomain ID token. Here, ASSET01 represents the asset class of real estate and the US0000000000 represents a unique ID corresponding to the real estate to be tokenized.

[0129] The asset details are held in a preliminary staging environment in the TokenTEQ internal system’s database. In some embodiments, no smart contract is created at this point so as to prevent premature contract creation and avoid potential resource wastage. This prevents the premature creation of smart contracts and avoids the risk of “zombie” contracts. This Stage 1 establishes the asset’s identity in TokenTEQ’s internal system, ensuring that necessary asset details are collected and verified before moving on to the smart contract creation stage.

[0130] Stage 2: Asset Verification (Authenticating Ownership and Asset Details). In this stage, the asset’s ownership and legitimacy are verified by TokenTEQ’s document processor system using a combination of Al-driven and / or manual processes to ensure that all information is accurate and up to date. The Tokenizer (or some other person or entity) submits digital copies of Attorney Docket Number: TT-0003 supporting documents (e.g., property deed, personal identification, property tax documents, etc.) through a secure, encrypted channel to TokenTEQ’s document processor system.

[0131] The TokenTEQ document processor system then uses artificial intelligence (“Al”) and related technologies like Optical Character Recognition (OCR) to scan and digitize the documents uploaded by the Tokenizer. Natural Language Processing (NLP) and Named Entity Recognition (NER) are then employed to identify and extract key details such as the owner’s name, asset location, serial numbers, and so forth.

[0132] Extracted data is then cross-referenced with the asset data provided by the Tokenizer, as well as external authoritative databases (such as chain of title records at a county property website) to verify authenticity and ownership. This can be done via the document processor system’s Al agents gathering web data, or through manual verification performed by humans. In some embodiments, both Al agents and manual verification are used.

[0133] If the documents are successfully validated against the information the Tokenizer provided as well as the authoritative databases, then the TokenTEQ internal system updates the asset status to “Verified,” and a subdomain ID token (e.g., US0000000000.ASSET01.TEQ) is generated. If verification fails, the Tokenizer is notified of any discrepancies and given an opportunity to fix them and present the asset for verification again.

[0134] Upon verification success, the subdomain token is added to a name-lookup smart contract in a blockchain name service that enables a domain-to-smartcontract lookup table (similar to the Ethereum Name Service, a domain name service built on the Ethereum blockchain). In this example, TokenTEQ uses its own wallet keys as the authoritative source to update the domain-to-smartcontract lookup table on the blockchain. At this stage, successful verification establishes the authenticity of the asset and enables the TokenTEQ system to proceed with smart contract creation.

[0135] Stage 3: Smart Contract Creation and Token Issuance. Upon successful asset verification, the TokenTEQ system creates a smart contract on the selected blockchain network, for example the Ethereum blockchain, and the smart contract mints tokens representing fractional ownership of the asset. In particular, the TokenTEQ system generates a smart contract on the blockchain, embedding the subdomain ID token as a reference. The smart contract then mints, in this example, 1,000 tokens, each representing 0.1% ownership of the asset. These tokens are initially stored in the smart contract. The tokens are listed for purchase through the smart contract. Buyers can purchase tokens for a specified price using supported native cryptocurrencies of the smart contract network or other supported cryptocurrencies (e.g., XDC, ETH, BTC, or stablecoins Attorney Docket Number: TT-0003 such as USDC or other bridged cryptocurrencies).

[0136] As tokens are purchased, the smart contract holds the funds until certification (discussed with respect to Stage 5) is completed.

[0137] Stage 4: Binary QR Code Generation and Blockchain Storage. In some embodiments, a binary quick reference (“QR”) code is generated by the TokenTEQ internal system upon asset verification in stage 2 above, using 0’s and 1 ’s to represent black and white pixels in a pixel frame, creating a scannable black and white QR code. The QR code is linked via a uniform resource locator (“URL”) to a webpage that incorporates the subdomain ID (e.g., https: / / example.eom / US0000000000.ASSET01.TEQ). The QR code’s binary data is stored in connection with the smart contract on the blockchain, ensuring immutability and a tamper-resistant reference to the asset.

[0138] When scanned, the QR code directs users to a webpage (e.g., example. com / USOOOOOOOOOO.ASSETOl.TEQ) containing real-time asset information, such as verification status, token count, and smart contract details obtained from the blockchain (in some embodiments, the server hosting the webpage is able to read the blockchain itself or utilizes a third-party API to do so).

[0139] Stage 5: Certification Process (Verifying Transaction and Ownership Transfer). In this stage, a certification process verifies the ownership transfer or sale of the actual real estate asset, confirming that the buyer(s) and seller have completed the transaction. The seller (the Tokenizer in this case, or in some circumstances the buyer or property manager or other appropriate party or parties) indicates to TokenTEQ that a sale of the tokenized real estate has occurred or will occur, submits the transaction meta data (such as buyer / seller names, transaction amount, proposed closing dates, and other details) and identifies documents to be submitted, and / or submits digital copies of the appropriate closing documents (e.g., final sale contract, buyer’s and seller’s ID, deeds, etc.) through the TokenTEQ web data collection interface. While the Tokenizer may specify the certification time limit in Stage 1, TokenTEQ itself may, in some embodiments, also specify a time-frame wherein the transaction must be completed.

[0140] Once the transaction meta data and documents have been provided, the document processor system uses Al and / or manual processes verify the closing documents against the internal data about the property and the metadata provided by the Tokenizer about transaction to ensure they match the verified asset details. Once the sale has been completed, TokenTEQ checks for any inconsistencies or errors and cross-references with authoritative external databases (e.g., Attorney Docket Number: TT-0003 government property records) to confirm ownership transfer. This may be done using Al web agents, via manual review, or both.

[0141] Upon successful verification of the sale or transfer, a certification subdomain token (e.g., CERT_US0000000000.ASSET01.TEQ) is generated and sent to the smart contract on the blockchain. The receipt of the certification subdomain token triggers the release of funds from the smart contract to the seller’s wallet, completing the transaction.

[0142] Stage 6: Automatic Voiding Mechanism (Handling Failed or Incomplete Transactions). If the certification process in stage 5 fails or the certification time (e.g., the Certification Time Limit in stage 1) limit expires, the goal is to void the transaction and the smart contract and return funds to token buyers. In this example, if certification is not completed within 30 days (or some other predefined timeframe), or otherwise fails, the TokenTEQ internal system generates a Web 3 voiding subdomain token (e.g., VOID_USOOOOOOOOOO.ASSETOLTEQ). The voiding subdomain token is sent to the smart contract, canceling the transaction, and putting the smart contract into a voided state.

[0143] Thereafter, upon receipt of the voiding subdomain token, the smart contract returns funds to the buyers, and the tokens are recalled and / or burned. The TokenTEQ internal system updates the token’s transaction’s status to “Voided” as would be reflected on the webpage linked to by the QR code. This voiding process helps ensure that no incomplete or failed transactions remain active, protecting all parties involved.

[0144] Stage 7: Closing Mechanism (Deactivating the Smart Contract Post-Sale). In this example, after the certification subdomain token is sent to the smart contract, and after transfer of ownership of the real estate by deed to the token holders, the token holders then choose to lease the real estate to tenants. The tenants pay their rent by sending funds to the smart contract each period of time (e.g., monthly). Those rental funds are then automatically distributed in proper proportion to each of the token holders’ wallets via the smart contract.

[0145] After a period of time, the token holders wish to sell the real estate. The TokenTEQ system receives and certifies the new buyer’s information and sale documents similar to Stage 5. Once certified, a closing token is created on the blockchain name service and thereafter a corresponding token is issued to the smart contract. This token modifies the smart contract to require token holders to send their tokens to the smart contract in order to get the sale proceeds and thereafter renders the smart contract inactive. After the successful completion of the sale (or transfer), the smart contract becomes inactive, helping to ensure that no further transactions can occur. Attorney Docket Number: TT-0003 In greater detail, after the sale is certified, the TokenTEQ system generates a web3 closing subdomain token (e.g., CLOSE_USOOOOOOOOOO.ASSETOl.TEQ) and registers it with the block chain name service (as with other subdomain tokens). The closing subdomain token is then sent to the smart contract on the blockchain. Thereafter, the smart contract becomes inactive and becomes flagged as inactive on the website linked to by the QR code.

[0146] Where the token buyer anticipates receiving funds from the smart contract, the closing subdomain token may change the smart contract income distribution from automatic to then requiring the buyer’s token(s) to be sent back to the smart contract in order to redeem the token for the funds. In this way, funds sent to the smart contract after the closing token is received are held until redeemed by transfer of the buyer’s token to the smart contract. In some scenarios, the new asset owner may opt to re-tokenize the asset, initiating a new tokenization process under a different subdomain, allowing for flexibility and reuse of the system.

[0147] Other Applications

[0148] The system’s adaptability allows it to be seamlessly integrated into existing digital infrastructures, providing a scalable solution for industries that handle high-value or sensitive transactions. It enhances the security of ownership verification, contract execution, and data integrity, making it a valuable tool for sectors that demand regulatory compliance and data protection, such as financial services and legal institutions.

[0149] Moreover, the system supports a wide range of assets and transaction types, allowing for the automation of rental income, royalties, or sale proceeds through smart contracts. The ability to send funds to the smart contract using either the subdomain name or the hexadecimal address adds significant flexibility and ease of use for participants across various industries. Additionally, the system facilitates the tokenization of digital identities and intellectual property, enabling secure, verified, and portable digital credentials for use across various platforms and applications.

[0150] For example, in the real estate sector, rental income from properties can be automatically routed to the smart contract via a user-friendly subdomain (e.g., rwal234. REALESTATE. xyz).

[0151] Similarly, in the intellectual property sector, royalties from licensed assets can be managed securely and efficiently using this method. This adaptability makes the system highly useful for industries involved in leasing, licensing, or any revenue-generating assets, whether tangible or intangible. Similarly, in some embodiments, virtual-world assets (including but not limited to game skins, game characters, website or game accounts, virtual real estate, etc.) may also be tokenized. Attorney Docket Number: TT-0003 The decentralized nature of the system, combined with its use of Distributed Ledger Technology (DLT) and blockchain, helps ensure that all transactions are secure, transparent, and tamper-proof. The system’s features, including multi -factor authentication and encryption protocols, provide enhanced protection for ownership records, contract data, and financial transactions, making it an indispensable tool for industries focused on security and compliance.

[0152] With its flexibility, the system can be customized to meet the specific certification and transaction needs of various industries, making it a key solution for organizations looking to modernize their digital certification processes and automate the secure management of assetgenerated income. Additional embodiments of the present invention are considered below.

[0153] Real Estate Tokenization

[0154] The system can be adapted to handle the tokenization of real estate assets, enabling fractional ownership of properties through a secure and transparent process. Utilizing Al-driven document verification, the system ensures that property details, ownership records, and legal documents are accurately represented before the asset is tokenized. Ownership tokens are generated and linked to asset-specific subdomains (e.g., ADDRESS1234. REALESTATE. XYZ), creating a unique digital identifier for each tokenized property.

[0155] For real estate assets that generate ongoing income (e.g., rental income or lease payments), the smart contract automatically calculates and distributes revenue to token holders based on their ownership share. Income or sale proceeds are directed to the smart contract, and payouts can be made using the asset’s subdomain name for user-friendly transactions. The system also supports the resale of tokens on secondary markets, with the smart contract updating ownership records in real-time, ensuring full transparency and traceability of property ownership.

[0156] Vehicle Tokenization and Transfer

[0157] The system can be adapted to facilitate the secure tokenization and transfer of vehicle ownership, covering a wide range of assets such as cars, boats, and aircraft. Using verified documents (e.g., VINs for cars, hull numbers for boats, tail numbers for aircraft), the system conducts Al-driven verification to confirm the asset’s identity and ownership. Once verified, a subdomain token is created (e.g., AUTO1234.VEHICLE.XYZ), serving as a unique, tamper-proof digital representation of the vehicle on the blockchain.

[0158] Ownership transfers are streamlined through the use of certification tokens, which automatically trigger the release of funds and update the ownership record on the blockchain. Compliance is ensured through a KYC verification process using Decentralized Identifiers (DIDs), Attorney Docket Number: TT-0003 linking verified user identities to the transaction. This approach provides a transparent, secure framework for vehicle ownership tracking, enabling efficient transfers while reducing the risk of fraud and enhancing regulatory compliance. The immutable blockchain records ensure that all parties can verify the vehicle’s ownership history, offering a trusted, verifiable audit trail.

[0159] Intellectual Property and Digital Rights Management

[0160] The system can be adapted to facilitate the tokenization of intellectual property (IP) assets, including patents, copyrights, and trademarks. Through a secure verification process, the system confirms the ownership and validity of the IP asset before creating a digital representation on the blockchain. Verified TP assets are linked to unique subdomains (e.g., CONTENTOOl. DIGITAL. XYZ), providing a traceable and tamper-proof identifier for each tokenized asset.

[0161] For IP assets that generate ongoing revenue (e.g., licensing fees or royalties), the smart contract automates the distribution of payments to IP holders. The smart contract tracks usage and income events, calculating the appropriate share for each token holder. Payments can be directed through the subdomain, simplifying financial transactions while ensuring transparency and accuracy. The system’s immutable record-keeping provides IP holders with a clear, verifiable audit trail of income distribution, enhancing trust and efficiency in digital rights management.

[0162] Digital Identity Verification and DID Services

[0163] The system supports robust digital identity verification using a Web3 KYC process combined with Decentralized Identifiers (DIDs). Users undergo a secure KYC process where their personal information and identification documents are verified through Al-driven analysis or third-party verification services. Upon successful verification, a unique DID is issued and linked to the user’s identity subdomain (e.g., userl234.KYC.XYZ). This tokenized digital identity is securely stored on the blockchain, providing a verifiable and tamper-proof identity reference.

[0164] The verified identity can be utilized across multiple platforms, offering seamless crossplatform interoperability without the need for repeated KYC verification. By leveraging DIDs, the system ensures that users can securely interact with a variety of services, such as financial applications, digital asset platforms, and regulatory-compliant transactions. This approach enhances privacy, reduces onboarding friction, and strengthens compliance with regulatory requirements, while providing a consistent and trusted framework for identity verification in the digital ecosystem.

[0165] Artwork and Collectibles Tokenization Attorney Docket Number: TT-0003 The system can be adapted to facilitate the tokenization of high-value artwork and collectibles, applying Al-driven and / or manual verification processes to confirm ownership and provenance of assets such as paintings, sculptures, and rare collectibles. Once the verification process is complete, a unique subdomain token is issued (e.g., ART1234.FINEART.XYZ) and linked to the artwork’s smart contract, creating a secure, tamper-proof digital record that captures ownership history, provenance, and any rental agreements directly on the blockchain.

[0166] For artworks that generate income (e.g., rental fees from museum exhibitions or proceeds from sales), the system automates the collection and distribution of payments to token holders. Funds are deposited into the smart contract and allocated based on each holder’s fractional ownership share. Transactions are facilitated through the artwork’s subdomain (e.g., artl23.FINEART.XYZ), simplifying the process while ensuring full transparency in financial distributions. This approach provides a verifiable, immutable audit trail of both ownership and income events, significantly enhancing trust, liquidity, and the overall efficiency of investments in the art market.

[0167] Equipment Leasing and Asset Management

[0168] The system can be adapted to manage the tokenization and leasing of specialized equipment, such as medical devices, industrial machinery, and heavy equipment. By verifying ownership and condition through Al-driven analysis, the system securely tokenizes the asset, linking it to a unique subdomain identifier (e.g., EQUIP1234. INDUSTRIAL. XYZ). This digital representation provides a tamper-proof record of the asset’s details, facilitating transparent management and ownership tracking.

[0169] For equipment that generates leasing income, the smart contract automates the collection and distribution of payments to token holders based on their ownership percentage. Lease agreements are executed securely via smart contracts, reducing the risk of disputes and ensuring timely payments. The use of asset-specific subdomains simplifies income transactions and provides real-time updates on leasing activity, allowing stakeholders to monitor equipment utilization, income flow, and ownership changes with full transparency and traceability on the blockchain.

[0170] Supply Chain and Inventory Tokenization

[0171] The system can be adapted to facilitate the tokenization and tracking of products throughout the supply chain. Using secure verification processes, each product is assigned a unique subdomain token (e.g., PRODUCTOOl.SUPPLYCHAIN.XYZ), linked to a Decentralized Attorney Docket Number: TT-0003 Identifier (DID) and verified metadata. This tokenization creates a digital representation of the product on the blockchain, providing a tamper-proof, traceable record of its lifecycle.

[0172] The system offers real-time transparency and visibility into product movement across the supply chain, with each transaction and status update recorded immutably on the blockchain. Scannable QR codes linked to the subdomain allow stakeholders to verify the product’s authenticity and access detailed metadata instantly. This approach enhances trust and accountability by ensuring that all parties have access to a secure, verifiable audit trail, streamlining supply chain operations and reducing the risk of fraud or counterfeit products.

[0173] Event Ticketing and Fundraising

[0174] The system can be adapted to facilitate the tokenization of event tickets and fundraising initiatives. Through a secure issuance process, the system creates digital tickets as unique, verifiable assets on the blockchain. Verified tickets are linked to distinct event subdomains (e.g., EVENTOO 1. TICKET S.XYZ), providing a traceable, tamper-proof identifier for each tokenized ticket.

[0175] For events generating revenue (e.g., ticket sales, donations), the smart contract automates the distribution of funds to organizers and investors. The smart contract tracks ticket sales and revenue events, calculating the appropriate share for each stakeholder. Payments are directed through the event subdomain, simplifying financial transactions while ensuring transparency and accuracy. The system also supports ticket resale on secondary markets, with real-time updates to ownership records, preserving accuracy and traceability.

[0176] Additionally, QR codes linked to the subdomain offer secure access control, allowing efficient entry verification at the event. This approach enhances the ticketing process by preventing counterfeiting, streamlining transfers, and ensuring transparent revenue sharing, delivering a secure and seamless experience for organizers and attendees alike.

[0177] Web3 Know Your Customer

[0178] In another embodiment, a web3 primary domain (e.g., KYC.XYZ) is designed for identity verification purposes. A facilitator may generate a unique subdomain for each client or user who passes know-your-customer (“KYC”) verification, creating a decentralized identifier (DID) that tokenizes the verified digital identity. This web3 KYC subdomain token may then become an asset that the facilitator may then manage, control, or update. This DID can be linked to the customer’s wallet on a blockchain and used for cross-platform verification in asset transactions.

[0179] This KYC feature helps ensure client identity verification through a secure and compliant Attorney Docket Number: TT-0003 process before clients participate in transactions. Client identity may be verified either through internal Al-driven methods or by using a third-party verification service. Once verified, a subdomain token representing a KYC-verified wallet is created for each client. This token enhances security, data privacy, and cross-platform interoperability by establishing a reusable, blockchain-based verification standard for clients’ digital identities. In some embodiments, the existence of a KYC subdomain token may be a requirement written into the smart contract before that smart contract will allow the wallet to participate in transactions involving tokenized real-world assets (“RWAs”).

[0180] Fig. 7 depicts various steps of an exemplary embodiment of a web3 KYC tokenization process integrated with exemplary embodiments in Fig. 1 and / or Fig. 2. This process may, for example, run in parallel with a tokenization process and run in parallel with asset verification. It may also stand alone as a KYC tokenization process without any related asset tokenization process.

[0181] In step 700, an individual to be verified enters their identity and other parameters into a tokenization facilitator’s internal system via a secured web2 data collection interface (e.g., via a client web interface) for storage in a database. This may be similar to a registration form. Exemplary identification parameters may include but are not limited to:

[0182] • Name

[0183] • Date of Birth

[0184] • Email

[0185] • Phone number

[0186] • Address

[0187] • Wallet Details

[0188] • First Type of ID

[0189] • First ID Number

[0190] • First ID Details

[0191] • Second Type of ID

[0192] • Second ID Number

[0193] • Second ID Details

[0194] • Bank Details

[0195] • Family Details

[0196] • Employment Details

[0197] • Corporation Details (e.g., if the client is a corporation as opposed to an individual) Attorney Docket Number: TT-0003 At this time (or perhaps later after verification is successful) a unique KYC ID for the user (e g., USER1234.KYC.XYZ) is also created and stored in the database and associated with the client. This ID is used to identify the user and is later used in connection with the KYC subdomain token.

[0198] In step 705, the user submits the appropriate identification and related documents (e.g., copies of passport, drivers license, social security or tax identification number, and so forth). In some embodiments, real time image and / or video may be acquired from the client.

[0199] In step 710, the facilitator’s internal system performs document verification against the identity parameters. The facilitator’s document processing system utilizes Artificial intelligence (“Al”) and related technologies like Optical Character Recognition (OCR) to scan and digitize the documents uploaded by the user to the extent needed for that document type. The facilitator’s document processing system then uses Natural Language Processing (NLP) and Named Entity Recognition (NER) to identify and extract details such as the user’s name, document type and identification numbers, tax identification or social security numbers, and so forth. Extracted data is then cross-referenced by a document processing system with the identification parameters provided by the user to verify correctness and consistency. In some cases, this may be performed manually.

[0200] In step 715, extracted data is compared against external authoritative databases (such as third-party credit agencies, government databases, etc.) to verify document authenticity and user details. This can be done via Al agents utilized by the document processing system to gather web data, or through manual verification performed by humans. In some embodiments, both Al agents and manual verification are used. In a preferred embodiment, there is an optional manual audit 716 of Al generated verification results.

[0201] In some embodiments, the user / client provides their own wallet address for verification. In such a case, the user may be asked to transfer a specified (typically small) amount of cryptocurrency to a specified address (and sometimes within a specified period of time) as part of the verification process to confirm that the user controls the wallet. In some embodiments, the facilitator will create a new wallet and provide the keys to the client, thus ensuring that the wallet is controlled by the client.

[0202] In step 720, if the verification process fails, then the user is notified of discrepancies and is provided options to edit or resubmit the identity parameters and / or documentation whereafter the verification process is performed again in whole or in part. If the verification process is successful, then in step 725 the facilitator’s internal system updates the user’s status in the Attorney Docket Number: TT-0003 facilitator’s internal system. The KYC subdomain token information (e.g., USER1234.KYC.XYZ) is then added to the blockchain name service by sending the token information and the client’s wallet information to a smart contract (in some embodiments, controlled by the facilitator) within the blockchain name service which creates the KYC subdomain token within the blockchain name service, associates the wallet address with the KYC subdomain token, and then (optionally) creates and sends a corresponding wallet -receivable KYC subdomain token, having the KYC subdomain token information therein, to the wallet address on the blockchain.

[0203] The information associated with the KYC subdomain token is stored securely and referenced by the tokenizer’s system to confirm the client’s identity across platform transactions. Thus in some embodiments, the KYC subdomain token provides a blockchain-based identity reference that ensures only verified users participate in smart contract transactions, enhancing platform security and regulatory compliance.

[0204] This KYC subdomain token may also, in some embodiments, be a requirement for a wallet to purchase, sell, or receive income from asset tokens, or interact with a smart contract generally. For example, a smart contract could have conditional instructions requiring that any wallet interacting with the smart contract have a KYC subdomain token associated therewith in order to send or receive funds to that smart contract or to provide data to that smart contract. Proposed transactions from wallets without a KYC subdomain token associated therewith would have their transactions reversed or rejected.

[0205] In step 730, in some embodiments, a binary quick reference (“QR”) code is generated by the facilitator’s internal system upon identification verification. The QR code uses 0’s and l’s (bits) to represent black and white pixels in a pixel frame, the bits create a scannable black and white QR code. The QR code is linked via a uniform resource locator (“URL”) to a web3 asset metadata reference page 731, created by facilitator and accessible through the public web interface which incorporates the KYC subdomain token (e.g., https: / / example.com / USER1234.KYC.XYZ). When scanned, the QR code directs users to a webpage (e.g., https: / / example.com / USER1234.KYC.XYZ) provided through a public web interface containing real-time identity information. The website may have a “KYC Verified” badge or icon thereon to indicate a verification status (which may be full, partial, or some defined class of verification).

[0206] That information may include those specific details provided by the user and wallet details obtained from the blockchain through a blockchain interface (in some embodiments, the web Attorney Docket Number: TT-0003 server is able to directly read the blockchain or in other embodiments it utilizes a third-party API to do so, e.g., the Etherscan API). This may enable third-parties to obtain and / or verify all or a portion of the client’s identifying information.

[0207] Fig. 8 depicts an exemplary embodiment of a web3 KYC subdomain token structure. In the depicted embodiment, the KYC subdomain token has the form of USER1234.KYC.XYZ 802a, where USER1234 is a client identifier, KYC is a subdomain and the label indicates the KYC nature of the subdomain token, and XYZ 801 is a top-level domain (sometimes referred to as a domain extension). In this example, a tokenizer controls the web3 primary domain “KYC. XYZ” 802 (which itself is also a token) and is able to issue KYC subdomain tokens (802a - 802d) for “KYC. XYZ”. The tokenizer verifies through a KYC process its clients who want to engage in transactions on the blockchain. Once verified (e.g., through a process like Fig. 7) the tokenizer issues the KYC subdomain token for the client, e.g., USER1234. KYC. XYZ, and sends the KYC subdomain token to the wallet address on the blockchain. In some embodiments, the top level domain / extension may indicate the tokenizer or other service provider’s identity e.g., USER1234.KYC.WORLDWIDEMEGABANK.

[0208] Fig. 9 depicts an exemplary embodiment of a web3 KYC subdomain token structure. In the depicted embodiment, the KYC subdomain token has the form of USER1234.GLOBAL_INSTITUTION.KYC 902a, where USER1234 is a client identifier, GLOBAL INSTITUTION is subdomain and the label is a service provider identifier, and KYC 901 is a top-level domain indicating the KYC nature of the token. In this example, a bank controls the web3 primary domain “GLOBAL INSTITUTION.KYC” 902 and is able to issue KYC subdomain tokens (902a - 902d) for “GLOBAL INSTITUTION.KYC”. The bank verifies through a KYC process its clients who want to engage in transactions on the blockchain. Once verified (e.g., through a process like Fig. 7) the bank issues the KYC subdomain token for the client, e.g., USER1234.GLOBAL_1NST1TUT1ON.KYC, and sends the KYC subdomain token to the wallet address on the blockchain.

[0209] In some embodiments, the KYC subdomain token is unique to the client, e.g., USER1234.GLOBAL_INSTITUTION.KYC. In other embodiments, the KYC subdomain token may be generic or indicate a certain level of KYC process, e.g. FULLY VALIDATED. GLOBAL INSTITUTION.KYC or PARTIALLY VALIDATED. GLOBAL INSTITUTION.KYC.

[0210] While Figs. 8 and 9 depict KYC subdomain tokens as having a top level, a first level Attorney Docket Number: TT-0003 subdomain, and a second level subdomain, multiple levels of subdomains may be used. For example, USER1234.US.NA.GLOBAL_INSTITUTION.KYC might be used, where each of the subdomains US.NA are additional subdomains utilized to give location information for a the client. And in some simplistic embodiments, only one subdomain may be utilized, e.g., USER1234.GLOBAL INSTTTUTION or USER1234.KYC.

[0211] This KY C subdomain token informs other blockchain users that the specific wallet address is associated with a person or entity whose identity is known by, and verified by, the bank. A corresponding QR code may also provide blockchain users with additional access to the client’s identifying information in some cases. Smart contracts may be configured so as to only interact with wallets whose KYC subdomain token has been issued by a certain entity, or who have a specific subdomain token.

[0212] The description and drawings of foregoing systems provide context for the discussion that follows. In particular, a secondary token is associated with, and subordinate to, a primary token within the hierarchy of the system. As explained above, hierarchical relationships are expressed in terms of a primary domain and subordinate subdomains. In this continued discussion, the same hierarchical relationship is expressed using a primary token and one or more secondary tokens, which correspond respectively to the primary domain and subdomains noted earlier, and the mechanisms described herein operate as extensions and enhancements of that framework. In some embodiments, the primary token, secondary tokens, access tokens, or attribute tokens may embed, reference, or resolve a subdomain identifier, consistent with the subdomain-based framework just discussed.

[0213] While blockchain technology and smart contracts have enabled tokenization of assets and enforcement of certain rules, several shortcomings remain in existing token-based systems. First, ensuring the integrity of token redemption or exchange events typically requires interactive protocols or trusted intermediaries. For instance, in many cryptocurrency payment or swap scenarios, parties rely on hash-time-lock contracts (HTLCs) or multi -signature escrow arrangements to ensure that an asset (or payment) is only released when the correct counter-value is provided. These approaches introduce complexity and often require a real-time handshake between parties (such as HTLCs, state channels, multi-sig coordination, Layer-2 interactive commitment schemes). No known existing blockchain platform links a non-fungible “instruction” (also called a “primary” token) token with its fungible associated tokens (sometimes called secondary tokens or value tokens) through mutual cryptographic commitments that allow one-step, Attorney Docket Number: TT-0003 deterministic verification of a correct pairing at redemption. In other words, current systems lack a direct token-to-token binding that would let a redeemer prove that the tokens presented exactly match the original tokenized obligation without resorting to an interactive challenge-response protocol. This gap means there is potential for either fraudulent redemption (if tokens can be swapped or tampered with) or increased reliance on centralized matching systems.

[0214] Second, existing token-based access control mechanisms are typically limited to singletoken gating and do not support multi-factor or multi-attribute authorization on-chain. It is known in the Web3 space to use a single non-fungible token (NFT) as a “key” to grant access to a digital resource (for example, holding a particular NFT might grant access to a website or exclusive content). However, these solutions perform only a simple ownership check of one token. There is currently no standard method to require a user to possess multiple distinct tokens or credentials simultaneously as a condition for access. Traditional access control systems outside of blockchain might use multiple factors (such as an identity verification plus a time-based passcode), but in decentralized token systems this has not been achieved in a trustless manner. In practice, if a resource owner wants to enforce that a user is, for example, both a verified member of a certain group and accessing within a certain time window, they would have to rely on off-chain checks or custom logic. There is a need for an on-chain multi-attribute access control mechanism whereby an NFT can encode complex access requirements (like possessing an identity token, a role token, and a time-limited token) and have those requirements automatically checked by smart contracts before granting access. Such a mechanism would bring the benefits of fine-grained, cryptographically enforced access control to decentralized applications, which is not possible with single-token gating approaches.

[0215] Third, current blockchain token systems do not adequately address conditional settlement of tokenized lOUs with integrated compliance checks. Cryptocurrencies and stablecoins allow digital representations of value, but they function as bearer instruments — any holder of the token can typically redeem or transfer it, and conditions on redemption (if any) are enforced off-chain by institutions. Security token platforms (for regulated assets) add some on-chain restrictions (for example, whitelisting certain addresses or enforcing transfer rules based on regulations), but even these focus on controlling transfers or ownership, not the specific conditions under which an underlying obligation is paid out. As a result, there is no widespread mechanism for a tokenized IOU (i.e., a blockchain token representing a promise of payment or obligation) that carries enforceable, programmable conditions such as who may redeem it, when it can be redeemed, Attorney Docket Number: TT-0003 where (jurisdictionally) it can be redeemed, and under what external parameters (e.g., foreign exchange rates or compliance approvals). For example, conventional stablecoins (like fiat-pegged tokens) can be redeemed by anyone holding them and do not encapsulate user-specific or contextspecific rules. If an organization wanted to issue a digital promissory note that says “Pay $X to Alice if and only if certain compliance checks pass and before a certain date,” there is no standard token solution to do so. In existing systems, these kinds of conditions would be enforced manually or via centralized databases and legal contracts, negating the advantages of blockchain automation. Thus, a need exists for a cryptographically enforced IOU settlement framework where a primary token (for example, a non-fungible token representing an obligation) carries embedded conditions — such as identity of the redeemer, jurisdictional limits, compliance requirements, exchange rate thresholds, and expiration — governing its redemption, and where settlement can occur automatically once those conditions are verified. Accordingly, the present invention introduces various technical solutions to address one or more of these needs.

[0216] Embodiment Bl: Double-Predictor Token Binding Mechanism Referring now to FIG. 10, an exemplary Embodiment Bl of the invention is directed to a double-predictor token binding mechanism for ensuring the integrity of tokenized value redemption. In this embodiment, a primary token (1002 in FIG. 10) is issued on a blockchain network to represent a particular instruction or promise - for example, an IOU, a voucher, or a receipt that will be redeemed for some value. The primary token 1002 is preferably implemented as a non-fungible token (NFT) recorded on the blockchain, uniquely identifying the obligation or entitlement. Along with issuing the primary token, one or more secondary tokens or associated tokens 1004 are also issued or designated on the blockchain. The secondary or associated tokens 1004a-d represent the actual transferable value or asset that is tied to the primary token (for instance, they could be a certain number of fungible cryptocurrency tokens, a digital voucher amount, or other tokenized value). Critically, each associated token 1004 is cryptographically bound to the primary token 1002 by way of embedded commitments: the primary token’s metadata contains a first cryptographic commitment (e.g., a secure hash) to the associated token(s)’ unique identifier or content (issuance context), and each associated token’s metadata contains a second cryptographic commitment (e.g., a hash) referencing the primary token. These commitments are generated such that they correspond to each other (for example, the hashes may be of each other’s identifiers or of a common secret), thereby forming a mutual binding between the instruction and associated tokens. For example, Attorney Docket Number: TT-0003 C I = H("I" || chain_id || contract_addr || l id || S || MR_V)

[0217] C_Vi = H("V" || chain_id || contract_addr || V_i_id || S || l id)

[0218] Where H(...) is a secure one-way hash function (e.g., SHA-256). The prefix "I" or "V" denotes the token type. The inputs are:

[0219] chain id - blockchain network identifier

[0220] contract addr - issuing smart contract address

[0221] l id - primary token’s unique identifier

[0222] V_i_id - associated token’s unique identifier (for each associated token i)

[0223] S - a 256-bit random salt generated at issuance (adds unpredictability and collision resistance)

[0224] MR V - Merkle root of the associated token set, computed over a sorted list of all associated token identifiers or descriptors in the issuance. (If the associated tokens are fungible or represent account-based allocations rather than distinct token IDs, each Merkle leaf can be a tuple of token type, account, and amount.)

[0225] Once the primary token 1002 and associated token(s) 1004 are issued with their respective commitments, the system can later verify a redemption attempt in a single step. At issuance, an event is emitted (e.g., Issued(I_id, MR_V, H(S))) recording the primary token’s ID, the Merkle root MR V of the associated tokens, and a hash of the salt S. The hash H(S) is stored on-chain while S remains secret until redemption. Upon redemption, the verifier checks the stored anchor and validates H(S) before recomputing the commitments. Specifically, when a redeemer (e.g., “Alice”) wishes to redeem the primary token 1002 for the promised value, she presents the primary token along with the associated associated token(s) 1004. A smart contract or verification algorithm then performs a deterministic check: it compares the commitment stored in the primary token 1002 to data derived from the presented associated token(s) 1004 (such as each associated token’s unique ID), and it compares the commitment stored in each associated token 1004 to data derived from the primary token 1002 (such as the primary token’s own identifier). If and only if both comparisons match — meaning the commitments correspond — the system concludes that the provided associated token(s) are exactly those originally bound to the primary token, and thus the redemption is valid. If verification fails, the primary token is not consumed or burned, remaining available for a later attempt. Upon successful verification, the smart contract in the same transaction marks the primary token as redeemed (or bums it) to prevent reuse, while releasing the associated value. Attorney Docket Number: TT-0003 This one-step redemption verification contrasts with prior approaches that might require interactive steps or external oracles to match tokens. By embedding the “double-predictor” commitments at issuance (each token effectively predicting the identity of the other), the need for a live challenge-response or third-party confirmer is eliminated. This improves security by preventing fraudulent token swaps, and it increases efficiency by allowing automatic on-chain verification of correct token pairing without off-chain intervention or delay. Front-running or duplication does not help because verification is one-shot against pre-committed values; only the exact bound tokens pass.

[0226] Embodiment B2: Multi-Attribute Metadata Access Control Embodiment B2, illustrated in FIG. 11, introduces a system for enforcing complex access control policies using tokenized attributes. In this embodiment, an access token (2002 in FIG. 11) is implemented as an NFT on a blockchain and encodes within its metadata a policy that specifies multiple required attributes for access to a resource. For example, the access token’s metadata might indicate that a user must hold an identity credential token 2004, a role token 2006, and a time-based token 2008 (such as a valid membership token), as well as one or more additional tokens 2010 simultaneously in order to access a particular service or dataset.

[0227] When a user attempts to access the protected resource, they must present proof (either on-chain or off-chain) of possession of all the required attribute tokens. In one implementation, the user’ s blockchain address is checked for ownership of the necessary tokens. A smart contract 2020 or decentralized application can inspect the blockchain state (e g., using standard token balance calls for NFTs or fungible tokens) to confirm that the user’s address holds the required tokens. If the verification involves an off-chain component (for example, the user’s device or browser providing signatures or proofs), the system might require the user to provide a cryptographic proof of possession for each token. This could be done by having the user cryptographically sign a challenge using the private key of the address that holds the token, thereby proving they control that address. Alternatively, zero-knowledge proof techniques could be used for the user to prove ownership of required tokens without revealing which specific address holds them (for privacy reasons). For simplicity, in many cases possession can be proven just by demonstrating control of the address, with the trust that the verifying smart contract will only grant access to that address once verified.

[0228] In summary, Embodiment B2 transforms a simple single-token gate into a multi -attribute gate, enabling fine-grained access control on-chain. This approach advantageously removes the Attorney Docket Number: TT-0003 need for centralized access management systems by leveraging tokenized credentials that are verifiable on a blockchain. It provides enhanced security (since multiple independent factors are required, the compromise of one token or credential alone does not grant access), and it offers flexibility and composability (the access policy can be composed of any combination of tokenized attributes, and these requirements can be changed or updated as needed).

[0229] Embodiment B2 can be extended or varied in various implementations. For instance, certain implementations might enforce that the attribute tokens themselves meet specific criteria (e g., an identity token must be issued by a trusted authority and not be expired, or a time-based token must represent the current valid time window). The access token’s metadata could also be updated over time to change requirements or to revoke access entirely. Such modifications can be performed by authorized parties (like the resource owner or a governance smart contract), thereby allowing dynamic policy control. The framework thus provides both a robust on-chain verification mechanism for multi -attribute requirements and a maintenance mechanism for evolving access policies.

[0230] Reverse Parsing Embodiment: In some embodiments, the system is configured to derive a Web3 domain-subdomain token by reverse-parsing a Web2 fully qualified domain name (FQDN). For example, a Web2 identifier such as resource. acme. xyz. io may be deterministically mapped into a Web3 namespace token such as resource.acme.io.xyz by re-ordering the domain labels according to a predefined rule. Once reverse-parsed, the Web3 token is resolved via a blockchain name service, a smart contract registry, or another trusted blockchain-based resolution mechanism to locate the associated smart contract.

[0231] Embodiment B3 : Cryptographic IOU Settlement Framework Embodiment B3 , depicted in FIG. 12, relates to a cryptographic IOU settlement framework that encodes conditional payout rules into a tokenized instrument and automates compliance-checked settlements. In this embodiment, a primary token 3002 (similar in concept to the primary token of Embodiment Bl, and typically implemented as an NFT) is used to represent a promise of payment, such as an IOU, promissory note, or conditional voucher. The primary token 3002 is issued to a specific entity (e.g., to a user’s blockchain address corresponding to “Alice”) who is the designated redeemer or payee. What distinguishes this primary token is that it carries embedded metadata-defined conditions 3004 that must be satisfied for the token to be redeemed for value. The conditions 3004 can include a variety of constraints, for example:

[0232] Authorized Redeemer / Identity Condition (306): The token may specify that only a Attorney Docket Number: TT-0003 particular identity or category of user is allowed to redeem it. In practice, this could mean the token is non-transferable or only recognized for redemption if the redeemer presents a valid identity credential. For instance, the token’s metadata might contain an identifier for Alice’s identity token or a hash of Alice’s identity information, effectively stating that the token is “payable to the order of Alice” and no one else. Even if the NFT were transferred to another party, the system would require the redeemer to prove that they are Alice (or an authorized delegate of Alice) before processing payment.

[0233] Jurisdictional or Regulatory Compliance Conditions (3008): The token may include a field specifying permitted jurisdictions or other regulatory compliance parameters. For example, it might indicate that it is “redeemable only in Country Y” or “subject to AML clearance level X”. During redemption, the system will enforce this by checking the redeemer’s credentials or other data (for instance, verifying that the redeemer’s address or identity is associated with Country Y, or that a compliance oracle indicates the user has passed the required KYC / AML checks). If the check fails (e.g., the redeemer is from an unauthorized region or not sufficiently KYC-verified), the redemption transaction will be halted or denied.

[0234] Foreign Exchange Rate Condition (3010): The token can encode a requirement that a certain exchange rate condition be met at the time of redemption. For example, if the lOU’s value is denominated in one currency but the payout is in another, the token might specify conditions such as “redeemable only if USD / EUR < 0.9” or “the payout amount is calculated based on the current X / Y exchange rate, which must be below $100 as per an oracle feed.” The token’s metadata would

[0235] - include a reference to a trusted oracle data feed or specific oracle contract address and data key, along with the threshold criteria.

[0236] - At redemption, the system will query the oracle (either via a direct on-chain call in a smart contract or via an off-chain service) to get the current rate, and then compare it to the condition.

[0237] - Only if the condition is satisfied (e.g., the exchange rate meets the required threshold) will the redemption be permitted to proceed.

[0238] Temporal Expiration Condition (3012): The token may carry an expiration date or block height after which it is no longer valid for redemption. For instance, the token’s metadata could indicate that it must be redeemed before January 1, 2026, or within N blocks from issuance. The redemption process will check the current time or block number against this condition and refuse redemption if the token has expired. This ensures that the obligation isn’t open-ended and enforces Attorney Docket Number: TT-0003 a deadline on redemption.

[0239] When the designated recipient (e.g., Alice) wishes to redeem the primary token 3002, she initiates a redemption request (for example, by calling a smart contract function or through an off-chain interface that communicates with a smart contract). The redemption process involves evaluating all the conditions 3004 encoded in the token’s metadata. A smart contract (or an associated off-chain service, depending on implementation specifics and compliance requirements) will perform the following checks:

[0240] 1. Verifying Identity and Authorization: It confirms that the redeemer is indeed the authorized party (e.g., Alice) or meets the identity criteria specified by the token. This could involve checking for a specific identity token in the redeemer’s account or requiring a digital signature or credential presentation that proves identity. For example, Alice might be required to present a verifiable credential or possess an on-chain identity token, which the system checks against the token’s requirements.

[0241] 2. Checking Compliance Flags: If the token requires a certain KYC / AML compliance level or other regulatory clearance, the system queries a compliance oracle or checks for the presence of a requisite on-chain compliance token. For instance, the token might contain a reference to an on-chain KYC token that Alice must hold. The smart contract verifies that Alice’s address possesses the necessary compliance token or that an oracle attests she is KYC-approved before allowing redemption to proceed.

[0242] 3. Querying Oracles for External Data: The contract fetches the latest data from the specified external data sources (oracle feeds) necessary to evaluate conditions. For example, if the token has an exchange rate condition, the contract will retrieve the current exchange rate from the designated price oracle. If the token has a condition based on an external event or metric (like a commodity price, weather event, or any other off-chain data), the relevant oracle is queried. The system then compares the oracle-provided data to the corresponding condition(s) stored in the token.

[0243] 4. Checking Temporal Conditions: The system verifies that the token has not expired and that the current blockchain timestamp or block height is within any allowed redemption window specified by the token. If the token is expired or the current time is outside the permitted timeframe, the redemption is halted or denied.

[0244] Only if all the encoded conditions 3004 are verified to be satisfied does the system proceed to settle the IOU. Settlement can take the form of triggering a payment or value transfer to Alice. Attorney Docket Number: TT-0003 In one implementation, the smart contract might emit an event or directly call an oracle that bridges to an external payment system or backend. For example, once all on-chain checks pass, the contract could invoke an oracle service that notifies an external compliance and settlement platform 3020 (as depicted in FIG. 12 by event / notifi cation 3014). This external platform 3020 could be a secure service (possibly run by the issuing organization or a trusted third party) that then performs any required regulatory checks and releases funds to Alice according to the token’s instructions.

[0245] By leveraging this architecture, the IOU settlement becomes an automated, trust-minimized process. The issuer of the IOU can be confident that value will only be paid out if all conditions are met, and the redeemer can trust that if they meet the conditions, the payout will occur promptly and reliably. Additionally, by integrating oracles and compliance checks, this framework automates what traditionally would require multiple separate systems and manual oversight. For instance, consider an international remittance scenario: an organization issues a token representing a remittance obligation to a user in another country. The token could enforce that the user has passed KYC verification, that the applicable exchange rate is within certain bounds at the time of payout, and that the user is redeeming within a permitted time window. All these checks happen through a combination of on-chain logic and oracle inputs, and once validated, the actual money movement (which might occur off-chain, e.g., via a bank API or a stablecoin transfer) is triggered automatically by the system. This drastically reduces the need for manual intervention or the risk of non-compliance, as the business rules are embedded in the token itself.

[0246] Embodiment B3 provides a comprehensive solution for conditional IOU settlements on blockchain. By encoding redemption conditions into the token and using oracles for external data, it creates a self-executing instrument that ensures compliant payout. This approach goes beyond simple token transfers by embedding business logic and regulatory requirements into the asset tokenization itself. It is a significant improvement over existing digital payment tokens, as it localizes the enforcement of complex rules and data-driven conditions within the token transaction process, rather than relying on external legal agreements or post-fact verification.

[0247] Fig. 13 illustrates an embodiment of a condition-verification subsystem for the Primary Token redemption process. As shown, one or more verification inputs may be obtained from: (1) a blockchain oracle 3101, (2) an identity or credential verification source 3102, (3) a time-based or block-height or block-number condition source 3103, and (4) an Intern et-of- Things (loT) device 3104 or one or more other sensor input(s) 3105. Each of these inputs may be evaluated by a smart Attorney Docket Number: TT-0003 contract 3100 to determine whether the redemption conditions defined within the metadata 3112 of the primary token 3110 have been satisfied prior to triggering settlement.

[0248] In some embodiments, blockchain oracles provide external data for verifying or executing processes related to a variety of tokenized assets, including tangible asset tokens, digital asset tokens, and identity asset tokens in addition to the conditional settlement tokens described above. For tangible asset tokens, oracles may supply authoritative registry data, property valuations, market prices, or even sensor readings (for example, loT sensor data for physical goods). For digital asset tokens, oracles may provide license verification, usage or performance data, or off-chain hash validation of digital content. For identity asset tokens, oracles may supply compliance status updates, credential validations, or revocation signals. By integrating oracles across these domains, smart contracts can enforce settlement rules, lifecycle events, and compliance conditions dynamically based on live, trusted external data feeds rather than static on-chain information.

[0249] Oracle Integration Embodiment: In some embodiments, the verification or settlement process involves retrieving external data from a trusted external data source integrated with the blockchain, including but not limited to a blockchain oracle. The external data may provide compliance or KYC status, foreign exchange rates, asset price feeds, geographic restrictions, licensing information, registry information, or other real-time external data required to evaluate conditions defined in the token’s metadata. Such oracle integration enables smart contracts to enforce settlement rules, lifecycle events, and compliance conditions dynamically, based on live external data feeds rather than static on-chain information.

[0250] Embodiment B4 - Integrated Token Architecture

[0251] Fig. 14 illustrates how the three independent embodiments — Double-Predictor Binding (Fig. 10), Multi -Attribute Access Control (Fig. 11), and Conditional Settlement (Fig. 12) — can be combined in a single atomic transaction to enforce binding, attribute, and condition checks before redemption or payout. In this configuration, a single blockchain smart contract atomically enforces all three mechanisms in one transaction before executing the designated outcome.

[0252] A Primary Settlement Token 4002 has metadata fields include C I commitment, access policy root, and condition root. The Primary Settlement Token 4002 has Associated Tokens 4004a-b. Each carries its own C_Vi commitment linking back to the Primary Settlement Token. The Primary Settlement Token also has an exemplary credential tokens IdentityToken 4006a and RoleToken 4006b. Associated condition checks 4008a-c are also present and include an expiry condition, FX threshold condition, and a delivery confirmation condition. Attorney Docket Number: TT-0003 A Smart Contract Verifier 4010 processes the Primary Settlement Token 4002 and verfies the associated tokens 4004-4006 and conditions 4008a-c. If the tokens and conditions are appropriately satisfied, access is granted 4100.

[0253] Cryptographic Settlement Token Framework

[0254] This mechanism transforms a token into a programmable settlement token with embedded conditional payout logic. A non-fungible settlement primary token representing a payment obligation is issued to a designated recipient (akin to a digital promissory note). The token’s on-chain metadata carries one or more redemption conditions (e.g. identity verification of redeemer, jurisdictional restrictions, foreign exchange (FX) rate thresholds, time-based expiry) along with payout instructions for the promised value. A smart contract automatically enforces that the token can be redeemed for its value only if all specified conditions are satisfied; otherwise redemption is blocked. For example, the token may require that the redeemer prove their identity and that a delivery confirmation is recorded before funds are released. Upon a redemption request, the contract checks on-chain credentials and may query trusted off-chain data (via oracles) to evaluate conditions like compliance approvals or loT-sensor-reported events. If and when all conditions are met, the contract triggers the payout - potentially by releasing cryptocurrency or by signaling an external platform (e.g. a bank or payment system) to transfer funds - and marks the token as redeemed. This framework adds a compliance-aware, conditional settlement capability to tokenized obligations: the token itself encapsulates the “who, when, and under what conditions” of payment, bridging blockchain automation with real-world legal and regulatory requirements.

[0255] Cross-Border Remittance

[0256] Initiation & Identity Verification: A sender initiates a cross-border remittance through the platform, providing transaction details (amount, destination) and personal identification. The system stages the remittance request and verifies the sender’s identity and compliance information before proceeding. For example, the user’s government-issued ID may be processed (using OCR and data extraction) to create a KYC subdomain token representing the verified identity. The identity verification data is linked to the transaction, ensuring the remittance originates from a certified user. This preliminary step leverages the parent system’s know-your-customer tokenization process to bind a verified identity to the remittance.

[0257] Transaction Tokenization & Smart Contract Setup: After verification, a dedicated domain-subdomain token is generated to represent the remittance transaction itself. For instance, a namespace token might be created encoding the remittance ID under a top-level domain (e.g., Attorney Docket Number: TT-0003 remit.acme with a subdomain for the specific transfer). A smart contract on the blockchain is instantiated for this remittance and associated with the domain-subdomain token. This contract will govern funds flow and act as an escrow during the process. Using the blockchain name service, the domain-subdomain token can be resolved to the smart contract’s address, allowing any party (sender or receiver) to query the contract via the human-readable token identifier. At this stage, the foundational tokenization and contract deployment from the parent framework is complete -the remittance now has an on-chain identity and programmatic control point.

[0258] Primary token Issuance with Double Binding: The system next issues a non-fungible settlement primary token on the blockchain to embody the payment instruction. This remittance primary token is minted to the intended recipient’s address (or to an escrow contract on their behalf) and serves as a digital settlement token for the cross-border payment. Simultaneously, the equivalent associated tokens representing the transfer amount are provisioned and cryptographically linked. In this example, assume the sender’s stablecoin funds are locked in the contract as 1000 USDC; the primary token’s metadata includes a hash commitment referencing those specific 1000 USDC tokens, and each of those USDC tokens carries a commitment referencing the primary token’s ID. By embedding this double-predictor binding at issuance, the system ensures the remittance funds cannot be swapped or tampered with; only the originally designated tokens can fulfill the payment.

[0259] Conditional Redemption Rules Encoding: As part of issuing the remittance primary token, the platform encodes redemption conditions in the token’s metadata. These conditions correspond to compliance and context requirements for the cross-border payment, effectively turning the token into a rule-based remittance instrument. For example, the token may specify that it is only redeemable by a recipient possessing a valid identity credential and only within a permitted jurisdiction. An expiration time can be set in the metadata (e.g., “redeemable until 30 days from issuance”), after which the token becomes void if not redeemed. Additionally, if currency conversion is involved (USD to local currency), a condition can require that the prevailing FX rate meets a certain threshold at the time of payout - this would be enforced by checking an oracle for the current exchange rate. All such rules are immutably recorded in the token’s metadata at creation. In summary, the remittance token now carries built-in logic such that who can redeem (only the intended beneficiary with proper credentials), when (before expiry), where (perhaps only in an allowed jurisdiction or platform), and under what external parameters (e g., acceptable FX rate) are all predetermined and on-chain. Attorney Docket Number: TT-0003 Multi-Factor Authorization for Access: To further bolster security, the system can employ a multi-attribute access control step before redemption. In this embodiment, the beneficiary’s ability to claim the funds is gated by possession of multiple tokens. For instance, the recipient might be required to hold: (i) an identity / National ID token verifying their identity, and (ii) a one-time passcode token issued to them (an NFT or short-lived token serving as a second factor). The remittance primary token’s policy would list these as required attributes. When the recipient attempts to access the remittance claim interface, the system (via a smart contract or dApp) verifies that the recipient’s address holds both required tokens and that any attribute conditions are satisfied (e.g., the one-time pass token is unexpired). This check is done automatically on-chain by scanning token ownership and metadata. The use of multiple credentials ensures that even if the primary token were obtained by an unintended party, it cannot be redeemed without the matching identity and secret token. This on-chain multi-factor check extends the parent framework’ s basic access control with a trustless, cryptographically-enforced version of two-factor authentication.

[0260] Notification & Token Delivery: Once the remittance primary token is set up with its binding and conditions, the system notifies the recipient. For example, the platform generates a QR code or secure link that encodes the transaction’s domain-subdomain token or a URL containing it. Scanning this code or clicking the link directs the recipient to the remittance retrieval interface (a webpage or app screen corresponding to the token’s address), or directly to a blockchain name service lookup for the primary token’s smart contract. The recipient is informed (via email or messaging) that a payment token is awaiting them, along with instructions to use their digital wallet and the provided link. This user-friendly step, leveraging the parent system’s QR code mechanism, ensures the beneficiary can easily locate and retrieve the correct token on the blockchain without needing to manually search by transaction hash.

[0261] Redemption Request & On-Chain Verification: The beneficiary initiates redemption by presenting the primary token (which they now hold in their wallet) for payout via the smart contract. This action triggers the contract to perform an automatic, deterministic verification of all commitments and conditions. First, the double-predictor commitments are checked: the contract recomputes the hash from the provided associated tokens (the reserved stablecoins or digital funds) and compares it against the commitment stored in the primary token’s metadata, and vice versa. A matching pair proves that the exact correct associated tokens are being used to redeem the settlement token; any discrepancy causes an immediate failure, preventing fraudulent or incorrect Attorney Docket Number: TT-0003 funds from being substituted. Next, the contract evaluates each redemption condition encoded in the token. It verifies the redeemer’s address and credentials: for example, it confirms the presence of the required KYC / identity token and any other attribute tokens (as set in Step 5) on the redeemer’s address. It checks that the current time is within the allowed redemption window (by comparing against the token’s expiry timestamp). For any external conditions, the contract interfaces with oracles: for instance, it retrieves the latest FX rate from a trusted oracle to ensure the rate is favorable as per the token’s rule, and it may call an identity -verification oracle or check an on-chain credential to make sure the redeemer is indeed the designated person or has necessary approvals. If a jurisdictional restriction is specified, an oracle or credential (such as a residency token) might be checked at this time as well. The result is a comprehensive, one-shot validation: all required commitments and conditions must be satisfied in the same blockchain transaction. The smart contract logs the verification outcome for transparency. If any condition fails (e.g. missing token, hash mismatch, expired deadline, improper region), the redemption is rejected and the funds remain locked. If all checks pass, the process proceeds to settlement. The verifier checks that C I recomputes correctly from the presented tokens, and that each C_Vi recomputes correctly using the presented primary token’s ID. The inclusion of the salt S in the commitments ensures collision resistance.

[0262] Settlement Execution & Completion: Upon successful verification, the smart contract automatically triggers the payout according to the primary token’s encoded instructions. In many cross-border cases, the actual movement of money to the recipient may involve off-chain infrastructure. For example, if the associated tokens are stablecoins, the contract could simply transfer those on-chain tokens to the recipient’s wallet. Alternatively, if the platform is linked to banking networks, the contract can emit an event or call a bridge / oracle that notifies an external payment system to release fiat funds to the recipient’s bank account. In one embodiment, the contract calls a payment oracle service that signals the originating bank to credit the beneficiary’s local bank account and debits the reserved funds accordingly, achieving the fiat leg of the remittance. This external integration ensures regulatory compliance (e.g. the external platform might perform a final sanctions check before finalizing the payout). Once payout is executed, the smart contract marks the primary token as redeemed or spent (for instance, by burning the NFT or updating its state on-chain), preventing any further use. A confirmation or receipt may be logged as proof of payment. Notably, the entire trigger to pay is automated and conditional: the sender does not manually release funds; the code does so once it “sees” all conditions satisfied. This Attorney Docket Number: TT-0003 eliminates counterparty risk for the recipient and ensures the predefined logic guarantees payment. Conversely, the sender is protected by the conditions: if something were awry (e g. goods not delivered or a compliance check fails), the contract simply would not pay. In the end, the recipient receives the funds, the settlement token is settled, and an indelible on-chain record (including loT data and timestamps) is recorded.

[0263] Exception Handling & Cancellation: If the transaction fails or conditions aren’t met, the platform has mechanisms to handle it. For example, if the token expires without meeting the delivery condition, the obligation can be considered cancelled and the sender (buyer) may retrieve the reserved funds (the contract could allow the sender to withdraw funds after expiry). In case of a dispute or a cancellation agreement before delivery, the sender can invoke a voiding procedure - essentially sending a “void settlement token” instruction to the contract that cancels the obligation on-chain. Upon such voiding, the contract releases the reserved funds back to the sender and marks the settlement token as void, preventing any future redemption. These parentframework features complement the CIP logic by covering edge cases where manual intervention or off-chain agreement is needed to cancel. They ensure the system can gracefully handle scenarios where the automated process does not complete, maintaining fairness for all parties.

[0264] Simplified Use Case Lifecycle Summaries

[0265] The following summaries provides simplified lifecycle-style descriptions of exemplary use cases. These summaries highlight how the parent framework and CIP extensions operate together in practice. They are illustrative and not intended to limit the scope of the embodiments described above.

[0266] Master Use Case - Cross-Border Remittance

[0267] Sender initiation: Sender initiates the remittance on the platform and undergoes identity verification (KYC). The system creates a token to represent the remittance transaction (domainsubdomain token) and sets up a smart contract escrow.

[0268] Instruction (Primary) token issuance: A non-fungible settlement token is issued to the recipient as a payment instruction, and specific associated tokens (funds) are locked and cryptographically linked to this token (Double-Predictor binding).

[0269] Conditional rules programmed: The settlement token’s metadata is programmed with conditional payout rules (e.g., required identity credentials, jurisdiction limits, expiration date, and FX rate threshold) that must be satisfied for redemption.

[0270] Notification to recipient: The recipient is notified (e.g., via a secure link or QR code) that Attorney Docket Number: TT-0003 a payment token is awaiting them. They use their digital wallet and the provided link to access the settlement token.

[0271] Multi-factor authentication enforced: Before redemption, multi-factor authentication is enforced: the recipient’s wallet must hold additional tokens (e.g., a verified identity token and a one-time passcode token) as required by the settlement token’s policy.

[0272] One-shot verification and payout: The recipient submits a redemption request; the smart contract automatically verifies all commitments and conditions in one transaction (checking token bindings, identity attributes, time window, external oracle data for FX, etc.). If every check passes, the contract releases the reserved funds to the recipient (either transferring on-chain tokens or triggering an off-chain bank payment) and marks the settlement token as redeemed.

[0273] Use Case 1 - Prepaid Digital Credits (Double-Predictor) Purchase and tokenization: A customer purchases prepaid digital credits (e.g., for an online service). Once payment is confirmed, the platform creates a token to represent the credit purchase (as a placeholder for the prepaid value).

[0274] Voucher and value tokens issuance: The platform issues a voucher NFT (settlement token) representing the credit entitlement, and simultaneously mints the corresponding associated tokens (e.g., 100 credit tokens for \$100 value). The voucher token and credit tokens are cryptographically bound via matching hash commitments (double-predictor), linking the voucher to those specific tokens.

[0275] Escrow of value tokens: The credit tokens are held in escrow by a smart contract while the customer holds the voucher NFT in their wallet. This ensures the associated tokens cannot be lost or spent separately; they are reserved exclusively for when the voucher is redeemed.

[0276] Redemption request: When the user wants to redeem their prepaid credits, they submit the voucher NFT to the platform’s smart contract. The contract retrieves the reserved credit tokens and verifies the hash commitments: it confirms the presented tokens match the ones originally linked to the voucher. If the commitments match, integrity is proven.

[0277] Payout and token retirement: Upon successful verification, the contract applies the credit to the user’ s account (or otherwise releases the value). The voucher NFT is then burned or marked as used, completing the redemption. The entire process - from issuance to fulfillment - occurs on-chain without requiring trust in a third party.

[0278] Use Case 2 - Digital Technical File Access (Multi-Attribute + Transferable Ownership) File token creation: A confidential digital file is registered on the blockchain, creating a Attorney Docket Number: TT-0003 unique token for the file (domain-subdomain token). Company A initially holds this file token as the owner.

[0279] Access token issuance with policy: Company A issues a specialized access token (NFT) with a policy requiring multiple attribute tokens for access (CIP multi -attribute extension). The access token’s metadata lists the attributes a user must possess (e.g., an identity token, a role token, and a time-limited pass token) to open the file.

[0280] Provisioning attribute tokens: The required attribute tokens are provisioned to the intended user (for example, an identity verification token and a role credential token are provided to a contractor). These serve as the “keys” which, in combination, satisfy the access token’s policy requirements.

[0281] On-chain access check: When the user attempts to access the protected file, they must present the access token. The system’s smart contract checks on-chain that the user’s account holds all the required attribute tokens and that each token is valid (e.g., not expired). If any required token is missing or invalid, access is denied; if all are present and correct, the file access is granted.

[0282] Transfer of ownership: Later, Company A transfers ownership of the file token (along with control of the access token) to Company B. Because the file’s access control is tokenized, the new owner (Company B) can update the access token’s policy as needed. This demonstrates that both the asset and its access rules can be transferred and managed by a new owner via blockchain transactions.

[0283] Use Case 3 - Supply Chain Settlement (Settlement Token + loT) Digital IOU issuance: A buyer and supplier formalize a supply chain transaction (e.g., an order of goods). Instead of immediate payment, the buyer issues a non-fungible settlement token to the supplier as a digital payment obligation. The token is backed by reserved funds (e.g., locked stablecoins or an escrow account) and acts as an on-chain promissory note.

[0284] Embedding conditional terms: The settlement token’s metadata is embedded with all agreed conditions of payment (delivery confirmation, product inspection, regulatory approvals, deadlines for delivery, etc.). These conditions must be fulfilled before the token can be redeemed for payment.

[0285] loT data integration via oracles: Throughout shipment, loT devices (e.g., GPS trackers and environmental sensors) feed real-time data to the blockchain via oracles. For instance, upon delivery to the destination, the GPS tracker can log an event or a warehouse loT gateway can send a “delivery arrived” signal on-chain. Likewise, a temperature sensor’s readings are recorded via Attorney Docket Number: TT-0003 an oracle. The oracle service authenticates the loT data and makes it available to the smart contract. By the time the goods are delivered, the contract’s state reflects that condition (i) “Delivered” is true, and condition (ii) (e.g., temperature within range) is true. Essentially, the loT devices feed physical performance data into the on-chain contract, tying real-world events to the digital settlement token.

[0286] Redemption verification: Once the supplier is confident all conditions have been met, they invoke redemption of the settlement token. The smart contract automatically verifies that the correct reserved funds are still bonded to the token (via the cryptographic binding) and that every condition is satisfied: it checks the redeemer’s authorization, queries the loT data (delivery status, sensor readings), and ensures any required compliance credentials or approvals are present. If any condition is unmet, the redemption fails immediately.

[0287] Automated payout: If all checks pass, the smart contract triggers payment. Depending on the setup, this could mean releasing the on-chain funds to the supplier’s address or instructing a bank / payment network to pay out off-chain. The settlement token is then marked as redeemed (or burned), preventing reuse.

[0288] Exception handling: If conditions are not met by the deadline or if the order is canceled, the system handles exceptions. For example, if the token expires without delivery, the obligation is void and the buyer can retrieve the reserved funds. The buyer may also invoke a cancellation on-chain by sending a “void settlement token” command to the contract, which releases the funds back to the buyer and marks the token as void. These measures ensure that failed or canceled transactions are resolved cleanly on-chain.

[0289] Although the invention has been described with respect to specific embodiments thereof, these embodiments, including those in an Appendices hereto, are merely illustrative, and not restrictive of the invention. Rather, the description is intended to describe illustrative embodiments, features and functions in order to provide a person of ordinary skill in the art context to understand the invention without limiting the invention to any particularly described embodiment, feature, or function. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the invention, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the invention in light of the foregoing description of illustrated embodiments of the invention and are to be included within the spirit and scope of the invention. Thus, while the invention has been described herein with reference to Attorney Docket Number: TT-0003 particular embodiments thereof, a latitude of modification, various changes, and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the invention.

[0290] Reference throughout this specification to “one embodiment”, “an embodiment”, or “a specific embodiment” or similar terminology means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment and may not necessarily be present in all embodiments. Thus, respective appearances of the phrases “in one embodiment”, “in an embodiment”, “in some embodiments”, or “in a specific embodiment” or similar terminology in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics of any particular embodiment may be combined in any suitable manner with one or more other embodiments. It is to be understood that other variations and modifications of the embodiments described and illustrated herein are possible in light of the teachings herein and are to be considered as part of the spirit and scope of the invention.

[0291] While one of the various inventions herein may be illustrated by using a particular embodiment, this is not and does not limit the invention to any particular embodiment and a person of ordinary skill in the art will recognize that additional embodiments are readily understandable and are a part of this invention.

[0292] APPENDIX A

[0293] Appendix A hereto represents an additional set of exemplary embodiments. The embodiments described below include an advanced blockchain-based system for the secure management of digital certification and tokenization of real-world, digital, and / or identity assets. By integrating Web3 domain-subdomain tokens, Distributed Ledger Technology (DLT), Decentralized Identifiers (DIDs), and Al-driven verification processes, the system ensures immutability of smart contracts, protects client funds, and enhances transparency. This automated framework significantly improves the efficiency, security, and accuracy of managing diverse asset types across multiple industries.

[0294] 1. Web3 Domain-Subdomain Token Structure

[0295] This system uses a hierarchical Web3 domain-subdomain structure to create unique, Attorney Docket Number: TT-0003 traceable identifiers for both assets and digital identities. This structure provides scalable and interoperable management of assets on the blockchain.

[0296] Examples like ASSET01.XYZ, KYC.XYZ, and US0000000000.ASSET01.XYZ are illustrative and flexible, allowing adaptation to various naming conventions based on specific needs.

[0297] 2. Primary Domains and Subdomains

[0298] • Asset Domain (ASSET01. XYZ):

[0299] • Verification Subdomain: US0000000000.ASSET01.XYZ represents an asset during the verification phase.

[0300] • Certification Subdomain: CERT_US0000000000.ASSET01.XYZ confirms certified ownership.

[0301] • Voiding Subdomain: VOID_US0000000000.ASSET01.XYZ indicates a voided transaction.

[0302] • Closing Subdomain: CLOSE_USOOOOOOOOOO.ASSETOl.XYZ marks the end of the asset lifecycle.

[0303] • Digital Asset Domain (DIGITAL. XYZ):

[0304] • Verification Subdomain: CONTENTOOl. DIGITAL. XYZ for digital assets like intellectual property under verification.

[0305] • Certification Subdomain: CERT CONTENTOOl. DIGITAL. XYZ for certified digital assets.

[0306] • KYC Domain (KYC XYZ):

[0307] • KYC Subdomain: userl234.KYC.XYZ links a verified user’s identity to their Decentralized Identifier (DID).

[0308] • Certification Subdomain: CERT_userl234.KYC.XYZ confirms the user’s verified KYC status.

[0309] • Revocation Subdomain: VOID_userl234.KYC.XYZ indicates revocation of the KYC status.

[0310] 3. Decentralized Identifiers (DIDs) for Identity Assets

[0311] The system leverages Decentralized Identifiers (DIDs) to represent verified user identities on the blockchain. DIDs provide a portable, verifiable identity that is interoperable across platforms.

[0312] • DID Generation: Each verified user is issued a DID linked to their KYC subdomain (e.g., userl234.KYC.XYZ). Attorney Docket Number: TT-0003 • Interoperability: DIDs enable seamless, decentralized identity verification without repeated KYC processes.

[0313] • Secure Storage: The DID and related metadata are stored immutably on the blockchain, ensuring privacy and security.

[0314] 4. Subdomain Creation and Management

[0315] • Primary Domain Establishment: The system establishes root domains like ASSET01.XYZ and KYC.XYZ for asset and identity management.

[0316] • Dynamic Subdomain Generation: Subdomains are dynamically generated based on key lifecycle events (e.g., verification, certification).

[0317] • Blockchain Storage: All subdomains and their associated metadata are stored immutably on the blockchain, ensuring a secure, verifiable record.

[0318] 5. KYC Verification Process Using DIDs

[0319] The KYC process verifies user identities and issues a DID, creating a tokenized digital representation on the blockchain.

[0320] KYC Steps:

[0321] 1. User Registration: Users submit personal information and identification documents (e.g., passport, utility bill).

[0322] 2. Identity Verification: The system employs Al-driven algorithms or third-party verification services.

[0323] 3. DID and Subdomain Token Issuance: A DID and a KYC subdomain token (e.g., userl234.KYC.XYZ) are created upon successful verification.

[0324] 4. Secure Storage: The DID and KYC token are stored immutably on the blockchain, ensuring secure identity management.

[0325] 6. QR Code Integration for Verification

[0326] A binary QR code is generated upon verification, linking to a Web2 URL that references metadata stored on the blockchain. This hybrid approach leverages the accessibility of Web2 and the immutability ofWeb3.

[0327] QR Code Features:

[0328] • Links to a Web2 URL (e.g., example.com / USOOOOOOOOOO.ASSETOLXYZ or example.com / user 1234. KYC.XYZ).

[0329] • Webpage at URL displays icons representing the asset type or an identity badge.

[0330] • Provides scannable access to detailed verification data and DID metadata. Attorney Docket Number: TT-0003 • Is stored immutably on the blockchain, ensuring a tamper-proof reference.

[0331] 7. Tokenization Initiation Process

[0332] The tokenization process starts with preliminary data staging, where key asset details are collected before the smart contract is created.

[0333] Initiation Steps:

[0334] 1. Data Collection: The Tokenizer inputs asset details (e.g., asset type, price, number of tokens).

[0335] 2. Asset ID Generation: A unique asset ID (e.g., US0000000000.ASSET01) is created. 3. Preliminary Staging: Data is stored until verification is complete to prevent premature smart contract creation.

[0336] 8. Asset Verification Process

[0337] The system verifies asset authenticity and ownership through Al and manual checks.

[0338] Verification Steps:

[0339] 1. Document Submission: Ownership documents and proof of asset details are provided. 2. Al Analysis: The system uses OCR, NLP, and NER technologies for data extraction. 3. Cross-Reference Check: The extracted data is validated against authoritative external databases.

[0340] 4. Token and QR Code Creation: A verification subdomain token (e.g., US0000000000.ASSET01.XYZ) and QR code are issued.

[0341] 9. Certification Process

[0342] The certification process finalizes the verification, authorizing ownership or sale of the asset. Certification Steps:

[0343] 1. Document Review: Al and manual checks verify the closing documents.

[0344] 2. Certification Token Issuance: A certification subdomain token (e.g., CERT_US0000000000.ASSET01.XYZ) is created.

[0345] 3. Fund Release: The certification token updates the smart contract, releasing funds.

[0346] 10. Automated Voiding and Closing Mechanisms

[0347] The system includes automated mechanisms to handle failed or incomplete transactions.

[0348] Voiding Steps:

[0349] 1. Failure Detection: Avoiding token (e.g., VOID US0000000000.ASSET01.XYZ) is issued if certification fails.

[0350] 2. Contract Cancellation: The voiding token cancels the smart contract and refunds buyers. Attorney Docket Number: TT-0003 Closing Steps:

[0351] 1. Finalization: A closing token (e.g., CLOSE_USOOOOOOOOOO.ASSETOl.XYZ) deactivates the smart contract after completion.

[0352] 11. Income Distribution and Secondary Market Integration

[0353] Smart contracts facilitate automatic income sharing and token resale on secondary markets. Distribution Steps:

[0354] 1. Income Deposit: Asset-generated income is deposited into the smart contract.

[0355] 2. Revenue Calculation: The smart contract calculates each holder’s share based on ownership.

[0356] 3. Automatic Payouts: Income is distributed directly to token holders.

[0357] 12. Applications and Use Cases

[0358] The system’s versatility allows it to be applied across a broad range of industries and scenarios, leveraging tokenization, certification, and identity verification for both physical and digital assets. The following examples illustrate potential use cases, including but not limited to:

[0359] 1. Real Estate Tokenization

[0360] • Process: Fractional ownership of real estate properties is enabled by verifying, tokenizing, and certifying the assets using Al-driven document analysis. Ownership tokens are linked to asset subdomains (e.g., ADDRESS 1234.REALESTATE.XYZ).

[0361] • Features: Automated income distribution (e.g., rental income) and support for token resale on secondary markets, with updated ownership records maintained by smart contracts.

[0362] 2. Vehicle Tokenization and Transfer

[0363] • Process: Secure ownership tracking and transfer of vehicles (e.g., cars, boats, aircraft) using verified documents (e.g., VINs, hull numbers). Subdomain tokens (e.g., AUTO 1234. VEHICLE. XYZ) are issued for verified assets.

[0364] • Features: Automated ownership transfer triggered by certification tokens, and compliance verification through KYC processes using Decentralized Identifiers (DIDs).

[0365] 3. Intellectual Property and Digital Rights Management

[0366] • Process: Tokenization of intellectual property (IP) assets such as patents, copyrights, and trademarks. Verified digital assets are linked to subdomains (e.g.,

[0367] CONTENT001 DIGITAL. XYZ).

[0368] • Features: Automated royalty payments through smart contracts, ensuring transparent and Attorney Docket Number: TT-0003 accurate distribution of income to IP holders.

[0369] 4. Digital Identity Verification and DID Services

[0370] • Process: Users undergo a KYC process that issues a DID linked to their identity subdomain (e.g., userl234.KYC.XYZ). Verified identities are securely stored and referenced on the blockchain.

[0371] • Features: Cross-platform interoperability for verified identities, allowing users to interact with multiple services without repeated KYC verification, enhancing regulatory compliance.

[0372] 5. Artwork and Collectibles Tokenization

[0373] • Process: High-value artworks and collectibles are verified for provenance and ownership using Al technologies. Tokens linked to subdomains (e.g., ART123.FINEART.XYZ) represent fractional ownership.

[0374] • Features: Support for fractional ownership, seamless secondary market trading, and automated distribution of income from rentals (e.g., museum loans).

[0375] 6. Equipment Leasing and Asset Management

[0376] • Process: Specialized equipment (e.g., medical devices, industrial machinery) is verified and tokenized with subdomain identifiers (e g., EQUIP1234. INDUSTRIAL. XYZ).

[0377] • Features: Automated lease payment distribution to token holders based on ownership shares, and secure execution of leasing agreements via smart contracts.

[0378] 7. Supply Chain and Inventory Tokenization

[0379] • Process: Products are tracked and verified throughout the supply chain using unique subdomain tokens (e.g., PRODUCTOOl.SUPPLYCHAIN.XYZ), linked to their DIDs and verified metadata.

[0380] • Features: Real-time transparency and visibility of product movement, with authenticity verified through scannable QR codes linked to subdomains.

[0381] 8. Event Ticketing and Fundraising

[0382] • Process: Tickets for events are issued as tokens linked to event subdomains (e.g., EVENTOO ETICKETS. XYZ), creating unique digital assets verified on the blockchain.

[0383] • Features: Automated revenue sharing to organizers and investors, support for ticket resale while maintaining accurate ownership records, and secure access control via QR codes.

[0384] These embodiments outline a robust, scalable framework for the digital certification and Attorney Docket Number: TT-0003 tokenization of real-world, digital, and identity assets. By integrating Web3 domain-subdomain tokens, DIDs, Al-driven verification, and automated smart contracts, the invention offers a transparent, efficient solution tailored to the needs of modem asset management across multiple industries.

[0385] Appendix B - Illustrative Example Workflows

[0386] The examples herein are non-limiting and are provided to illustrate enablement.

[0387] Variations may be made without departing from the scope of the claims.

[0388] Embodiment Bl — Double-Predictor Token Binding (Detailed Technical Specification) This embodiment cryptographically binds one primary token with one or more associated tokens such that redemption / validation succeeds only when the exact originally bound set is presented together. (A secondary token is associated with, and subordinate to, a primary token within the hierarchy of the system.) The mechanism is generally agnostic to token purpose (value, credential, proof, access right) and chain.

[0389] 2) Symbols

[0390] • H( ): cryptographic hash (e.g., Keccak-256 on EVM chains or SHA-256 on others; the algorithm is chain-selectable but fixed per deployment).

[0391] • "I", "V": domain separation tags, single-byte ASCII constants 0x49 and 0x56 respectively (or 2-byte UTF-8 if preferred), prepended to distinguish commitment namespaces.

[0392] • chain id: the blockchain network identifier (uint).

[0393] • contract_addr: the issuer smart-contract address (20 bytes for EVM chains).

[0394] • l id: primary token identifier (uint).

[0395] • V_i_id: associated token identifier (uint) for associated token i.

[0396] • S: 256-bit salt generated at issuance (CSPRNG), revealed at validation; only H(S) is anchored on-chain at issuance.

[0397] • MR_V: Merkle root of the associated token set, computed over canonically ordered leaves (see §4).

[0398] 3) Commitment Construction

[0399] Primary token commitment

[0400] C I = H( "I" || chain_id || contract_addr || l id || S || MR_V )

[0401] Each secondary token commitment

[0402] ""

[0403]

[0404] Attorney Docket Number: TT-0003 Rationale:

[0405] • No circular hashing: both commitments reference the issuance transcript, not each other’s hash.

[0406] • Provenance baked-in (chain id, contract addr) prevents look-alikes minted elsewhere.

[0407] • S prevents preimage / second-preimage attacks and binds all commitments to a single issuance event.

[0408] • Domain separation tags prevent cross-namespace collisions.

[0409] 4) Merkle Root MR_V (Canonical Set Encoding)

[0410] Leaves:

[0411] • For discrete tokens: LEAF = encode_u256(V_i_id)

[0412] • For fungible allocations or account -based reserves: LEAF = encode_tuple(tokenContract, account, amount)

[0413] Canonical ordering: Sort leaves by bytewise lexicographic order of their encoded bytes before tree construction.

[0414] Hashing: Internal node = H(left || right); if odd leaf, duplicate last (or use sparse-tree rules, but state which).

[0415] Serialization rules (EVM typical):

[0416] • encode_u256(x): 32-byte big-endian

[0417] • encode_addr(a): 20-byte raw

[0418] • encode_amount(a): 32-byte big-endian

[0419] • Tuples are concatenation of field encodings, no delimiter

[0420] Note: Include MR_V only in C I. Secondary tokens carry l id, eliminating the need for pertoken inclusion proofs unless explicit Merkle membership checks are desired (optional variant below).

[0421] 5) Serialization of Commitment Inputs

[0422] Concatenate fields in this order (no delimiters):

[0423] • tag ("I" or "V", 1 byte)

[0424] • chain_id (u256, 32 bytes)

[0425] • contract_addr (20 bytes, left-padded to 20; if you prefer 32-byte padded, specify consistently)

[0426] • l id or V_i_id (u256, 32 bytes) Attorney Docket Number: TT-0003 • S (32 bytes)

[0427] • MR_V (32 bytes; present only in C I)

[0428] Note: Byte order and field widths are normative to ensure deterministic recomputation across clients.

[0429] 6) Issuance Process (On-Chain + Off-Chain Roles)

[0430] Off-chain / issuer (or contract) steps:

[0431] • Generate S via CSPRNG (256-bit)

[0432] • Build canonical leaf list; compute MR_V

[0433] • Compute C I and each C_Vi per §3

[0434] On-chain state writes:

[0435] • Mint primary token with metadata containing C I

[0436] • Mint (or designate) associated tokens and record C_Vi in their metadata / state

[0437] • Emit issuance anchor event: Issued(I_id, MR V, H(S), chain id, contract addr) Note: A mapping may be stored for direct retrieval; event + mapping is preferred for auditability and gas.

[0438] Immutability requirement:

[0439] C I and each C Vi should be immutable once set. If a correction is needed, issue a new token and mark the old issuance revoked.

[0440] 7) Redemption / Validation Process (Single Transaction)

[0441] Input: l id, full set of presented associated tokens { V_i_id} , and S.

[0442] Verifier (smart contract) steps

[0443] 1. Provenance check: msg. sender or provided pointers indicate the official contract addr; require tokenContract == expectedlssuerContract.

[0444] 2. Anchor check: verify an Issued(I_id, MR V anchor, H(S)_anchor, ...) exists.

[0445] 3. Salt check: H(S) equals H(S)_anchor.

[0446] 4. Recompute:

[0447] • Build MR_V_computed from presented set using canonical rules.

[0448] • C_I* = H("I" || chain_id || contract_addr || l id || S || MR_V_computed); require C I* == stored C I(I id).

[0449] • For each presented associated token v: C_V* = H("V" || chain_id || contract_addr || V_v_id || S || l id); require C_V* == stored_C_V(V_v_id). Attorney Docket Number: TT-0003

[0450] 5. Cardinality check: ensure the presented set size equals the original bound set size if you store it; otherwise rely on MR_V equality.

[0451] 6. Ownership / authorization (if applicable): require the redeemer holds any required tokens or satisfies policy.

[0452] 7. Outcome:

[0453] • Success: atomically burn / mark-redeemed the primary token and trigger the configured action (payout, access grant, credential validation, etc.).

[0454] • Failure: revert; do not consume the primary token.

[0455] 8) Optional Variants (Dependent Embodiments)

[0456] • Issuer Signature Attestation: issuer signs D = H( l id | MR_V || S ||

[0457] policy _root(optional)), store signature in metadata or anchor; verifier checks signature before step 4.

[0458] • Merkle Membership Proofs: instead of recomputing MR_V from full set, accept pertoken Merkle proofs to MR V anchor.

[0459] • Accumulator Variant: use append-only accumulators (e g., sparse Merkle, vector commitments) for dynamic baskets (claim as alternative).

[0460] 9) Events, Errors, and State

[0461] Events:

[0462] • Issued(I_id, MR_V, H_S, chain id, contract addr)

[0463] • Redeemed(I_id, redeemer, outcomeCode)

[0464] • RedeemFailed(I_id, redeemer, reasonCode)

[0465] • Revoked(I_id, reasonCode)

[0466] Error / Reason codes (illustrative):

[0467] • E NO ANCHOR

[0468] • E BAD SALT

[0469] • E BAD MR

[0470] • E BAD CI

[0471] • E BAD CV

[0472] • E WRONG ISSUER

[0473] • E NOT OWNER Attorney Docket Number: TT-0003 • E ALREADY REDEEMED.

[0474] State layout (example):

[0475] • mapping(uint256 => bytes32) C T by lld;

[0476] • mapping(uint256 => bytes32) C_V_by_VId;

[0477] • mapping(uint256 => IssuanceAnchor) anchor by lld;

[0478] • mapping(uint256 => bool) redeemed;

[0479] • mapping(uint256 => bool) revoked;

[0480] 10) Security Properties and Threat Model

[0481] • Non-substitution: any change in { V_i_id} flips MR_V and breaks C L

[0482] • No circularity: commitments bind to shared transcript instead of each other.

[0483] • Front-running neutral: verification is atomic; pre-submitted tx without the correct set fails.

[0484] • Duplication fails: copied metadata on another contract fails provenance check (contract addr).

[0485] • Salt secrecy: only H(S) is anchored; S revealed at redemption eliminates precomputation risk.

[0486] • Replay-proof: burn / mark-redeemed on success; replays revert.

[0487] • Upgradability caution: if using proxies, fix contract addr via the implementation or store a binding issuer id to avoid provenance ambiguity.

[0488] • One-liner (examiner-friendly). Front-running or duplication does not help because verification is one-shot against pre-committed values; only the exact bound tokens pass.

[0489] 11) Gas and Practical Considerations (EVM example)

[0490] • For small sets (<32 leaves), full MR_V recomputation is cheap enough; for large sets, accept Merkle proofs to MR V anchor.

[0491] • Store C_I / C_Vi on-chain (32B each). For low gas, store only a content hash of off-chain metadata plus C_I / C_Vi on-chain for integrity.

[0492] • Events provide auditable trails with minimal storage.

[0493] 12) Worked Example (Deterministic Transcript)

[0494] • chain_id = 0x01

[0495] • contract_addr = 0x2222...2222

[0496] • l id = 0x1001 Attorney Docket Number: TT-0003 • Associated set = { V_1 = 0x5001, V _2 = 0x5002 }

[0497] • S = 0x69BFA1531A7C...7DE5872 (32 bytes)

[0498] Canonical leaves:

[0499] • encode_u256(0x5001)

[0500] • encode_u256(0x5002)

[0501] • MR_V = H( H(leafl) || H(leaf2) ) (illustrative — exact hash omitted)

[0502] Compute:

[0503] • C I = H("I" || 0x01 || 0x2222...2222 || 0x1001 || S || MR_V)

[0504] • C_V1 = H("V" || 0x01 || 0x2222...2222 || 0x5001 || S || 0x1001)

[0505] • C_V2 = H("V" || 0x01 || 0x2222...2222 || 0x5002 || S || 0x1001)

[0506] Anchor:

[0507] • Issued( I_id=0xl001, MR_V, H(S), chain_id=0x01, contract_addr=0x2222...2222 ) Redemption:

[0508] • present l id, tokens 0x5001 & 0x5002, and S.

[0509] • Recompute MR_V_computed from {0x5001, 0x5002} — must equal anchored MR_V.

[0510] • Verify CJ* == stored_C_I, C_V1* == stored_C_Vl, C_V2* == stored_C_V2.

[0511] • If all equal — burn / mark 0x1001, trigger outcome (e.g., transfer, access grant).

[0512] • If any mismatch (e.g., {0x5001, 0x5003}) —> revert (no consumption).

[0513] 13) Optional Policy Coupling (Cross-Embodiment Hook)

[0514] Where used with Embodiment B2 (multi -attribute access) or Embodiment B3 (conditional settlement), include policy root in D (issuer signature variant) and / or as an additional commitment field in the primary token metadata to bind policy to the exact issuance.

[0515] Embodiment B2 — Multi-Attribute Metadata Access Control (Full Technical Specification)

[0516] This particular embodiment exemplifies fine-grained, on-chain access control by requiring a user to simultaneously satisfy a policy encoded in a non-fungible access token (the “policy container”). The policy names a set of attribute tokens (e.g., identity, role / clearance, time-based pass, jurisdiction credential, training certificate), each of which must be valid at verification time. The access verifier is a smart contract that deterministically evaluates the possession of one or more attribute tokens consistent with an on-chain access policy, atomically in one transaction and Attorney Docket Number: TT-0003 grants or denies the designated outcome (e g., open a resource, decrypt a key, enable a function, reveal a credential).

[0517] 2) Entities and Symbols

[0518] • Access Token (NFT): the policy container; uniquely identified by A_id.

[0519] • Attribute Token: any token (NFT / FT / V C pointer) that satisfies one requirement in the policy.

[0520] • H( ): cryptographic hash for policy integrity fields (Keccak-256 / SHA-256; fixed per deployment).

[0521] • chain_id, contract_addr: verifier contract context (for policy signatures, optional).

[0522] • now, block.number: current time or block height (depending on chain).

[0523] • issuer_pubkey: public key for verifying signed policies (optional embodiment).

[0524] • Outcome: the controlled action (grant access, release secret, emit capability, toggle state).

[0525] 3) Policy Container (Access Token) — Metadata Schema

[0526] Each Access Token stores an immutable or versioned policy. A normative JSON (or CBOR) schema follows; actual on-chain storage can be raw bytes with the same fields.

[0527] "policy _id": "string",

[0528] "version": 1,

[0529] "requirements": [

[0530] "type": "identity",

[0531] "token": {"standard": "erc721", "contract": "OxIDREG...", "id": "0x301"},

[0532] "holder": "caller"

[0533] {

[0534] "type": "role",

[0535] "token": {"standard": "ercll55", "contract": "OxROLE...", "id": "0x302"},

[0536] "role": "Engineer"

[0537] {

[0538] "type": "time",

[0539] "token": {"standard": "n / a"}, Attorney Docket Number: TT-0003 "valid_from": 17000000,

[0540] "valid_until": 17500000

[0541] },

[0542] "type": "jurisdiction",

[0543] "token": {"standard": "erc721", "contract": "OxGEO ...", "id": "OxJOOl"},

[0544] "allowed": ["US", "SG", "EU"]

[0545] },

[0546] {

[0547] "type": "certificate",

[0548] "token": {"standard": "erc721", "contract": "OxCERT...", "id": "OxCFE"},

[0549] "must be unrevoked": true

[0550] }

[0551] ],

[0552] "logic": "ALL",

[0553] "revocation": {

[0554] "policy _nonce": 7,

[0555] "is_revoked": false

[0556] "integrity": {

[0557] "policy _hash": "Ox...",

[0558] "issuer_signature": "Ox..."

[0559] }

[0560] Notes:

[0561] • requirements is an ordered array of rule objects; each rule binds to a token reference (contract + id) and / or intrinsic constraint (time window, role value).

[0562] • logic enables ALL (AND) or ANY K (k-of-n) policies.

[0563] • integrity optionally anchors a signature by the policy issuer; the verifier rejects if the signature does not match.

[0564] 4) Token-Side Data (Attribute Evidence) Attorney Docket Number: TT-0003 Each Attribute Token may, but is not required, to carry metadata used during checks (e g., role strings, issuer IDs, revocation flags, credential level). For fungible / semi-fungible tokens, the presence plus balance / ID may suffice; for identity / credential NFTs, metadata or a registry mapping is consulted.

[0565] Revocation and status may be implemented by:

[0566] • On-chain registries (mapping tokenld —> revoked / active).

[0567] • Credential contracts exposing isValid(tokenId) or levelOf(tokenId).

[0568] • Off-chain VCs anchored by on-chain hashes / signatures (optional embodiment).

[0569] 5) Verification Algorithm (Smart Contract)

[0570] Function signature (illustrative, EVM):

[0571] function verify Access(address user, uint256 A_id) external view returns (bool);

[0572] Pseudocode (normative steps):

[0573] policy = loadPolicy(A id)

[0574] / / (1) Integrity checks

[0575] require(policy. integrity. policy _hash == H(serialize(policy without integrity)))

[0576] if (policy. integrity. issuer_signature present) {

[0577] require(verifySig(issuer_pubkey, H(chain_id||contract_addr||A_id||policy.integrity.policy_hash ),

[0578] policy, integrity ,issuer_signature));

[0579] / / (2) Revocation / versioning

[0580] require( 'policy . revocati on . i s_r evoked) ;

[0581] / / (3) Requirement evaluation

[0582] int satisfied = 0;

[0583] for (req in policy. requirements) {

[0584] switch (req. type):

[0585] case "identity":

[0586] require(owns(user, req. token. contract, req. token. id));

[0587] / / optional: require registry. isKYC(req. token. id) == true

[0588] satisfied++;

[0589] case "role":

[0590] require(owns(user, req. token. contract, req. token. id)); Attorney Docket Number: TT-0003 if (exists(req.role)) {

[0591] require(roleRegistry.hasRole(user, req. role)); / / or embedded token metadata check }

[0592] satisfied++;

[0593] case "time":

[0594] current = getCurrentTimeOrBlock();

[0595] require(current >= req.valid from && current <= req.valid until);

[0596] satisfied++;

[0597] case "jurisdiction":

[0598] require(owns(user, req. token. contract, req. token. id));

[0599] / / optional: require geoRegistry. allowed(user) in req. allowed

[0600] satisfied++;

[0601] case "certificate":

[0602] require(owns(user, req. token. contract, req. token. id));

[0603] if (req.must_be_unrevoked) {

[0604] require(certRegi stry . i s Vali d(req . token .id));

[0605] }

[0606] satisfied++;

[0607] default:

[0608] revert("Unsupported requirement type");

[0609] / / (4) Logic gate

[0610] if (policy. logic == "ALL") {

[0611] require(satisfied == len(policy. requirements));

[0612] } else if (policy. logic == "ANY_K") {

[0613] require(satisfied >= policy. logic.k);

[0614] } else {

[0615] revert("Unsupported logic");

[0616] / / (5) Outcome

[0617] emit AccessGranted(user, A_id);

[0618] return true; Attorney Docket Number: TT-0003 Denial path: On first failed predicate, revert or return false and emit AccessDenied(user, A id, reasonCode).

[0619] 6) Lifecycle and Outcomes

[0620] Grant path: On success, the verifier emits AccessGranted and:

[0621] • flips an on-chain flag for gated functions,

[0622] • returns a capability token,

[0623] • releases a decryption key via a confidential channel, or

[0624] • calls a downstream contract’s enter(user) or similar.

[0625] Deny path: No state change except logging; the Access Token remains valid for later attempts.

[0626] 7) Events and State

[0627] Events:

[0628] • AccessGranted(address user, uint256 A_id)

[0629] • AccessDenied(address user, uint256 A_id, uint256 reasonCode)

[0630] • PolicyUpdated(uint256 A_id, bytes32 policy _hash, uint256 policy nonce)

[0631] • PolicyRevoked(uint256 A_id, uint256 policy nonce)

[0632] State (illustrative):

[0633] • mapping(uint256 => Policy) policyByAId;

[0634] • mapping(uint256 => bool) policyRevoked;

[0635] Optional registries: rol eRegistry, certRegistry, geoRegistry

[0636] 8) Security and Privacy Considerations

[0637] • Atomic evaluation prevents “partial access” and TOCTOU races; all checks occur in the same transaction.

[0638] • Policy integrity via policy hash (+ optional issuer signature) thwarts tampering.

[0639] • Revocation supported by policy nonce and per-credential registries.

[0640] • Least disclosure: The contract only checks ownership / validity; where possible, use ZK proofs for attributes that should remain private (optional dependent embodiment).

[0641] • Replay and delegation: If delegation is allowed, require session-bound signatures or ephemeral delegation tokens.

[0642] 9) Worked Examples Attorney Docket Number: TT-0003 9.1 Engineering Document Room (identity + role + time)

[0643] A_id = 0xA202 (Access Token for “ENG DOC ROOM”)

[0644] Requirements:

[0645] • Id entity Token: ERC-721 at OxIDREG..., id=0x301 (KYC-verified).

[0646] • RoleToken: ERC-1155 at OxROLE..., id=0x302, role = “Engineer”.

[0647] • Time window: valid_from = 1,7000,000 (block / time), valid_until = 1,7500,000.

[0648] Logic: ALL.

[0649] User OxUser calls verify Access(OxUser, 0xA202):

[0650] • Owns 0x301 and 0x302; roleRegistry confirms “Engineer”; current time within window — > AccessGranted.

[0651] • If time has expired or role missing — AccessDenied; access token remains valid for later atempts (e g., after role assignment).

[0652] 9.2 Data Center Rack Access (jurisdiction + certificate)

[0653] A_id = 0xA900 (Access Token for physical rack control)

[0654] Requirements:

[0655] • Jurisdiction credential NFT OxGEO. ,.:0xJ001 with allowed = ["US", "SG", "EU"].

[0656] • Safety Certificate NFT OxCERT... :0xCFE with must_be_unrevoked = true.

[0657] Logic: ALL.

[0658] Verifier checks ownership + geoRegistry. allowed(user) and certRegistry.isValid(OxCFE) — toggles relay and emits AccessGranted.

[0659] 10) Optional Dependent Embodiments

[0660] • Signed policy: The issuer signs H(chain_id || contract_addr || A_id || policy _hash);

[0661] verifier rejects if signature invalid.

[0662] • k-of-n policies (ANY_K): Access requires any k satisfied requirements (e.g., two out of three factors).

[0663] • ZK credential proofs: Replace direct ownership checks with zero-knowledge attestations (proof circuits referenced by policy id).

[0664] • Time sources: Use block timestamp or oracle-provided time for stricter environments;

[0665] specify precedence.

[0666] • Delegation: Allow the policy to specify holder="delegate" and require a signed grant from the identity holder to user. Attorney Docket Number: TT-0003 11) Interoperability with Embodiment Bl and B3

[0667] • With Double-Predictor (Emb. 1): Require that the redeemer of a bound token set also satisfies an Access Token policy (e.g., KYC + role) before redemption.

[0668] • With Conditional Settlement (Emb.3): Treat certain policy checks (identity / time / jurisdiction) as conditions of the settlement token; unify results so that both the double-predictor check and the access policy must pass in the same transaction.

[0669] Embodiment B3 — Conditional Settlement Token (Full Technical Specification) This exemplary embodiment creates a primary token representing an obligation or conditional promise (e.g., a remittance IOU, supply chain settlement, service agreement) whose redemption is gated by multiple conditions. The smart contract enforces these conditions autonomously: redemption succeeds only if all are satisfied in one on-chain check, and fails otherwise. Conditional redemption and payout logic are implemented via on-chain validation of redemption conditions defined within the primary token’s metadata.

[0670] 2) Entities and Symbols

[0671] • SettlementToken (NFT): primary token, identified by S id, stores metadata including conditions and payout instructions.

[0672] • Secondary Tokens: may be linked via Double-Predictor (Embodiment Bl) or stand-alone;

[0673] represent locked value or proofs.

[0674] • Condition: a structured rule (identity, jurisdiction, expiry, oracle-fed data, loT event). • H( ): secure hash for integrity of condition sets.

[0675] • oracle addr: blockchain oracle contract providing external data.

[0676] • policy root: optional Merkle root of conditions for compact encoding.

[0677] 3) Metadata Schema (Illustrative JSON)

[0678] {

[0679] "settlement_id": "0x1001",

[0680] "obligation": {

[0681] "amount": "1000",

[0682] "currency": "USDC",

[0683] "beneficiary": "OxAlice"

[0684] L

[0685] "conditions": {

[0686] "identity": { Attorney Docket Number: TT-0003 "required token": "OxIDREG: 0x301",

[0687] "holder": "beneficiary"

[0688] },

[0689] "jurisdiction": {

[0690] "allowed": ["US", "SG", "EU"]

[0691] },

[0692] "expiry": {

[0693] "block_valid_until": 500000

[0694] "fx_rate": {

[0695] "oracle": "OxORACLE",

[0696] "pair": "USD / EUR",

[0697] "threshold": ">=0.9"

[0698] "iot_event": {

[0699] "oracle": "OxIOT",

[0700] "event_id" : "DELIVERY COMPLETE"

[0701] }

[0702] "payout_instructions": {

[0703] "method" : "onchain_transfer",

[0704] "asset_contract": "OxUSDC...",

[0705] "amount": "1000",

[0706] "recipient": "OxAlice"

[0707] "integrity": {

[0708] "conditions root": "OxHASH",

[0709] "issuer_signature": "OxSIG"

[0710]

[0711] Attorney Docket Number: TT-0003 4) Issuance Process

[0712] 1. Issuer defines conditions and payout instructions.

[0713] 2. Compute conditions root = H(serialize(conditions)).

[0714] 3. Sign digest: Sig = Sign_issuer(H(S_id || conditions_root)).

[0715] 4. Mint SettlementToken with:

[0716] - conditions root,

[0717] - full metadata,

[0718] - optional issuer signature for authenticity.

[0719] 5. Emit anchor: Issued(S_id, conditions root, H(S), payout instructions)

[0720] 5) Verification Algorithm (Smart Contract)

[0721] Function signature (EVM example) :

[0722] function redeem(uint256 S id, bytes32 salt, ConditionProoff] proofs) external;

[0723] Steps:

[0724] 1. Anchor check: Ensure issuance event exists for S id.

[0725] 2. Salt check: H(salt) must match stored H(S).

[0726] 3. Condition checks:

[0727] • Identity: verify redeemer owns 0xIDREG:0x301.

[0728] • Jurisdiction: check redeemer’s geo credential NFT is in allowed.

[0729] • Expiry: block.number <= block valid until.

[0730] • FX rate: call oracle at OxORACLE — > compare USD / EUR > 0.9.

[0731] • loT event: call oracle at OxIOT — confirm DELIVER Y COMPLETE.

[0732] 4. All conditions satisfied?

[0733] • Yes — bum / mark-redeemed S id, trigger payout.

[0734] • No revert; token remains valid for future attempt.

[0735] 6) Lifecycle

[0736] Issuance: Token minted with embedded conditions + anchor logged.

[0737] Redemption attempt: Redeemer calls contract; contract validates all conditions atomically. Success:

[0738] - SettlementToken is burned / retired.

[0739] - Associated value is released (on-chain transfer, oracle-triggered fiat release, or API call).

[0740] Failure: Attorney Docket Number: TT-0003 - No state change except event log.

[0741] - Token remains valid until conditions are satisfied or expiry is reached.

[0742] 7) Worked Example (Remittance with FX + Identity)

[0743] S id = 0x1001

[0744] Obligation: 1000 USDC — ► Alice

[0745] Conditions:

[0746] - IdentityToken #301 required.

[0747] - Expiry = Block #500000.

[0748] - FX Rate USD / EUR > 0.9 via oracle.

[0749] Issuer emits: Issued(0xl001, conditions_root, H(S), payout=1000 USDC to OxAlice) Redemption:

[0750] • Alice presents token #1001, IdentityToken #301, salt S.

[0751] • Contract recomputes conditions root; queries oracle for USD / EUR.

[0752] • Oracle returns 0.95 —> passes threshold.

[0753] • All conditions satisfied — > contract transfers 1000 USDC to Alice, bums #1001.

[0754] 8) Events and State

[0755] Events:

[0756] - Issued(S_id, conditions root, H_S, payout)

[0757] - Redeemed(S_id, redeemer, outcomeCode)

[0758] - RedeemFailed(S_id, redeemer, reasonCode)

[0759] - Expired(S_id, block.number)

[0760] State variables:

[0761] mapping(uint256 => bytes32) conditionsRootBySId;

[0762] mapping(uint256 => bool) redeemed;

[0763] mapping(uint256 => bool) expired;

[0764] 9) Security Rationale

[0765] - Atomic checks: all conditions validated in a single transaction — no race conditions.

[0766] - Provenance: chain_id + contract_addr + issuer_signature ensure authenticity.

[0767] - Replay-proof: Token is burned / marked redeemed after success.

[0768] - Tamper-resistance: Metadata integrity via conditions root.

[0769] - Oracle dependence: Trusted oracle contracts required; fallback = multiple oracle feeds + quorum logic. Attorney Docket Number: TT-0003 - Redemption succeeds only when all programmed conditions are satisfied in a single deterministic on-chain transaction; otherwise, the token remains valid but unredeemed.

[0770] Embodiment B4 — Integrated Token Architecture (Combination of Binding, Access Control, and Conditional Settlement)

[0771] This exemplary embodiment demonstrates how the double-predictor binding, multiattribute access policies, and conditional settlement can be combined into a single workflow. This unified architecture ensures that a primary token can:

[0772] • Be securely bound to secondary tokens via reciprocal commitments (Embodiment Bl),

[0773] • Require a user to satisfy multiple access attributes (Embodiment B2), and

[0774] • Enforce conditional logic before redemption or payout (Embodiment B3).

[0775] 2) High-Level Flow

[0776] 1. Issuance

[0777] • A SettlementToken (primary token) is minted, representing a $1,000 obligation.

[0778] Secondary tokens (e.g., stablecoin reserves or proof-of-value tokens) are minted simultaneously and cryptographically bound via double-predictor commitments. In some embodiments, the primary and secondary tokens may embed or reference subdomain identifiers consistent with embodiments of a system’s subdomain-based architecture. • The SettlementToken also embeds a policy requiring the redeemer to hold a KYC credential and a RoleToken proving “Engineer” clearance.

[0779] • Metadata includes additional conditions: expiry at Block #500,000 and an FX threshold check via an oracle.

[0780] On-chain anchor emitted:

[0781] Issued(S_id=0xl001, MR_V, H(S), conditions_root, policy _root)

[0782] 1. Redemption Attempt

[0783] Alice initiates redemption by presenting:

[0784] 2. Primary SettlementToken #1001

[0785] 3. Bound Secondary Tokens (per MR_V)

[0786] 4. Access attributes (Identity Token #301 + RoleToken #302)

[0787] 5. Salt S.

[0788] 6. Smart Contract Verification (Atomic)

[0789] Step 1: Anchor checks — Verify existence of issuance record with MR_V + H(S) + Attorney Docket Number: TT-0003 condi tions root.

[0790] Step 2: Binding checks — The system verifies the Secondary Tokens using on-chain commitments defined by the Primary Token; it recomputes C I and each C_Vi and confirms matches for all tokens.

[0791] Step 3: Access checks — Verify Alice owns IdentityToken #301 and RoleToken #302, and both remain valid / unrevoked.

[0792] Step 4: Conditional checks — Ensure current block < 500,000 and USD / EUR > 0.9 via oracle.

[0793] Step 5: Outcome — If all checks pass, SettlementToken #1001 is marked redeemed and $1,000 in stablecoin is transferred to Alice.

[0794] 7. Failure Handling

[0795] If binding fails — presented tokens don’t match issuance — revert, SettlementToken remains valid.

[0796] If access policy fails — Alice lacks required attributes — deny, SettlementToken remains valid.

[0797] If conditional logic fails —> e.g., expiry passed or FX rate below threshold — ► deny, SettlementToken remains valid.

[0798] 3) Worked Example (Integrated Case)

[0799] S id = 0x1001

[0800] Bound Secondary Tokens: V_1 = 0x5001, V_2 = 0x5002

[0801] Access Policy: requires IdentityToken #301 + RoleToken #302 (“Engineer”)

[0802] Conditions: expiry = Block #500,000; FX oracle threshold USD / EUR > 0.9

[0803] Salt = 0x69BFA1531A7C...

[0804] Anchors: Issued(0xl001, MR_V, H(S), conditions_root, policy _root)

[0805] Redemption success case:

[0806] • Alice presents SettlementToken #1001, Secondary Tokens #5001 / #5002, IdentityToken #301, RoleToken #302, and salt S.

[0807] • Contract verifies:

[0808] 1. C I and C_Vi match — binding confirmed.

[0809] 2. Alice owns #301 and #302 — > access confirmed.

[0810] 3. Block = 450,000 (<500,000) and oracle FX rate = 0.95 (>0.9) — conditions

[0811] confirmed. Attorney Docket Number: TT-0003 4. SettlementToken burned —> 1,000 USDC transferred to Alice.

[0812] Failure case (policy): Bob presents SettlementToken #1001 without IdentityToken #301 — » access fails — redemption denied, SettlementToken remains valid.

[0813] 4) Benefits of Integrated Architecture

[0814] Unified security: All three checks (binding, access, conditions) are required, closing attack vectors individually.

[0815] Multi-domain applicability:

[0816] • Finance: Secure, programmable remittance with KYC + FX conditions.

[0817] • loT / Logistics: Shipment SettlementToken requires sensor proofs and jurisdiction attributes.

[0818] • Certification: Tokenized diploma requires student ID + institutional signature + valid accreditation credential.

[0819] • Atomicity: All checks execute in a single transaction — no race conditions, no frontrunning.

[0820] • Modularity: Each component (binding, access, conditions) can be reused independently or in any combination.

[0821] In this particular integrated embodiment, a single blockchain smart contract atomically enforces double-predictor token binding, multi-attribute access control, and conditional redemption logic, ensuring that the designated outcome occurs only when all pre-committed tokens, attributes, and conditions are satisfied in the same transaction.

[0822] With respect to Fig. 14, Flow:

[0823] • Step A (Binding Verification): Smart contract 410 recomputes C I from presented Secondary Tokens 404a / b and salt S, and compares against Settlement Token 402.

[0824] Likewise, each Secondary Token’s C_Vi is checked against l id.

[0825] • Step B (Access Verification): Contract 410 verifies that redeemer’s wallet holds Attribute Tokens 406a / b (Identity + Role), and checks time validity if required.

[0826] • Step C (Conditional Checks): Contract 410 queries external oracles and system clocks 408 to validate expiry, FX rate, loT event completion, or other conditions.

[0827] • Step D (Atomic Outcome): If all checks succeed, contract 410 bums Settlement Token 402, emits a Redeemed event, and triggers payout / transfer to the beneficiary (412). If any check fails, an AccessDenied or RedeemFailed event is emitted, and Settlement Token 402 remains valid for future attempts.

Claims

Attorney Docket Number: TT-0003Inventor and Applicant: Matthew Smith Shepley CLAIMSWhat is claimed is:

1. (Original) A computer-implemented method for cryptographically binding a blockchainbased primary token with one or more secondary tokens to ensure redemption integrity, the method comprising:causing to be issued, on a blockchain network, a primary token that includes metadata storing a first cryptographic commitment associated with an issuance context of at least one secondary token;causing to be issued, on the blockchain network, the at least one secondary token, each secondary token including a second cryptographic commitment associated with said primary token,wherein the first cryptographic commitment and the second cryptographic commitment are generated such that they form a mutual cryptographic binding between the primary token and the at least one secondary token.

2. (Original) The method of claim 1, wherein the first cryptographic commitment and the second cryptographic commitment each comprise a hash value computed using a predetermined hash algorithm.

3. (Original) The method of claim 1, wherein the first cryptographic commitment encodes a commitment to a set comprising a plurality of secondary tokens.

4. (Original) The method of claim 1, further comprising verifying a redemption of the primary token by performing a non-interactive, deterministic verification based solely on on-chain commitments and metadata, without requiring any handshake, counterparty messaging, or off-chain validation.Attorney Docket Number: TT-0003Inventor and Applicant: Matthew Smith Shepley5. (Original) The method of claim 1, wherein the primary token is a non-fungible token recorded on the blockchain network and wherein the at least one secondary token comprises one or more fungible digital asset tokens recorded on the same blockchain network.

6. (Original) The method of claim 1, wherein the issuing of the primary token and the at least one secondary token is performed by a smart contract on the blockchain network.

7. (Original) The method of claim 1, wherein a smart contract will reject redemption of the primary token when a presented secondary token fails to satisfy a cryptographic commitment associated with the primary token.

8. (Original) A computer-implemented method for enforcing multi -attribute token-based access control in an access policy for a protected resource, the method comprising:causing to be issued, on a blockchain network, a non-fungible access token that contains metadata defining an access policy requiring possession of a plurality of distinct attribute tokens by a user, wherein the access token’s metadata is stored on-chain such that updates to the access policy or revocation of the access token are enforceable through blockchain transactions;receiving, from a user device, an access request for a protected resource;verifying, via a decentralized verification process, that a blockchain address controlled by the user holds the plurality of distinct attribute tokens required by the access policy; andupon verification, granting the user access to the protected resource.Attorney Docket Number: TT-0003Inventor and Applicant: Matthew Smith Shepley 9. (Original) The method of claim 8 wherein each attribute token corresponds to a different required condition for access.

10. (Original) The method of claim 8, further comprising deriving a domain-subdomain token by reverse-parsing a fully qualified domain name and resolving the domain-subdomain token via a blockchain-based name service as part of the verification process.

11. (Original) The method of claim 8, wherein receiving the access request includes receiving a cryptographic proof of possession generated through a digital signature or zeroknowledge proof.

12. (Original) The method of claim 8, further comprising updating the metadata of the non- fungible access token to modify the access policy or to revoke the access token entirely, wherein subsequent access attempts will automatically enforce the updated access policy or prevent access if the token is revoked.

13. (Original) A computer-implemented method for conditional settlement of a blockchainbased primary token, the method comprising:causing to be issued, on a blockchain network, a primary token comprising metadata defining one or more redemption conditions and payout instructions, wherein redemption of the primary token is performed by a smart-contract on-chain wherein the smart-contract:receives a redemption request for the primary token;automatically verifies that each of the one or more redemption conditions is satisfied; andresponsive to all redemption conditions being satisfied, triggers execution of the payout instructions.Attorney Docket Number: TT-0003Inventor and Applicant: Matthew Smith Shepley 14. (Original) The method of claim 13, wherein the smart contract’s verification of the one or more redemption conditions comprises retrieving external data from a blockchain oracle.

15. (Original) The method of claim 13, wherein at least one of the one or more redemption conditions includes an identity verification requirement.

16. (Original) The method of claim 13, wherein at least one of the one or more redemption conditions includes an expiration time or blockchain block number after which redemption of the primary token is disallowed.

17. (Original) The method of claim 13, wherein the one or more redemption conditions include at least one of: (i) confirmation of a supply-chain event recorded by an Internet-of-Things (loT) device, or (ii) verification of an environmental parameter recorded by an Internet-of- Things (loT) device.

18. (Original) The method of claim 13, wherein the one or more redemption conditions are satisfied in multiple stages recorded on-chain before execution of the payout instructions.

19. (Original) The method of claim 13, wherein triggering execution of the payout instructions causes a release of funds or assets through a bank, a payment rail, or a system external to the blockchain.

20. (Original) The method of claim 13, wherein the smart-contract’s automatic verification does not require an off-chain validation step.

Images