Blockchain system and method for authenticated use of a stable fungible token

Abstract

FIG. 4 reflects a process of minting and using a smart contract within a conditional stable cryptotoken embedded on a blockchain. Initially, a recipient is issued with a status certificate reflecting characteristics of their organisation reflecting activity or company status, such as a carbon neutral objective for a charity. A conditional stable coin, in the typical form of a fungible token "FT", is subsequently minted to include stipulated conditions of use, with the conditional stable coin pegged to a tangible asset held in a reserve account. Upon attempted transfer or use of the conditional stable coin to a recipient wallet, blockchain system intelligence determines whether the characteristics in the status certificate associated with the recipient wallet correlate precisely with the smart contract within the conditional stable coin. If there is correlation, transfer and control is approved and the blockchain record accordingly updated. If there is any subsequent attempt to redeem the tangible asset by use of the conditional stable coin from any recipient wallet not containing aligned correlated characteristics with the smart contract, then redemption is stopped and, if appropriate, an audit trail established, reported and recoded in a blockchain record for the relevant conditional FT.

Description

[0001] TIN-P10955WO1: 2 December 2025

[0002] -1-

[0003] BLOCKCHAIN SYSTEM AND METHOD FOR AUTHENTICATED USE OF A STABLE FUNGIBLE TOKEN

[0004] FIELD OF THE INVENTION

[0005] This invention relates, in general, to a blockchain system and a method by which a cryptotoken is minted with an embedded conditional smart contract. The invention is particularly applicable to stable coins and their subsequent transfer and authenticated and approved use irrespective of a wallet location or ownership of the stable coin. More particularly, embodiments of the present invention relate to a system and method which restrict use and ongoing distribution of fungible tokens “FTs” minted either to a regulated or unregulated wallet.

[0006] SUMMARY OF THE PRIOR ART

[0007] Blockchain is essentially a distributed database that is shared among the nodes of a public computer network. The blockchain is overseen by distributed computing intelligence. As a database, a blockchain stores information electronically in digital format.

[0008] Blockchains are best known for their role in cryptocurrency systems, such as Bitcoin, and are arranged to maintain a secure and decentralized record of transactions. The concept behind blockchain is that it guarantees the fidelity, integrity, and security of a record of data and generates trust without the need for a trusted third party. However, on a generally never basis, an individual or organization cannot control or manipulate the protocol behind a cryptocurrency because it is cryptographically secure. Furthermore, there is no, little or limited and ineffectual regulation of certain aspects of blockchains on both a national or international governmental level, with this lack of oversight leading to questionable use of block technology in potentially dubious or otherwise entirely illegal activities, such as money laundering, terrorist financing or narcotics trafficking in the latter case.

[0009] One key difference between a typical database and a blockchain is how the data is structured. A blockchain collects information together in groups, known as blocks, which hold sets of information. Blocks have certain storage capacities and, when filled, are TIN-P10955WO1: 2 December 2025

[0010] -2- closed and linked to the previously filled block thus forming the “blockchain”. All new information that follows that freshly added block is compiled into a newly formed block that will then also be added to the chain once filled. A conventional database usually structures its data into tables, whereas a blockchain, like its name implies, structures its data into chunks (blocks) that are strung together. This data structure inherently makes an irreversible timeline of data when implemented in a decentralized nature. When a block is filled, it is set in stone and becomes a part of this timeline. Each block in the chain is given an exact time stamp when it is added to the chain.

[0011] Blockchain technology is, for example, the basis for cryptocurrency transactions, such as supported by Bitcoin. Another platform is Ethereum which is both similar and dissimilar to Bitcoin. For example, both are cryptocurrencies that can be traded, and both are acquired through mining activity of a numerically limited pool of coins or tokens. Cryptocurrencies are fungible in that one ETH can be exchanged for a different ETH without any consequence or loss.

[0012] Other blockchain technologies, such as Solano, exist. These may have certain advantages or disadvantages relative to more accepted mainstream blockchains of Bitcoin and Ethereum.

[0013] In dealing with blockchain cryptocurrencies, it is typical to use a cryptocurrency exchange firm, such as CoinBase. Coinbase is a cryptocurrency trading and investing platform that offers users the ability to buy, sell, and exchange over one hundred tradable cryptocurrencies such as Bitcoin, Ethereum, and Dogecoin. Unlike traditional brokerage firms, cryptocurrency exchanges are generally not members of the Securities Investor Protection Corp. (SIPC) and the like. Therefore, unless user terms specify otherwise, investors with cryptocurrency assets commingled on a custodial cryptocurrency exchange could potentially lose their funds as unsecured creditors. Coinbase, however, is regulated in the UK by the UK Financial Conduct Authority because such blockchain financial transactions are subject to regulatory approval / control, although the specific form of account / wallet holder validation is not known. TIN-P10955WO1: 2 December 2025

[0014] -3-

[0015] Contrastingly, non-fungible tokens “NFTs” are unique digital assets addressing certifiable things, for example, photographs, music, videos, and trading cards. Consequently, NFTs are not mutually interchangeable / fungible since each NFT is in itself unique. NFTs are managed in a digital ledger and traded on the web. For instance, rather than buying a genuine photo to show on a divider, the purchaser gets a unique digital file. Nearly any digital asset, for example, a piece of collectible advanced characters, virtual land, or unique online media posts, can be made and bought as an NFT. NFTs are joined to explicit qualities with certificates of authenticity, which means that the digital assets cannot be traded or supplanted with each other because each NFT exists on a decentralized digital platform.

[0016] Fungible tokens or non-fungible tokens “NFTs” minted on the blockchain therefore represent something of value, whether a commodity or a financial asset. For cryptocurrency, it is usual for the token to be a “stable coin” where the value of a digital asset is supposed to be pegged to a reference asset, such as fiat money, exchange-traded commodities (such as precious metals or industrial metals), or another cryptocurrency. With pegging, the real-world asset is essentially held in escrow so the transfer of the representative coin, i.e., an FT or NFT, to a new ownership provides the new owner with access and control over the real-world item, such as US dollars in the exemplary case of fiat currency.

[0017] Ethereum is a decentralized global software platform having its own native cryptocurrency, the ether or “ETH”, and it has an operational protocol that offers incentives to process transactions and computational activities. The ETH is compatible with and enables use of NFTs. Moreover, the ETH supports decentralized finance, decentralized autonomous organizations, and the unregulated Metaverse. Ethereum can be used by anyone to create any secured digital technology they can think of. It has a token designed for use in the blockchain network, but it can also be used by participants as a method to pay for work done on the blockchain. The blockchain technology that powers Ethereum enables secure digital ledgers to be publicly created and maintained. TIN-P10955WO1: 2 December 2025

[0018] -4-

[0019] Decentralized applications (dApps) are digital applications or programs that exist and run on a blockchain or peer-to-peer (P2P) network of computers instead of a single computer. DApps (also called “dapps”) are outside the purview and control of a single authority. DApps can be developed for a variety of purposes including gaming, finance, and social media. Since dApps are decentralized, they are free from the control and interference of a single authority and therefore safeguard user privacy but have a lack of censorship.

[0020] With non-regulated platforms, such as Bitcoin and Ethereum, the setting up of the account simply requires an account hash or account / wallet address to be established. For example, it would be possible to set up a blockchain account based on a user pseudo-name “Yogi Bear" rather than conventionally just a wallet address, and then to fill the resultant established wallet with mined currency or acquired cryptocurrency having financial real- world tradeable worth / value. The wallet may also include NFTs. In other words, in setting up such unregulated wallets there is no need to supply or validate personal identification “ID”, with the resulting cryptocurrency wallet not linked to a person in any way. The lack of any relationship means that, in the exemplary case of monetary transaction in commercial transactions, the non-regulated platform cannot be broken down (1) to identify the owners of particular wallets [which is evidently advantageous for anyone who is morally corrupt and involved in illegal activities, such as blackmail and trafficking], (2) to identify the chain of custody of any value in the wallet, (3) to identify or track the value in a particular wallet, and (4) is problematic for those individuals who have legitimate business reasons for trading in blockchain coins / tokens on non-regulated platforms and for whom establishment of trust is important.

[0021] There is also a second, flip side to the problem of anonymity in non-regulated platforms. That is, when the need arises to communicate personal data through a non-regulated platform for reasons of validation of an individual, it either cannot be done or otherwise the communicated personal data must be entirely open / visible to the recipient and thus subject to potential unwanted hacking, data scraping and subsequent general misuse. TIN-P10955WO1: 2 December 2025

[0022] -5-

[0023] With Ethereum wallets and similar wallets on other unregulated platforms, a particular commercial issue arises with banking transactions. Particularly, there is no present way to establish (a) the actual real identity of the owner (i.e., the user of the wallet is a proxy / front for someone else or otherwise is fake) and / or (b) the provenance of the wallet’s content value since the wallet’s owner has not gone through any validating sign- off. Expressing this differently, an unregulated trading system has qualities of being impervious to being, i.e., it cannot be, broken down to (i) identify ownership of individual wallets stored on its public ledger, or (ii) identify a chain of custody of any item stored in its respective wallet. Consequently, use of an (exemplary) Ethereum wallet is restricted in monetary / banking commerce because of the failure to confirm compliance with antimoney laundering “AML” regulations. This is a technical security problem.

[0024] In terms of banking transaction security and protection measures, these can in fact be broadly classified as issues relating either to AML and / or Know Your Customer “KYC”. To date, commercial banking institutions attempt to restrict use of transaction, especially cryptocurrencies, by imposing unrealistic or prejudicial levels of AML and / or KYC compliance based on the identification of countries of perceived concern , e.g., Albania, Cayman Islands, Malta, Iran and others [at June 2022], as reflected by the Law Society (see https: / / www.lawsociety.or .uk / topics / anti-money-launderin / hi h-risk-third- countries -for- ami-purposes ) . This list of affected countries varies with time based on global economic and political reports that weight and / or prejudice individuals based on association with the individual’s movements and geography. The present banking regime simply makes compliance with AML / KYC very difficult in these countries of concern principally because there presently exists no robust technical solution that links unregulated accounts [making use of blockchain] into a regulated environment [in which an individual would be concerned trustworthy based on a verified legitimate identity of a person who is both determined legally safe / regulatory compliant and who is operating a crypto-wallet]. KYC accreditation is, in other words, presently based on hard-coded and inflexible questions and a rule-based ground truth where the risk is assessed as either black (high) or low (white / approved) and in which shades of grey are either forcibly ignored and TIN-P10955WO1: 2 December 2025

[0025] -6- subjected to frequently unnecessary, resource expansive and unproductive enhanced due diligence consideration.

[0026] For cross-geographical financial transactions using cryptocurrencies traded over web 3.0, more efficient mechanisms are required to see both or either the effective usage of enhanced web facilities and the non-prejudice treatment of individuals having respectively legitimate commercial trading intent and credible and verifiable physical presence, i.e., the account holder is a real and honest individual.

[0027] There is, in fact, a more significant AML issue associated with control of a minted NFT or FT. This problem relates to a KYC. This problem is the unauthorised or illicit use of cryptocurrency and particularly the trading in of the token to retrieve and therefore have direct personal control over the real-world item pegged to the cryptocurrency token. To provide a context, a government aid organisation might transfer certificates, i.e., coins and the like, to an external organization / company that purports to undertake aid work. Once received, the external organization might dishonesty or inappropriately make use of the pegged fiat currency, linked to the received certificate, to buy drugs, guns or to pay for services (and the like), which actions are incompatible with the intent of the government aid organisation and outside of the control of the [exemplary] government aid organisation given its loss of control. It could also be that the initial recipient of the token forwards the certificate to another independent or subsidiary or affiliated company which [second chained recipient operating in an arm’s length transaction] then uses the certificate to access fiat currency that it misuses to buy drugs, guns or to pay for services (and the like). With both the original owner and the initial recipient having no control over the actions of the later recipient (especially, but not necessarily, if at least at least one of the initial recipient or later recipient(s) is / are operating in an unregulated environment, the use of the certificate is uncontrolled and subject to fraudulent, illegal, unintended and / or non-audible misuse. In short, stable coins, FTs and NFTs are unfortunately presently all ripe to support money laundering activity.

[0028] SUMMARY OF THE INVENTION TIN-P10955WO1: 2 December 2025

[0029] -7-

[0030] According to a first aspect of the invention there is provided a method restricting at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service, the method comprising: providing a status certificate issued as a hash to a first wallet registered on a platform of a blockchain system containing distributed system intelligence, wherein the first wallet has an owner, the status certificate is issued by an accredited certificate issuer active on the blockchain system and the status certificate has certificate properties arranged to reflect at least one of: an authenticated operational business nature of the owner; authenticated commercial activities of the owner; and authenticated stated operating objectives of the owner; from a token sender, making a request to a minting authority on the blockchain system to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to at least one of: an operational business nature of a desired recipient of the cryptotoken; commercial activities of the desired recipient of the cryptotoken; operating objectives of the desired recipient of the cryptotoken; and an identified recipient for the cryptotoken; at the minting authority, minting to the token sender the requested cryptotoken and embedding a smart contract on the blockchain system for the cryptotoken that corresponds to the identified conditions of defined use of the cryptotoken; from a token sender, attempting to transfer the cryptotoken to an addressed wallet for use thereby; and using the distributed system intelligence to determine that the addressed wallet is the first wallet and has at least one of (a) a link to the identified recipient, and (b) a relevant status certificate for the first wallet and which relevant status certificate has at least one certificate property determined to be substantially consistent with the identified conditions of defined use of the cryptotoken as expressed in the smart contract; and using the distributed system intelligence to allow transfer, from the token sender, and use of the cryptotoken in and by the addressed wallet only when the addressed wallet is determined, by the distributed system intelligence, to at least contain one of (a) the link to the identified recipient and (b) the relevant status certificate.

[0031] The transfer is typically allowed only when the relevant status certificate is determined to exist in the addressed wallet. TIN-P10955WO1: 2 December 2025

[0032] -8-

[0033] All the conditions of the smart contract may need to be met for transfer of the cryptotoken to occur.

[0034] In a preferred embodiment, subsequent to transfer of the cryptotoken to the addressed wallet, the system may restrict at least one of transfer, use and redemption of the cryptotoken to or by a different wallet distinct to the addressed wallet.

[0035] In a preferred embodiment, subsequent to transfer of the cryptotoken to the addressed wallet, the system may authorise at least one of transfer, use and redemption of the cryptotoken to or by a different wallet distinct to the addressed wallet when the system intelligence determines that the different wallet contains a second relevant status certificate having at least one certificate property determined to be substantially consistent with the identified conditions of defined use expressed in the smart contract.

[0036] The method may include generating an audit trail on the blockchain for each failed transfer of the cryptotoken following determined absence of the relevant status certificate in the addressed wallet. The method can further include generating an alert message for each failed transfer and communicating said alert message sent to at least one of: the token sender; the minting authority; the addressed wallet; and the certificate issuer.

[0037] In a second aspect of the invention there is provided a method restricting at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service, the method comprising: providing a status certificate issued as a hash to a first wallet registered on a platform of a blockchain system containing distributed system intelligence, wherein the first wallet has an owner, the status certificate is issued by an accredited certificate issuer active on the blockchain system and the status certificate has certificate properties that authenticate historical operating characteristics directly linked to the first wallet; from a token sender, making a request to a minting authority on the blockchain system to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to identified operating characteristics for a recipient wallet; at the minting authority, minting to the token sender TIN-P10955WO1: 2 December 2025

[0038] -9- the requested cryptotoken and embedding a smart contract on the blockchain system for the cryptotoken that corresponds to the identified conditions of defined use of the cryptotoken; from a token sender, attempting to transfer the cryptotoken to an addressed wallet for use thereby; using the distributed system intelligence to determine that the addressed wallet has a relevant status certificate consistent with the identified conditions expressed in the smart contract; and using the distributed system intelligence to allow transfer, from the token sender, and use of the cryptotoken in and by the addressed wallet only when the relevant status certificate is determined to be present.

[0039] In a further aspect of the invention there is provided a blockchain system having serverbased entities interconnected over a network, the server-based entities including at least: distributed system intelligence; a token sender; a minting authority; a certificate issuer; and a plurality of wallets registered within the blockchain system; wherein: the distributed intelligence is arranged to restrict at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service; the certificate issuer is arranged to issue, as a hash, a status certificate to a first wallet of the plurality of wallets and the status certificate has certificate properties arranged to reflect at least one of: (i) an authenticated operational business nature of an owner of the first wallet; (ii) authenticated commercial activities of the owner; and (iii) authenticated stated operating objectives of the owner; the token sender is arranged to make a request to the minting authority to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to at least one of: (i) an operational business nature of a desired recipient of the cryptotoken; (ii) commercial activities of the desired recipient of the crypto token; (iii) operating objectives of the desired recipient of the crypto token; and (iv) an identified recipient for the cryptotoken; the minting authority is arranged to mint to the token sender the requested cryptotoken and further to embed a smart contract on the blockchain system for the cryptotoken that corresponds to the identified conditions of defined use of the cryptotoken; the token sender is arranged to attempt transfer the minted cryptotoken to an addressed wallet for use thereby, the addressed wallet being one of the first wallet and a different independent wallet of the plurality of wallets; and the distributed system intelligence is arranged to: determine that the addressed wallet is the TIN-P10955WO1: 2 December 2025

[0040] -10- first wallet and has at least one of (a) a link to the addressed wallet, and (b) a relevant status certificate for the first wallet and which relevant status certificate has at least one certificate property determined to be substantially consistent with the identified conditions of defined use of the cryptotoken as expressed in the smart contract; and authorise the token sender to transfer the cryptotoken to the addressed wallet, thereby to allow use of the cryptotoken in and by the addressed wallet only when the addressed wallet is determined, by the distributed system intelligence, to at least contain one of (a) the link to the identified recipient and (b) the relevant status certificate.

[0041] The distributed system intelligence may be arranged to transfer the cryptotoken only when the relevant status certificate is determined to exist in the addressed wallet.

[0042] All the conditions of the smart contract may need to be met before the distributed system intelligence authorises transfer of the cryptotoken to the addressed wallet.

[0043] The distributed system intelligence may be further arranged, subsequent to transfer of the cryptotoken to the addressed wallet, to restrict at least one of transfer, use and redemption of the crypto token to or by a different wallet distinct to the addressed wallet.

[0044] The distributed system intelligence is further arranged, subsequent to transfer of the crypto token to the addressed wallet, may be further arranged to permit at least one of transfer, use and redemption of the cryptotoken to or by a different wallet distinct to the addressed wallet when the system intelligence determines that the different wallet contains a second relevant status certificate having at least one certificate property determined to be substantially consistent with the identified conditions of defined use expressed in the smart contract.

[0045] The distributed system intelligence may be arranged to generate an audit trail on the blockchain for each failed transfer of the cryptotoken following determined absence of the relevant status certificate in the addressed wallet. TIN-P10955WO1: 2 December 2025

[0046] -11-

[0047] The distributed system intelligence may be arranged to generate an alert message for each failed transfer and communicating said alert message sent to at least one of: the token sender; the minting authority; the addressed wallet; and the certificate issuer.

[0048] In yet another aspect there is provided a blockchain system having server-based entities interconnected over a network, the server-based entities including at least: distributed system intelligence; a token sender; a minting authority; a certificate issuer; and a plurality of wallets registered within the blockchain system; wherein: the distributed intelligence is arranged to restrict at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service; the certificate issuer is arranged to issue, as a hash, a status certificate to a first wallet of the plurality of wallets and the status certificate having certificate properties authenticating historical operating characteristics directly linked to the first wallet; the token sender is arranged to make a request to the minting authority to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to identified operating characteristics for a recipient wallet; the minting authority is arranged to mint to the token sender the requested cryptotoken and further to embed a smart contract on the blockchain system for the cryptotoken that corresponds to the identified conditions of defined use of the cryptotoken; the token sender is arranged to attempt transfer the minted cryptotoken to an addressed wallet for use thereby, the addressed wallet being one of the first wallet and a different independent wallet of the plurality of wallets; and the distributed system intelligence is arranged to: determine that the addressed wallet is the first wallet and has relevant status certificate consistent with the identified conditions expressed in the smart contract; and authorise the token sender to transfer the cryptotoken to the addressed wallet, thereby to allow use of the cryptotoken in and by the addressed wallet only when the addressed wallet is determined, by the distributed system intelligence, to include the relevant status certificate.

[0049] Advantageously, the invention provides a stable coin (usable across an unregulated or regulated platform of a blockchain environment) with an associated smart contract that defines cryptographically coded levels of security that control access and communication TIN-P10955WO1: 2 December 2025

[0050] -12- of the stable coin (or fungible token or NFT) so as to prevent non-approved access to or disposal of the stable coin or otherwise any form of realisation of pegged fiat currency or the like, including access permitting physical possession or material control of any other commodity, service or article of value. The concepts of the embedded smart contract and check process may, furthermore, be applied more widely to any token representing any item or service. The interactions between generally distributed system intelligence and connected servers owned by independent entities within the blockchain environment collectively lend themselves to preventing money laundering in cryptocurrency transactions, and provide a mechanism that cedes general control with / to an approved minting authority responsible for setting up stipulated smart contract conditions at the time of coin / certificate minting.

[0051] In overview, the preferred embodiments described a new process of minting and using a a new conditional stable cryptotoken embedded within a smart contract on the blockchain. Initially, a recipient is issued with a status certificate reflecting characteristics of their organisation reflecting activity or company status, such as a carbon neutral objective for a charity. A conditional stable coin, in the typical form of a fungible token “FT”, is subsequently minted to include stipulated conditions of use, with the conditional stable coin pegged to a tangible asset held in a reserve account. Upon attempted transfer or use of the conditional stable coin to a recipient wallet, blockchain system intelligence determines whether the characteristics in the status certificate associated with the recipient wallet correlate precisely with at least pre-defined minimally acceptable smart contract conditions within the conditional stable coin. If there is acceptable correlation, transfer and control is approved and the blockchain record accordingly updated. If it is determined by the system intelligence that there is no qualifying status certificate that satisfies minimal smart contract conditions, then the identity of the offending wallet may be reported as suspicious and / or reported on the blockchain. Reporting may be to the token sender, certificate issuer or other blockchain entity. Regardless or reporting, if there is any subsequent attempt to redeem the tangible asset by use of the conditional stable coin from any recipient wallet not containing aligned correlated characteristics with the TIN-P10955WO1: 2 December 2025

[0052] -13- smart contract, then redemption is stopped and, if appropriate, an audit trail established, reported and recoded in a blockchain record for the relevant conditional FT.

[0053] The beneficial effect of the system intelligence’s interpretation and intervention is to prevent and / or restrict - but always to control - the transfer of cryptotokens to only preapproved organisations with verified / authenticated business activities, organisational setup, and / or established commercial dealings that satisfy, i.e., are never inconsistent with, the token supplier’s objectives as originally set at the point of minting the cryptotoken. Adaptation of the smart contract may take place under the sole discretion of the token sender, with the adaptation on the nature of the recipient updated on the blockchain by the minting authority or holder of the peg. Update of the status certificate through authentication and validation by the certificate issuer is, however, preferred over adaptation of the smart contract since the certificate issuer can be considered to be generally independent and thus an independent server arbitrator within the blockchain environment.

[0054] The system of the preferred embodiments thus supports anti-money laundering control by denying any and all potential recipients (whether direct or indirect arm’s length recipients) access to the end tangible asset. The system of the preferred embodiments thus effectively renders the minted cryptotoken valueless to all but approved recipients who satisfy the smart contract conditions (either wholly or in a satisfactory part that is consistent with the tokens senders) identified conditions of defined use.

[0055] BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings in which:

[0057] FIG. 1 (comprised from FIGs. la and lb) is a system architecture of blockchain system supporting regulated and unregulated trading platforms;

[0058] FIG. 2 is a function interaction flow process diagram showing message interactions and content delivery between functional blocks within the system architecture of FIG. 1, especially in the context of wallet linking between regulated and unregulated trading platforms; TIN-P10955WO1: 2 December 2025

[0059] -14-

[0060] FIG. 3 shows manging entities within the blockchain system of FIG. 1, and messaging interactions arising therebetween in accordance with a preferred embodiment of the present invention; and

[0061] FIG. 4 is a function interaction flow process diagram showing preferred messaging interactions and content delivery between the system management entities of FIG. 3.

[0062] DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0063] Referring to FIG. 1, there is shown a system architecture 10 for a blockchain system. The system, as will be appreciated, is based around a communications network 12, such as a wide area network, through which a multiplicity of servers, databases and client devices interact through any suitable messaging protocol, as will be readily appreciated. Server functionality may be localised but equally it may also be distributed, especially with respect to those aspects that are based on the use of blockchain technology. FIG. 1 therefore provides an overview of the functions and high-level database content without being limited to the specific structures shown. Messaging into, through and out of the network 12 may be supported by wireless and / or wireline communication protocols with all messaging preferably being securely end-to-end encoded on a point-to-point basis.

[0064] In more detail, the system will include multiple client devices 14, although for simplicity of the diagram only a single client device is shown. The client device 14 may be a smartphone or a computer or the like. The client device 14 includes an interface 16 through which a user 18 can enter and receive data. The user interface will include a display and other input / output devices, as is conventional. The client device also includes processing intelligence 20 that controls operation of the device, and which executes programs and / or apps 22 stored in memory (“mem”) 24. Functional software used by the client device may be web-based, i.e., supported by a browser. The operational software may be based on artificial intelligence that permits interpretation of data and an evaluation of user credibility based on a threshold score derived or implied from available data. TIN-P10955WO1: 2 December 2025

[0065] -15-

[0066] A private ledger database 26 is part of a regulated platform 27 in which user identification is validated. The regulated platform thus includes one or more servers 30 supporting local and / or distributed processing as required, for example, in relation to cryptocurrency banking systems [such as those provided by the company Tintra] that make use of private blockchain technology. Server functions, which are explained below in terms of interactions and effects, include: i) a linkage module function 42; ii) an open-source intelligence “OSINT” module 44, although this is optional and may be replaced or supplemented by a third-party external OSINT 50 to the private server but accessible via the network 12; iii) a certificate module 46 for issuing hashed certificates; and iv) a verification module 48 which, again, is optional and dependent upon how linking between a regulated private wallet and one or more unregulated public wallets is validated for an identified common user.

[0067] The private ledger 26 of the regulated platform typically includes for each registered user: i) a usemame / unique identity 32; ii) a private wallet address 34 (such as supported by blockchain) linked to the username / unique identity 32; iii) a document description 36 identifying the nature of different forms of documents held in the private wallet address 34; iv) a unique secure hash 38 coded for a document certificate issued against each type of document stored within a wallet; and a v) at least one link 40 to one or more public wallets supported on one or more unregulated platforms, such as Ethereum and Tezos.

[0068] Registration of each user 18 into the regulated platform is based on establishing proof of identity. This is a conventional process for regulated systems and is well-known to typically include provision of official original or certified documents, biometric data entry, proof of recent residence and / or proof of existing employment. Other validation metrics exist. The point is simply that the private platform, e.g., a regulated platform account run TIN-P10955WO1: 2 December 2025

[0069] -16- by a company (nominally called “Tintra”) for accounts (nominally called “Tintra account”) that support a cryptocurrency wallet, has a confirmed real person as owner and which real person is appropriately validated by substantiating documentation compliant with legislation.

[0070] As indicated above, at least one independent third-party external OSINT module 50 [in the sense that the third-party OSINT module is outside of the regulated private platform] may be connected to the network 12. Irrespective of whether the OSINT modules is internally located within a private / regulated platform or externally and independent, the OSINT module 44, 50 operates as a backend application programming interface “api” arranged, in response to available personal data, to scrape additional personal data from one or more different source databases through one or more publicly available independent servers. For example, given a social media account, the OSINT module may fetch named photographic data posted on the social media account, or other information including (but not limited to) employment, education, family history and onwards into convictions and other personal data (such as high-level insurance policy information), etc. In FIG. 1, these data sources are represented by social media server 52 and connected database 54, with user data typically self-entered into the database by an identifiable user having some form of public account, such as a FaceBook® page or other searchable online record, such as a Linkedln® business account. Whilst the OSINT module 46, 50 is described as having access to public databases, it may also have approved access to private databases and thus personal confidential information.

[0071] The system of FIG. 1 further includes public blockchain servers 60 such as those supporting the Ethereum platform described above. At least one of these public servers (on a non-regulated platform) include a public certificate module 62 as well as other functional processing technology 64. The public blockchain servers 60 have access to a public database ledger 66 in which is stored, as a minimum, a public wallet address 70 for a user account and non- transferable NFTs (typically obtained by writing a smart contract). The public database ledger 66 may include additional information such as NFTs (and all that they represent) and transaction histories. An optional user account identity 68 and TIN-P10955WO1: 2 December 2025

[0072] -17- related information may be included but generally, for the reasons given above, this is not the case for current blockchains. The non-transferable NFT placed onto the unregulated wallet are, in effect, a permanent record for a description 72 of document types (e.g., driving licence, credit report, passport) and a secure certificate code hash 74 unique to each document. Each non-transferable NFT is written to the account by a public certificate module 62 in response to (in one path) the certificate module 46 in the private platform 27. For example, a smart contract on the public blockchain server(s) 60 would permit a private wallet address to be basis for the generation (by the certificate [issuance] module 46 in the private regulated platform 27) of certificates and related descriptions that verify the legitimacy of documents that unequivocally are attributable / link to a verifiable identity of a real person who owns / accesses the address of the unregulated wallet. Further, the smart contract would permit the storage of these unique non-transferable NFTs, and limited subsequent access. More specifically, the nature of each non-transferable NFT is that it cannot be moved from the unregulated wallet or in any way changed by any interaction other than an interaction directly involving the linked regulated wallet.

[0073] Finally, the system 10 of FIG. 1, can include further service providers having general access privileges to public space, such privileges supported by servers and databases of the service provider. For example, the service provider could be a university admissions department or an on-line retailer. The nature of the interaction with the functional aspects of the system, particularly in the context of the obfuscation of verified personal data, will be described subsequently.

[0074] The public wallet may include coins or tokens of value, including cryptocurrencies and NFTs.

[0075] FIG. 2 is a function interaction flow process diagram 100 showing messaging interactions and content delivery between functional blocks within the system 10 of FIG. 1. These interactions are particularly in the context of permitting wallets on regulated and unregulated trading platforms to be linked securely together. References to performance of functions by specific software / program modules on servers with the system of FIG. 1 TIN-P10955WO1: 2 December 2025

[0076] -18- should therefore be understood to include the generation of push and pull messages and / or query and return messages in a data message format suitable for the communication network, e.g., encoded packet-based data messages.

[0077] The different registration processes for a regulated and non-regulated wallet are well documented, are outlined generally above and regardless are well-known. In the context of the invention, it is sufficient to understand that establishing a regulated on-line currency account (such as provided by Cex.io - Bitcoin & Cryptocurrency Exchange & Trading - Buy & Sell Crypto - CEX.IO - and Tintra) requires user identity verification and that verification requirements can vary between different platforms. Conversely, an unregulated wallet which can include NFTs, can be obtained using a less stringent process that seldom if ever requires, during set-up and use, any form of account holder identification other than an account name (which could be a pseudo-name) and / or limited other data, such as a pay-as-you-go mobile phone number acquired with an off-the-shelf SIM purchase. As indicated above, non-regulated accounts, such as Ethereum, can therefore be established without any identity verification and indeed without a correlation to a real-world individual.

[0078] For each piece of verification data supplied by the user [for KYC and account opening purposes] and stored in the private ledger database 26 against (i) a document description and original document data 36 that articulates the nature and content of the verification data [such as a passport number, biometric data, a driving licence number and / or other personal data such as jobs and employment dates, home addresses and dates and / or surnames of parents, etc.], against (ii) a regulated account identifier 32 for the user 18, and / or against (iii) a unique private wallet address 34, system intelligence within the domain of the regulated platform generates and stores a unique document certificate 38. The storage of the document content and document nature data 36 may be on a separate database which can be remote from the private ledger. The storage location is a design option and determined by whether the personal data 36 has wider but potentially confidential uses. TIN-P10955WO1: 2 December 2025

[0079] -19-

[0080] Preferably, the document certificate is in the form of an encrypted hash, such as an exemplary 256-bit hash for an SHA-2 cryptography structure. Consequently, each regulated wallet (simplistic account addresses “xyz#2...” and “Ay8$*...” for respective user / account names A. Smith and B. Jones in the simplistic and exemplary data table of FIG. 1, noting that addresses are conventionally hexadecimal of varying length) will contain a plurality of different unique document certificate hashes 38, with each hash mapped to a specific form of verifying document needed to establish the account. Consequently, the certificate hashes (or whatever securely encrypted form the certificates take) provide a yardstick measure of trust for the regulated wallet.

[0081] One of the issues addressed by the embodiments of the present invention relates to the establishment of an appropriate level of trust in the owner of the unregulated account, and how the level of trust (i.e., a KYC concern) can be surpassed to permit an unregulated wallet to be linked with a regulated wallet, thereby allowing access to the summed level of value held in all linked wallets whilst ensuring that integrity of the regulated platform [in which the regulated wallet operates] is not compromised.

[0082] Regardless of whether the wallet is a regulated wallet or an unregulated wallet, the skilled person will appreciate that there will typically be a private key / private log-in process that allows a user to open the respective wallet.

[0083] A) REGULATED ACCOUNT LOG-IN

[0084] On their computer or smartphone 14, the user instantiates 102 the banking app 22 to effect sign-in into their regulated wallet on the regulated platform 27. The app 22 - or other form of software - may be locally stored in memory or accessed in an active web session, with sign-in conducted using the interface 16. In response to the sign-in request [and assuming that the sign-in is validly authenticated for a valid regulated wallet address], a general server 25 for the regulated platform accesses 104 the private ledger database 26 to locate and return 106 prior stored wallet contents which, in additional to a stored cryptocurrency balance, may include certificates and related descriptions associated with specific activities that have been concluded successfully through operation of the regulated wallet. TIN-P10955WO1: 2 December 2025

[0085] -20-

[0086] The information supplied to the client’s device, e.g., the smartphone 14, is displayed to permit instructions to be sent into the general server 25, as will be understood. All this is conventional.

[0087] B) LINKAGE OF AN UNREGULATED WALLET TO A REGULATED WALLET

[0088] FIG. 2 outlines an exemplary process that supports a user-driven request for linkage of a regulated wallet to be established with an unregulated cryptocurrency wallet distributed in an unregulated platform. To achieve this, the user firstly enters / adds 110 a wallet address (of an unregulated platform) into the app 22. [Evidently, this wallet address must pre-exist and be valid.]

[0089] The first issue to be addressed is how can the system be suitably certain that the preexisting unregulated wallet address belongs to a bona fide individual with satisfactory financial integrity?

[0090] The app 22 firstly interacts with the linkage module 42 by forwarding 112 the address of the unregulated wallet. The linkage module communicates 114 the address of the unregulated wallet to the OSINT module 44, 50, with the OSINT module 46, 50 arranged to verify the unregulated cryptocurrency wallet address on unregulated (public) blockchain ledger 66, e.g., Ethereum or the like. Particularly, from the unregulated ledger 66, the OSINT module retrieves at least one and generally a plurality of candidate identifying data entries that are stored / listed within the unregulated wallet. Preferably, the OSINT module pulls 116, i.e., interrogates, the wallet to identify all wallet usages (i.e., transactional entries or recorded interactions and uses) to identify candidate identifying data entries. These candidate data entries may be NFTs but generally will be personal data relating to social and / or commercial interactions of the [possibly unnamed] account holder of the unregulated wallet to other online entities.

[0091] Armed with candidate identifying data entries, the OSINT module 46, 50 is arranged to parse each candidate identifying data entry to identify searchable links to social media TIN-P10955WO1: 2 December 2025

[0092] -21- platforms 52 and / or third-party databases, and then to establish a link to those social media platforms and / or third-party database in order to scrape 118 related databases 54 for identifying personal data 55 (such as personal telephone numbers, employment history, transactions involving NFTs, cryptocurrency transaction histories and smart interactions and events stored in the ledger of the unregulated wallet, addresses of other unregulated wallets, user-related geographic locations, images / pictures, email addresses, public government data and company affiliations, etc.) and / or further links that lead to additional databases further down the chain and which are associated with any other previously returned information. The returned data to the OSINT module thus yields a profile of the owner of the unregistered wallet through the return thereto of scraped identifying data sources that can be used in a test to verify the identity of an individual having either ownership of or access to the address of the unregulated wallet, and thus related direct use of cryptocurrency through the unregulated wallet or indirect use of cryptocurrency by a secondary unregulated wallet traced by the inquisitions made by the OSINT module.

[0093] The OSINT module 46, 50 returns 120 identifying data sources to the linkage module 44 of the private server(s) 30 in the regulated platform 27.

[0094] The identifying data sources that are independently scraped from outside of the regulated platform 27 can now be used internally with the regulated platform to assess whether the KYC verified account holder of the regulated wallet is the same as the actual account holder / user of the unregulated wallet. For example, embodiments may use web 2.0 opensource tech to scrape information about a person who own the unregulated public wallet (such as an Ethereum wallet) to provide insight, based on a generated honesty score for replies or commonly existing pre-registered data, as to whether the public unregulated wallet belongs to one and the same person.

[0095] As an alternative to the user 18 providing the address of the unregulated (Ethereum) wallet, an alternative process could involve the user logging into the regulated system and the system leveraging the existing KYC data used to establish the regulated account. In this arrangement, server functionality (e.g., the linkage module 42) uses selected data (such as TIN-P10955WO1: 2 December 2025

[0096] -22- an email address or other verified personal information) to engage the OSINT function to cause that function to search for unregulated wallet(s) addresses linked to KYC verified data. The alternative system therefore eliminates the need for the user to provide the address of the unregulated wallet. From this point onwards, the regulated / unregulated wallet linkage mechanism is as described above in the preferred embodiment.

[0097] Since the private ledger database 26 contains a record of submitted documents verified during KYC and AML clearance during set-up of the regulated wallet for a specific account holder, OSINT returned identifying data sources can be cross-referenced to and compared 122 with pre-existing document type and document content 36 whether stored in the private ledger database 26 or stored securely elsewhere, as indicated above. If there is a match between an item of the identifying data sources and the document type and prestored verified document content 36 for KYC / AML, then the already existing and corresponding unique document certificate hash for the specific document [used for KYC and AML for the regulated wallet in the regulated platform 27] can be returned to the linkage module 42 to ensure a closing of the enquiry. If there is a sufficient number of OSINT-retumed identifying data sources that match precisely with corresponding prestored document types and document content 36 entries, then this in itself can justify linking of the regulated wallet to the unregulated wallet.

[0098] The number or type of matches needed can be selected to reflect the level of trust, termed an “honesty score”, deemed necessary to establish wallet linkages. Setting the threshold at a relatively high number of positive matches means that greater axioposity is established for the personal credentials of the KYC-approved owner of the regulated wallet as correlating with those of the user of the unregulated wallet. Different categories of document may attract different weighting to the cumulative score, i.e., a driving licence may be allocated a score of twenty whilst an email address may attract a value of one unit. The cumulative threshold can therefore be achieved in a differing number of ways, and the threshold set at differing levels to reflect perceived overall risk of the owner of the regulated and unregulated wallets being the same individual. TIN-P10955WO1: 2 December 2025

[0099] -23-

[0100] The system intelligence is configured to record the determination of such common ownership in both the private ledger database 26 and the public ledger database 66 with recording of appropriate cross-lining addresses 40, 76 stored in the respective wallets.

[0101] Alternatively or complementarily, returned identifying data sources for which there is no corresponding pre-stored and pre-certificated data, as established by the linkage module 42 interrogating the private ledger database (or associated database in which the KYC data 36 is stored), can be used as a direct challenge 124 to the user 18 logged into to the regulated wallet via the app 22.

[0102] More particularly, the linkage module 44 creates one or more challenges 122 (based on the scraped identifying data sources) that require a confirmatory response through the app 22 during logged-on activity. For example, if the returned identifying data sources return an employment history, system intelligence (based for example on natural language processing “NLP” term extraction in an Al environment) may pose a question concerning employment dates with a particular company. Alternatively, if the returned identifying data sources is a telephone number, the query could require the insertion of deliberately obscured digits. Similar challenge queries can be formulated, as will be appreciated, for transactions involving NFTs, cryptocurrency transaction histories and smart interactions and events stored in the ledger of the unregulated wallet, addresses of other unregulated wallets, user-related geographic locations, images / pictures and particularly tags for locations or individuals present, email addresses, public government data and company affiliations, etc. If the linkage module receives a response 124 via the app 22 and the response to the query is correct and, preferably, delivered within a time window set for response, then this represent new identity verification data that is another step towards legitimizing user of the unregulated wallet as being the same individual who is the owner of the regulated wallet. The app 22 can return the response directly for the linkage module to assess, or otherwise it may return a match / no-match result based on local comparison of the response relative to the expected response supplied to the app as part of the query generation function at the linkage module. TIN-P10955WO1: 2 December 2025

[0103] -24-

[0104] If the response to the query through the app is false (or timed out), then the system intelligence concludes either that the respondent user 18 cannot be trusted to the extent that a link between the registered and unregistered accounts cannot be justified, or otherwise that at least one further challenge based on returned identifying data sources must be made and correctly answered. In the event that the user 18 correctly responses through the app 22, then the linkage module can either (i) raise further queries to increase confidence in the identity of the respondent user 18, or (ii) accept that a sufficient level of trust has been associated that warrants linkage of the regulated and unregulated wallets. Linking of wallets follows the procedure described above.

[0105] Any correct reply to the query is stored in a database, such as but not limited to the private ledger database 26, with the reply cross-referenced to the document type. In this way, an appreciation of the user’s activities is grown and the fields of document type and document content 36 and related certificates expanded with time.

[0106] The linkage module 42, in response to a valid answer to a query, is thus further preferably arranged to send 130 the certificate module 46 (within the regulated platform) data relating to the nature of the query (e.g., document type) and the accurate user-supplied response. The certificate module 46 generates a new coded hash for the specific content and identified nature of the identifying data source query and its correct response, and links 132 this certificate to the relevant regulated private wallet address 34.

[0107] The certificate module 46 can now cross-reference and mint the certificate [relating to the returned data from the OSINT module] into at least one of:

[0108] (i) the private ledger database and, typically, in a look-up table or the like (flow 134 of FIG. 2). Assumingly that the requisite honesty score is met, then use of the unregulated wallet in the regulated environment will be enabled. The certificate would be a non-transferable NFT ;

[0109] (ii) the public ledger database (flows 133 and 135 of FIG. 2) for the relevant unregulated wallet. This would increase direct public visibility of information / data related to the owner of the unregulated wallet, and TIN-P10955WO1: 2 December 2025

[0110] -25- confirms that the certificate has been validated in a regulated environment, thereby increasing levels of trust in public data. The certificate would be a non-transferable NFT ;

[0111] (iii) minting duplicates of the certificate(s) generated for the KYC / AML process(es) [needed to validate the authenticity of the user and establish the regulated wallet] into the linked unregulated public wallet, with these certificates again presented as non-transferable NFTs; and / or

[0112] (iv) both the private ledger database and the public ledger database for the reasons explained immediately above.

[0113] C) LINKAGE VIA A HARD WALLET

[0114] According to an alternative linking embodiment, the initial linking of private and public wallets on respectively regulated and unregulated platforms can be achieved using the following approach. The private cryptocurrency wallet is established by processes which satisfy KYC and AML requirements; these are known and outlined above. The verified user of the private wallet instantiates the app 22 and logs-in via the interface (reference numeral 16 of FIG. 1) and identifies, for example, an Ethereum address. Should the verified user 18 of the private wallet then contemporaneously engage a hard wallet device containing a private key for an unregistered public cryptocurrency wallet, the reported contemporaneous logins establish, via message handshaking (e.g., through interactions with the app 22), that there is a commonly known user and that the wallets can be linked / associated as described above. Particularly, the respective private ledger database and public ledger database appropriate are uploaded with cross-references to the respective wallets. The same principle may be applied to a browser-based software wallet.

[0115] As in intermediate summary of linking techniques which can link wallets respectively established on regulated and unregulated platforms of a blockchain environment, the trading system comprises a blockchain system having a public certificate module arranged selectively to write NFTs, received by the blockchain system, into specific unregulated accounts of the unregulated trading system. The unregulated system, as indicated above, is configured to be impervious to being broken down to (i) identify ownership of individual TIN-P10955WO1: 2 December 2025

[0116] -26- wallets stored on the public ledger, or (ii) identify a chain of custody of any item stored in its respective wallet. A public ledger database is coupled to the block chain system and is responsive to the public certificate module. The public ledger database contains a plurality of unregulated accounts each having at least a public wallet address for a user account and wherein at least some of the public wallet addresses further have stored therewith: (i) a document type identifier with a related minted unique non-transferable NFT linked to an externally generated certificate hash and where each non-transferable NFT is obtained via writing of a smart contract and each non-transferable NFT is a permanent record for a description of the document type; and (ii) a link to a private wallet of a regulated account of a regulated trading platform, the link related directly to the minted non-transferable NFT issued from the certificate module. Each non-transferable NFT is configured to be changed or moved from the unregulated wallet only through an interaction that directly involves the certificate module. Furthermore, system intelligence is arranged to cause, at a point of linking the unregulated wallet with a user-authenticated regulated wallet, any non-transferable NFTs in the regulated wallet to be identically replicated by the certificate module and minted into the unregulated wallet. After linking of the unregulated wallet with a user-authenticated regulated wallet, the system intelligence is arranged to cause any later issued non-transferable NFTs in the regulated wallet to be identically replicated by the certificate module and minted into the unregulated wallet.

[0117] The preferred embodiments of the present invention may make use of the wallet linking approach summarised (particularly but not exclusively in the immediately preceding summarizing paragraph), but it is not necessary. The preferred embodiments, subsequently described under the sub-title “AML STABLE COINS,” can be implemented independently as a standalone AML solution.

[0118] D) AML STABLE COINS

[0119] Referring now to FIGs. 3 and 4. FIG. 3 shows is a schematic representation of a blockchain environment 200, connected around and through a WAN 12, whereas FIG. 4 is an entity interaction diagram showing preferred messaging interactions and content delivery TIN-P10955WO1: 2 December 2025

[0120] -27- between the system entities / components of FIG. 3. The system entities / components of FIG. 3 are server-based.

[0121] Typically, but not exclusively, the system components / entities include a variety of management servers (and the like) belonging to different and independent operational organisations, such as a minting authority 202, a token sender 204, a certificate issuer 206 and numerous potentially direct and indirect recipients. FIG. 4 shows messaging interactions arising between these system component / entities in accordance with a preferred embodiment of the present invention.

[0122] To set up the AML stable coin, a first order recipient 207 must first obtain a “status” certificate as a hash (interchangeably called a “status NFT”) that establishes their credentials. The request for a status certificate may be independently requested by the recipient, e.g., through local data entry, or otherwise it may be automated by a prompt delivered to the recipient (either an end user or server intelligence) by the server or the token sender. These credentials relate to at least the nature of their business, e.g., a registered charity or a small / medium enterprise “SME”, and / or associated characteristics of the recipient company or individual in terms of commercial activities or stated objectives, e.g., a company that provides (as the commercial and typically registered activity) shelter to the homeless and (as the stated objective(s)) the provision of the commercial activity by operating as a carbon neutral society. As a second example, this could be an individual supplying water purification equipment and services. As a third example, this could be a brewery providing IPAs brewed from organic hops sourced within a thirty-mile local radius. As a fourth example, this could be the supply of medical services by Medecins Sans Frontieres. The foregoing examples are non-limiting and merely reflective of some established characteristics. The status certificate hash therefore defines at least one characteristic of or collectively the “properties” of a recipient, and thus the accessibility of that recipient in terms of particular usage of a cryptotoken and, to a complementary extent, the trustworthiness of the recipient from an AML perspective. The resulting picture of established activity by the, at this point prospective, recipient company TIN-P10955WO1: 2 December 2025

[0123] -28- is issued onto the blockchain in the form of one or more accessible or otherwise linked certificate hashes (i.e., NFTs). TIN-P10955WO1: 2 December 2025

[0124] -29-

[0125] Table 1: Exemplary Status Certificate Properties Aligned with Conditional Smart Contract Requirements

[0126] The issuing of this status certificate (such as an NFT), by the certificate issuer 206, can be in response to a specific request (reference numeral 302 of FIG. 4) from the recipient 207 or could be pushed independently by an approved certificate issuing authority 206 should the issuing authority have an acquired understanding or record of the established activities of the recipient 207. For example, the issuing authority 206 may mint certificates in response to AME / KYC clearance checks being performed and passed at a minting authority 202. The status certificate hash is preferably issued via the request route.

[0127] The request for a status certificate, typically but not exclusively in the form of an NFT, may be sent to the issuing authority directly or to the minting authority 202 which relays the request to the issuing authority 206. One of these server-based entities, most typically and preferably the minting authority 202, includes an automated function supported by processing intelligence, akin to that described previously, arranged to undertake a checking process 303 that seeks to validate the nature and operational characteristics or stated objectives of the first order recipient 207. Once a level of confidence has been passed in relation to the information returned 304 by that checking process, the [exemplary] minting authority is functionally tasked to invoke minting 308a, 308b of the status certificate 310 and then to cause its supply or linking to the relevant commercial entity and blockchain, i.e., the corresponding recipient will receive into its wallet and / or otherwise be permanently associated with the status certificate stored on blockchain and thus accessible for inspection by the distributed system intelligence “DIS” 210 of the blockchain environment 200. For the sake of clarity a single nominal schematic layering of the system intelligence function is shown to represent system-wide distribution.

[0128] The certificate issuing authority 206 may be a financial institution like a commercial bank or some other approved / regulated entity operating within the domain of the intemet / web 3.0, etc. TIN-P10955WO1: 2 December 2025

[0129] -30-

[0130] The term “first order” is used to differentiate direct recipients from one or more arm’s length recipients 208 who fall hierarchically beneath the first order recipient 207 in the sense that fungible tokens or non-fungible tokens can potentially be passed from the first order recipient 207 to one or more arm’s length recipients without oversight by the original token sender 204.

[0131] The status certificate (or multiple but linked certificates that each contribute an integral part to the company identify and company activity) has two general properties: i) It validates, i.e., in the sense that it confirms and authenticates, the identity of the recipient 106. This can be achieved, if the recipient is operating from an unregulated account, using the processes above described for wallet linking or by other established KYC procedures. ii) It identifies specific historically verifiable activity and / or confirmed established operating characteristics directly linked to a registered crypto wallet and thus implicitly to the recipient 207.

[0132] With the status certificated placed on the blockchain, the validated nature and confirmed operational characteristics or stated objectives of the first order recipient 207 are available for untamperable inspection by the distributed system intelligence 210 of the blockchain system 200.

[0133] The status certificate thus is configured to contain a unique code which refers to the certificate type, e.g., a charity could contain the code 0x34e23e.

[0134] A part of a stable coin AML process is, at this point, partially established within the blockchain.

[0135] Considering now the objective for a token sender 204 to send cryptocurrency or an NFT or other fungible token “FT” representing a service or something of value to a first order recipient. For example, for the sake of explanation only, the token sender 204 could be a government agency wishing to send money for humanitarian aid to a charity, such as TIN-P10955WO1: 2 December 2025

[0136] -31-

[0137] Oxfam®. For reasons of explanation only, the token sender 204 may wish to have minted and then to send one thousand cryptotokens having a nominal value of US$10M. The instruction for the minting is typically triggered by user entry at a user interface of the token sender, whereafter the process is automated by the system intelligence.

[0138] The issue, for the token sender 204, is that any sent token must be robustly secured and protected by the blockchain environment from misuse or inappropriate use.

[0139] Providing a context, the government agency would not want any token to be redeemed for fiat currency for reasons of buying weapons when the token was supplied / sent for the specific purchase of food by an extra-territorial charity at a local national market. In present cryptosystems, there is no ability to prevent this form of money laundering or misuse activity for any sent token since there is no final audit trail (especially into unregulated wallets on unregulated platforms) that provides checks and balances for when, how or by whom the real-world value of the cryptotoken was received. The problem of accountability and effective audit is compounded when the cryptrotoken is moved onwards 212 from the initial first order recipient 207 to any arm’s length recipient [as viewed from the perspective of the original token sender 204]. The first order recipient may be legitimate with respect to its intended uses of the received cryptotoken but may need to distribute some of the received cryptotokens to its own direct supplier, i.e., one or more arm’s length recipients 208. At this point, there is no present control by the original token sender, i.e., the government agency, over the use and realisation of cryptotoken’s real-world redeemable value by any arm’s length recipients 208.

[0140] The system intelligence may be arranged to generate an alert to the token sender and / or other blockchain entity, such as the certificate issuer or other administrative regulator, should a transfer fail because the identified conditions of defined use are determined not sufficiently met by the cryptowallet of the recipient. The alert, which is typically in the form of a message, can optionally be used (e.g., communicated) to the recipient to force the recipient to seek an updated status certificate that is consistent with the smart contract TIN-P10955WO1: 2 December 2025

[0141] -32- conditions embedded with the minted cryptotoken. Such a message may be automatically sent by the token sender’ s administrative server.

[0142] Returning to the interaction process shown in FIG. 4, the token sender 204 makes an online request 312 to the minting authority 202 for the minting of, say, one thousand smart contract cryptotokens having a nominal value of US$10M. The exact ratio of tokens to nominal value can be any approved ratio, including more typically one-to-one especially for fiat currency. In this request, the token sender 204 stipulates (via an app) conditions that must be satisfied by any recipient (whether direct or at arm’s length), i.e., the token sender 204 identifies core characteristics of the recipient. The stipulated conditions do not need to identify a recipient by name although this is an option, with any identified name in the status certificate narrowing the cryptotoken’ s use to organizations sharing a common root name. At the same time as making the request to the minting authority for the one thousand smart contract cryptotokens, the token sending electronically authorises and sends payment for the one thousand smart contract cryptotokens. Upon cleared receipt of this payment, the minting authority 202 mints the one thousand smart contract cryptotokens 314 (typically but not exclusively in the form of “conditional” fungible tokens 316 or the like) and returns these conditional FTs, i.e., makes them available for use, to the token sender 204. The cleared funds (or access to other tangible property) are stored and pegged 318 in a reserve account (reference numeral 220 of FIG.3) that is controlled by the minting authority.

[0143] For fiat currency, the received funds are in essence held in escrow and subject to release by the minting authority upon valid presentation of a subsequent request.

[0144] The smart contract can be created using any suitably implemented convention operable on any smart contract capable blockchain system.

[0145] Whilst the minting authority controls the insertion of the smart contract to reflect conditions under which the minted coin (interchangeably referred to “conditional” certificate, fungible token or NFT) can be used, the entirety of the system typically and TIN-P10955WO1: 2 December 2025

[0146] -33- generally (but not exclusively) calls for a degree of collaboration with a certificate issuer [responsible for authorization of a recipient] and / or the entity responsible for requesting the minting of the coin in exchange for appropriate value placed in escrow in a reserve account pegged to the minted coin.

[0147] The token sender 204 instructs sending 320 of conditional FTs to an identified recipient 207, thereby notifying the blockchain environment of the proposed transfer. The instruction may be for all or just some of the minted conditional FTs.

[0148] The system intelligence of the blockchain invokes an interrogation function 322 that looks to identify 324 the presence of a status certificate within the wallet of the proposed recipient. If a status certificate is determined to be present, the system intelligence determines 326 whether the recipient’s status certificate appropriately correlates to the conditions set by the smart contract of the conditional FTs. Correlation may be established if one condition is satisfied, although multiple or all smart contract conditions may be required to be satisfied by encoded, non-corruptible data in the status certificate. If there is determined partial (in the sense that other deemed critical conditions are satisfied that ensure consistency with the objectives of the smart contract) or complete correlation 328, the transfer of the minted FTs is authorised 330, i.e., the corresponding conditional FTs stored in the token sender’ s wallet can be deducted, to the proposed recipient’s wallet (now an “authorised recipient) and the transaction permanently coded into an updated blockchain record 332. Once authorised, the recipient wallet has full ownership, control and access to the received conditional FT. The system intelligence updates the blockchain record - including any appropriate to system entities - to reflect to change of custodian and use provision by the recipient of the conditional FT.

[0149] Artificial Intelligence “Al” sub-systems within the distributed system intelligence may be used to interpret the consistency between the smart contract conditions and the status certificate and, particularly, whether the properties of the status certificate pass a threshold confidence level sufficient to justify cryptotoken transfer. The granularity for definitions of business nature may vary and interpretation by Al may be employed to resolve whether TIN-P10955WO1: 2 December 2025

[0150] -34- the criterion has been sufficiently met. The evaluation may take into account other criteria in the status certificate that influence the decision.

[0151] Conversely, if it is determined that there is either (a) no status certificate in the proposed recipient wallet or (b) that the smart contract conditions in the conditional FT are not met by the data permanently coded into in the status certificate associated with the proposed recipient, the system intelligence denies 340 the transfer of FTs from the token sender 204 and accordingly notifies at least one the token sender and preferably but optionally also the minting authority. The blockchain record can, at this point, also be optionally updated to reflect the temporally denied transfer, but this is simply a design option of the particular blockchain environment. The wallet may therefore also be flagged with a warning concerning relating to the status of the owner and / or the nature of the wallet account, e.g., unsafe for reasons on non-validated account ownership.

[0152] The status certificate can be minted as a non-transferable NFT as described in relation to FIGs. 1 and 2. This non-transferable NFT is sent to the nominal wallet address “123” (irrespective of whether this, say, “123” address is registered or unregistered), and is inherently linked to the token sender’s regulated wallet. The non-transferable nature of the NFT pre- validates the transfer of conditional FTs because the registered wallet of the token sender already correlates with the properties and location of the non-transferable NFT.

[0153] As a further alternative for AML control, at the point when the token sender requests the minting of conditional FTs or conditional NFTs, etc., the token sender may further stipulate one or more wallet addresses of known suitable recipients. The initial transfer of control of the conditional FT can then take place to an identified wallet address, say, “123” since wallet address 123 satisfies the conditional terms for the nature of its activity its stated attributes and / or approved commercial characteristic. The onward transfer of the conditional FT to wallet address, say, “789” could also be initially called by the system, but the system intelligence is arranged to identify that there is a mismatch in identities between the 789 wallet address and the authorised wallet address 123, thereby denying the transfer call. TIN-P10955WO1: 2 December 2025

[0154] -35-

[0155] For a successfully correlated status certificate, the transferred conditional FT (or the like) is now usable by the [immediate] recipient, thereby allowing recipient to have control over the conditional FT and redeem its value or linked asset or service upon contacting the minting authority and making a release request 342. Successful correlation between the certificate status and the conditional FT, i.e. the resulting AML stable coin, therefore prevents inappropriate use of related real assets by denying any non-approved recipient access to or control over conditional FTs.

[0156] Since the approved recipient in receipt of conditional FTs is now in an analogous position to the original token sender who ordered the minting to the conditional FTs, the recipient can transfer conditional FTs provided that the next recipient also has a status certificate determined by the system intelligence to correlate precisely with the smart contract conditionals originally set at the point of minting the conditional FT. In other words, if the smart contract set a condition that the recipient must be a charity, the original recipient charity of conditional FTs would be prevented from sending the conditional FTs onto any wallet other than one containing a status certificate containing the charity code, e.g., 0x34e23e. Expressly this in more technical terms, the transfer function of FIG. 4 is implemented only to allow transfers to wallets which contain certificates which contain the code matching either subject only to any inclusive or alternative Boolean operators for codes defined at the point of minting.

[0157] Unless specific arrangements are mutually exclusive with one another, the various embodiments described herein can be combined to enhance system functionality and / or to produce complementary functions or system that support the effective identification of user-perceivable similarities and dissimilarities. Such combinations will be readily appreciated by the skilled addressee given the totality of the foregoing description. Likewise, aspects of the preferred embodiments may be implemented in standalone arrangements where more limited functional arrangements are appropriate. Indeed, it will be understood that unless features in the particular preferred embodiments are expressly identified as incompatible with one another or the surrounding context implies that they TIN-P10955WO1: 2 December 2025

[0158] -36- are mutually exclusive and not readily combinable in a complementary and / or supportive sense, the totality of this disclosure contemplates and envisions that specific features of those complementary embodiments can be selectively combined to provide one or more comprehensive, but slightly different, technical solutions. In terms of the suggested process flows of the accompanying drawings, it may be that these can be varied in terms of the precise points of execution for steps within the process so long as the overall effect or re-ordering achieves the same objective end results or important intermediate results that allow advancement to the next logical step. The flow processes are therefore logical in nature rather than absolute. The functional architectures of, for example, FIGs. 1 and 3 may be implemented independently on one another, as will be understood, since the wallet linking and AML stable coin processes, whilst complementary, relate to different events which are not necessary coterminous. Further, in terms of the system’s distributed functions and, particularly, the system intelligence used to implement the various interactive messaging protocols, data calls and queries, these can be located one or multiple servers within, usually, the regulated platform. The private server / server functions block of FIG. 1 should, consequently, be viewed functionally as a block to typical operational functions. In this regard, labels such as “linkage module” and “certificate module” should be understood to be descriptive tags for the specific functionality and related interactions.

[0159] It will, of course, be appreciated that the above description has been given by way of example only and that modifications in detail may be made within the scope of the present invention. For example, whilst the described embodiments have focused on digital accounts that, generally, will contain or support transactions using cryptocurrencies, the concepts and approaches to linking and identity verification, especially using a scraped deeper-dive approach to different data sources, applies in general to linking of regulated with unregulated accounts of any nature. Similarly, the concepts of establishing a restricted stable coin that prevents money laundering, as outlined in relation to FIG. 3 and 4, can be applied more generally to any blockchain system in which coins are exchanged either for fiat currency or something different, such as an item or a service. TIN-P10955WO1: 2 December 2025

[0160] -37-

[0161] From an implementation perspective of a smart contract standard, it would be preferable for the standard to include: i) a smart contract address which refers to the certificate issuance contract of the certificate issuer 206 responsible for issuing the status certificate; ii) at the point of minting the cryptotoken, appending a list of current codes relating to the status certificates.; and iii) ‘AND / OR’ Boolean operators to reflect whether all certificates are required, or only one of the list is required for correlation purposes (discussed in more detail above).

[0162] The set-up of the smart contract outlined in general immediately above would potentially require a new instantiation of the smart contract for each minting of new cryptotokens. Alternatively, a single instantiation of the smart contract can be created in which relevant status certificates for the minted cryptotokens are stored within a data structure, such as a hash map. The hash map therefore defines recipients for different token senders. This is again dependent upon the implementing capabilities inherent within a particular blockchain environment.

[0163] The nature of change to any smart contract standard is, of course, a design option and subject to functional choice and does not affect the fundamentals in the technical qualities of the AML stable coin of the preferred embodiments, neither does it affect the underlying technical assessment process by which transfers may be authorised.

[0164] The stipulation of identified recipient in the conditional smart contract of the preferred embodiment is optional. Similarly, the extent of the conditional terms defined in the smart contract embedded in the blockchain and inseparably linked to the minted cryptotoken may be one or a combination of two or more of (i) the operational business nature of a desired recipient of the cryptotoken, (ii) commercial activities of the desired recipient of the cryptotoken, and (iii) operating objectives of the desired recipient of the cryptotoken and (iv) other relevant criteria.

Claims

TIN-P10955WO1: 2 December 2025-38-CLAIMS1. A method restricting at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service, the method comprising: providing a status certificate issued as a hash to a first wallet registered on a platform of a blockchain system containing distributed system intelligence, wherein the first wallet has an owner, the status certificate is issued by an accredited certificate issuer active on the blockchain system and the status certificate has certificate properties arranged to reflect at least one of: an authenticated operational business nature of the owner; authenticated commercial activities of the owner; and authenticated stated operating objectives of the owner; from a token sender, making a request to a minting authority on the blockchain system to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to at least one of: an operational business nature of a desired recipient of the cryptotoken; commercial activities of the desired recipient of the cryptotoken; operating objectives of the desired recipient of the crypto token; and an identified recipient for the cryptotoken; at the minting authority, minting to the token sender the requested cryptotoken and embedding a smart contract on the blockchain system for the cryptotoken that corresponds to the identified conditions of defined use of the cryptotoken; from a token sender, attempting to transfer the cryptotoken to an addressed wallet for use thereby; and using the distributed system intelligence to determine that the addressed wallet is the first wallet and has at least one of (a) a link to the identified recipient, and (b) a relevant status certificate for the first wallet and which relevant status certificate has at least one certificate property determined to be substantially consistent with the identified conditions of defined use of the cryptotoken as expressed in the smart contract; and using the distributed system intelligence to allow transfer, from the token sender, and use of the cryptotoken in and by the addressed wallet only when the addressed walletTIN-P10955WO1: 2 December 2025-39- is determined, by the distributed system intelligence, to at least contain one of (a) the link to the identified recipient and (b) the relevant status certificate.

2. The method of claim 1 , wherein the transfer is allowed when only the relevant status certificate is determined to exist in the addressed wallet.

3. The method of claim 1 or 2, wherein all the conditions of the smart contract must be met for transfer of the cryptotoken to occur.

4. The method of claim 1, 2 or 3, wherein the first wallet satisfies one of the conditions that it is on: i) a regulated trading platform and an identity of the owner is known; ii) an unregulated trading platform and the owner is unknown to the token sender; and iii) an unregulated trading platform and the owner is linked to a second wallet held of a regulated platform.

5. The method of any preceding claim, wherein the cryptotoken is one of a fungible token “FT”; and a non-fungible token “NFT”.

6. The method of any preceding claim, wherein the cryptotoken is a stable coin pegged by the minting authority to the tangible asset.

7. The method of claim 6, wherein the tangible asset is fiat currency.

8. The method of any preceding claim, wherein identified recipient is a wallet address.

9. The method of any preceding claim, further comprising:TIN-P10955WO1: 2 December 2025-40- subsequent to transfer of the cryptotoken to the addressed wallet, restricting at least one of transfer, use and redemption of the cryptotoken to or by a different wallet distinct to the addressed wallet.

10. The method of any of claims 1 to 8, further comprising: subsequent to transfer of the cryptotoken to the addressed wallet, permitting at least one of transfer, use and redemption of the cryptotoken to or by a different wallet distinct to the addressed wallet when the system intelligence determines that the different wallet contains a second relevant status certificate having at least one certificate property determined to be substantially consistent with the identified conditions of defined use expressed in the smart contract.

11. The method of claim 9, further comprising: generating an audit trail on the blockchain for each failed transfer of the cryptotoken following determined absence of the relevant status certificate in the addressed wallet.

12. The method of claim 11, further comprising generating an alert message for each failed transfer and communicating said alert message sent to at least one of: the token sender; the minting authority; the addressed wallet; and the certificate issuer.

13. A method restricting at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service, the method comprising: providing a status certificate issued as a hash to a first wallet registered on a platform of a blockchain system containing distributed system intelligence, wherein the first wallet has an owner, the status certificate is issued by an accredited certificate issuer active on the blockchain system and the status certificate has certificate properties that authenticate historical operating characteristics directly linked to the first wallet;TIN-P10955WO1: 2 December 2025-41- from a token sender, making a request to a minting authority on the blockchain system to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to identified operating characteristics for a recipient wallet; at the minting authority, minting to the token sender the requested cryptotoken and embedding a smart contract on the blockchain system for the cryptotoken that corresponds to the identified conditions of defined use of the cryptotoken; from a token sender, attempting to transfer the cryptotoken to an addressed wallet for use thereby; using the distributed system intelligence to determine that the addressed wallet has a relevant status certificate consistent with the identified conditions expressed in the smart contract; and using the distributed system intelligence to allow transfer, from the token sender, and use of the cryptotoken in and by the addressed wallet only when the relevant status certificate is determined to be present.

14. A blockchain system having server-based entities interconnected over a network, the server-based entities including at least: distributed system intelligence; a token sender; a minting authority; a certificate issuer; and a plurality of wallets registered within the blockchain system; wherein: the distributed intelligence is arranged to restrict at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service; the certificate issuer is arranged to issue, as a hash, a status certificate to a first wallet of the plurality of wallets and the status certificate has certificate properties arranged to reflect at least one of: (i) an authenticated operational business nature of an owner of the first wallet; (ii) authenticated commercial activities of the owner; and (iii) authenticated stated operating objectives of the owner;TIN-P10955WO1: 2 December 2025-42- the token sender is arranged to make a request to the minting authority to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to at least one of: (i) an operational business nature of a desired recipient of the cryptotoken; (ii) commercial activities of the desired recipient of the crypto token; (iii) operating objectives of the desired recipient of the crypto token; and (iv) an identified recipient for the cryptotoken; the minting authority is arranged to mint to the token sender the requested cryptotoken and further to embed a smart contract on the blockchain system for the cryptotoken that corresponds to the identified conditions of defined use of the crypto token; the token sender is arranged to attempt transfer the minted cryptotoken to an addressed wallet for use thereby, the addressed wallet being one of the first wallet and a different independent wallet of the plurality of wallets; and the distributed system intelligence is arranged to: determine that the addressed wallet is the first wallet and has at least one of (a) a link to the addressed wallet, and (b) a relevant status certificate for the first wallet and which relevant status certificate has at least one certificate property determined to be substantially consistent with the identified conditions of defined use of the cryptotoken as expressed in the smart contract; and authorise the token sender to transfer the cryptotoken to the addressed wallet, thereby to allow use of the cryptotoken in and by the addressed wallet only when the addressed wallet is determined, by the distributed system intelligence, to at least contain one of (a) the link to the identified recipient and (b) the relevant status certificate.

15. The blockchain system in accordance with claim 14, wherein the distributed system intelligence is arranged to transfer the cryptotoken only when the relevant status certificate is determined to exist in the addressed wallet.TIN-P10955WO1: 2 December 2025-43-16. The blockchain system in accordance with claim 14 or 15, wherein all the conditions of the smart contract must be determined to be met before the distributed system intelligence authorises transfer of the cryptotoken to the addressed wallet.

17. The blockchain system in accordance with claim 14, 16 or 16, wherein the cryptotoken is one of a fungible token “FT”; and a non-fungible token “NFT”.

18. The blockchain system in accordance with claim 14, 15 or 16, wherein the cryptotoken is a stable coin pegged by the minting authority to a tangible asset held in a reserve account.

19. The blockchain system in accordance with any of claims 14 to 18, wherein the tangible asset is fiat currency.

20. The blockchain system in accordance with any of claims 14 to 19, wherein identified recipient is a wallet address.

21. The blockchain system in accordance with any of claims 14 to 20, wherein the distributed system intelligence is further arranged, subsequent to transfer of the cryptotoken to the addressed wallet, to restrict at least one of transfer, use and redemption of the crypto token to or by a different wallet distinct to the addressed wallet.

22. The blockchain system in accordance with any of claims 14 to 21, wherein the distributed system intelligence is further arranged, subsequent to transfer of the cryptotoken to the addressed wallet, to permit at least one of transfer, use and redemption of the cryptotoken to or by a different wallet distinct to the addressed wallet when the system intelligence determines that the different wallet contains a second relevant status certificate having at least one certificate property determined to be substantially consistent with the identified conditions of defined use expressed in the smart contract.TIN-P10955WO1: 2 December 2025-44-23. The blockchain system in accordance with claim 21, wherein the distributed system intelligence is arranged to generate an audit trail on the blockchain for each failed transfer of the cryptotoken following determined absence of the relevant status certificate in the addressed wallet.

24. The blockchain system in accordance with claim 21, wherein the distributed system intelligence is arranged to generate an alert message for each failed transfer and communicating said alert message sent to at least one of: the token sender; the minting authority; the addressed wallet; and the certificate issuer.

25. A blockchain system having server-based entities interconnected over a network, the server-based entities including at least: distributed system intelligence; a token sender; a minting authority; a certificate issuer; and a plurality of wallets registered within the blockchain system; wherein: the distributed intelligence is arranged to restrict at least one of use and redemption of a cryptotoken representative of a tangible asset or deliverable service; the certificate issuer is arranged to issue, as a hash, a status certificate to a first wallet of the plurality of wallets and the status certificate having certificate properties authenticating historical operating characteristics directly linked to the first wallet; the token sender is arranged to make a request to the minting authority to mint a cryptotoken, wherein the request includes identified conditions of defined use of the cryptotoken relating to identified operating characteristics for a recipient wallet; the minting authority is arranged to mint to the token sender the requested cryptotoken and further to embed a smart contract on the blockchain system for theTIN-P10955WO1: 2 December 2025-45- cryptotoken that corresponds to the identified conditions of defined use of the crypto token; the token sender is arranged to attempt transfer the minted cryptotoken to an addressed wallet for use thereby, the addressed wallet being one of the first wallet and a different independent wallet of the plurality of wallets; and the distributed system intelligence is arranged to: determine that the addressed wallet is the first wallet and has relevant status certificate consistent with the identified conditions expressed in the smart contract; and authorise the token sender to transfer the cryptotoken to the addressed wallet, thereby to allow use of the cryptotoken in and by the addressed wallet only when the addressed wallet is determined, by the distributed system intelligence, to include the relevant status certificate.

Images