
WHITE PAPER
TRANSCEND
NODE
Powered by Cuvex

WHITE PAPER
TRANSCEND
NODE
Powered by Cuvex
ABSTRACT
The purpose of this document is to provide an initial overview of Transcend Node (TND) and its related technologies, including blockchain, encryption, distributed storage, and smart contracts for the decentralized management of crypto asset inheritances or digital secrets. To keep this document concise and easily readable, we primarily focus on the unique and defining features of the TND platform that are essential to achieving its stated objectives.
This document is not intended to serve as the definitive reference for all implementation details.
Some aspects may evolve throughout the development and testing phases.
CUVEX
Only if you have complete offline control over your seed phrase can you truly be the sovereign owner of your crypto assets.
Building on this principle, as our first step, we developed the Cuvex system:
Possibly the most secure solution available today for creating and managing BTC wallets, as well as backing up and recovering seed phrases, the Cuvex system consists of the Cuvex hardware device along with the Cuvex smartphone and desktop apps.
The Cuvex system provides comprehensive support so that anyone regardless of their knowledge or skill level can:
1
Create and manage a seed phrase recovery process by generating cryptograms for backups and storing them on NFC cards.
2
Create a fully offline BTC wallet, incorporating physical and manual processes into the seed phrase entropy using the “Dice and Coin” standard.
3
Manage that wallet with “Coin Control” privacy features, maximizing privacy by design.
4
Sign transactions using a dual AirGap PSBT approach, ensuring the physical separation of the offline components required to move funds.
TRANSCEND
In our initial phase, we’ve helped our clients regardless of their technical expertise overcome the industry’s biggest challenges by delivering robust solutions built on zero-knowledge privacy policies, ensuring total independence from our systems at all times, and developing cryptographic technology focused on human freedom, privacy, and security.
Now, we’re taking the next step: adding value to that final milestone we all face passing on the value of our crypto assets to our loved ones when
we can no longer enjoy them ourselves.
For a process like this sovereignly automating crypto asset inheritance our proposal guarantees the following values:
1
No centralized entity can be involved in this process. It must be fully decentralized, relying on the guarantees of an anti-coercive network that can perpetually function without any centralized control certainly not ours.
2
Crypto assets must not be locked within smart contracts; they must remain fully accessible to the issuer of the inheritance until they can no longer maintain control.
3
To ensure these requirements, everything must be built so that its three pillars Privacy, Security, and Decentralization are irrevocable by design, creating a user experience that does not demand extensive technical expertise to complete the process.
TRANSCEND
Decentralized Crypto Asset Inheritance
Introduction
The Transcend network will be supported by community members who choose to deploy their own Transcend blockchain nodes.
These nodes are responsible for managing, controlling, securing, and ensuring the efficiency of the TND token’s blockchain.
On this original, independent chain, issuers of inheritances will store encrypted secrets, which will only be released to recipients if the issuer fails to meet a self-imposed life-latency challenge.
Node operators must hold a specific amount of TND tokens as a stake to participate in the network. In doing so, they provide distributed protection of these secrets, validate transaction blocks, maintain the network’s decentralized structure, and earn fees in Bitcoin for their services.
Any node that fails the decryption availability verification challenge or attempts to include fraudulent operations will be penalized. It may lose its staked tokens, which are then redistributed to the rest of the network’s nodes that remain in good standing.
Conclusions
Transcend is a protocol implemented via smart contracts running on the Transcend Blockchain. These contracts ensure the setup and delivery of a secret that grants heirs designated by the issuer access to a cryptocurrency inheritance once the issuer fails their own defined life-latency challenge.
The Transcend Blockchain is operated by independent nodes that secure its efficiency and safety by staking the TND utility token. Nodes that do not fulfill their duties are penalized, forfeiting their staked TND and being removed from the network.
Nodes receive compensation directly in BTC.

HOW TRANSCEND WORKS
1. Offline multi-signature inheritance secret encryption
2. Creation and deployment of the Transcend Smart Contract on the blockchain
1.
OFFLINE MULTISIGNATURE INHERITANCE SECRET ENCRYPTION

A
Using the Cuvex device, users can generate a BIP39 seed phrase for Bitcoin or any other supported crypto asset. The Cuvex device can also encrypt any seed phrase that wasn’t originally created on it.
Encryption of the seed phrase with AES-256-GCM takes place entirely offline on the Cuvex device, allowing for multi-signature access control over the resulting cryptogram.
For Transcend, the secret to be protected (which must be delivered to the heirs) requires at least 2-of-2 multi-signature access control. This means two passwords are needed to decrypt the secret.
Once the heirs’ wallet seed phrase is created and encrypted, the resulting cryptogram is stored on the memory of an NFC card, referred to in this document as the “Original Card.”
B
The Cuvex device allows you to clone the “Original Card.” The estate issuer must create as many clones as there are heirs; it’s recommended to make at least five clones of the “Original Card” to ensure system redundancy.
These cloned cards are referred to as “Heir Cards.”
Upon completion of this initial step, the issuer has cold-encrypted a seed phrase and its passphrase using AES-256-GCM on a purpose-built device, establishing at least a 2-of-2 multi-signature access requirement.
Once this cryptogram is created, it is written to the memory of multiple NFC cards: the “Original Card” and the “Heir Cards.”
The issuer then physically gives each heir one or more Heir Cards, along with only one of the two passwords needed to decrypt these cards.
The other password required to decrypt the Heir Cards can be retrieved by the heirs from the Transcend platform, once the issuer is no longer able to renew the life-latency challenge.

2.
CREATION AND DEPLOYMENT OF THE TRANSCEND SMART CONTRACT ON THE BLOCKCHAIN
Once the inheritance issuer has encrypted their seed phrase and passphrase onto the Original Card and Heir Cards, they can begin the process of creating and deploying the Transcend Smart Contract on the blockchain. This contract is responsible for protecting one of the two passwords needed to decrypt the Heir Cards. The process involves the following 5 steps:
STEP ONE
The issuer uses the Cuvex smartphone app and requests the creation of a Transcend Smart Contract. At this point, the app instructs the user to disable all external connections (Bluetooth, internet, etc.) and tap the Original Card.
Using all the encrypted binary data on the Original Card, and while operating fully offline, the Cuvex app generates a SHA256 hash as the smart contract identifier that ties it to the inheritance issuer.
The app allows the issuer to designate one of the Heir Cards as an additional Original Card, so that they have a backup for managing their digital inheritance if the Original Card is lost.
Next, the issuer is prompted to tap each of the previously created Heir Cards one by one. For each card, the app repeats the process, but creates two different hashes a BLAKE2 hash and an SHA256 hash based on the encrypted binary data of each Heir Card.
Once this process is complete, the app prompts the user to enter the multi-signature password set during Original Card creation. This is the other password that was not given to the heirs.
The Cuvex app then encrypts this password with AES-256-GCM, using each Heir Card’s BLAKE2 hash as the encryption key, resulting in one cryptogram per Heir Card.
For example, if the issuer taps five Heir Cards, the app will create five AES-256-GCM cryptograms.
When this is finished, the app permanently deletes all read and generated data, storing only the following in the smartphone’s secure element:
-
All cryptograms created for the tapped Heir Cards.
-
All hashes generated, including those of the Original Card (and its backup) as well as the Heir Cards.
STEP TWO
Once the first step is completed, the Cuvex app requests internet activation to connect to a Cuvex block explorer. This connection allows the user to choose the Transcend Node they wish to interact with (if they have one).
Upon connecting to a Transcend block explorer, the app generates a smart contract for the assignment via a lottery mechanism, to designate which nodes will serve as validators for the inheritance identified by the SHA256 hash of the Original Card obtained in the previous step. The insertion of this contract into the blockchain triggers an auditable lottery across the network, which results in the selection of 333 nodes as verifiers and encryptors for the Transcend smart contract identified by the SHA256 hash of the Original Card. Additionally, it establishes which of these nodes will act as the main node (the winning node for the Bitcoin fee paid by the inheritance issuer for registering the contract).
The maximum number of nodes that can serve as verifiers and encryptors is set to 333, as the RSA keys from each node will encrypt each Shamir secret share of the inheritance recovery data. This number of shares ensures the integrity of the encryption to be included in the Blockchain. This detail is further elaborated later in this document.
The process continues by registering the winner as excluded from subsequent lotteries, ensuring that the remaining nodes in the network will participate as main nodes in the next smart contract registration process. This creates an "Hourglass" process where nodes that have already been selected are excluded from future lotteries, allowing all nodes to eventually participate in a contract.
The winning node generates an on-chain BTC address to receive payment, signs it with their private key, and sends it to the smart contract responsible for the lottery.
The smart contract then returns to the app the public RSA keys of the 333 nodes assigned for the encryption of the contract, as well as the on-chain BTC payment address, which will be linked to the Transcend Smart Contract.
For example, if only 200 nodes are active, all of them will be assigned as encryptors and verifiers. These 200 nodes will be notified by the smart contract being generated, and the app will retrieve the 200 public keys from them, along with the on-chain BTC address created by the main node where the payment must be made.
Using this information, the app performs Shamir’s Secret Sharing on each cryptogram stored in the smartphone’s secure element, splitting it into 200 fragments and requiring at least 51% of them for reconstruction.
Once the cryptogram is split, the app calculates an SHA-256 hash for each fragment. It then encrypts each fragment with the assigned node’s public RSA key and stores the following data in a table to be sent to the Transcend Smart Contract:
-
The SHA256 hashes that identify the inheritance issuer
-
The SHA256 hashes that identify the inheritance recipients
-
The hash of the unencrypted Shamir fragment
-
The Shamir fragment encrypted with the node’s public RSA key
-
The on-chain BTC address of the main node that receives payment for contract creation.
This process is repeated for the remaining 199 fragments and for each cryptogram in the phone’s secure element, following the example of 200 nodes.
STEP THREE
Creation of the Transcend Smart Contract and Its Insertion into the Blockchain.
Once all cryptograms have been split using Shamir’s Secret Sharing, their hashes calculated, the fragments encrypted, and linked to the remaining information, the App generates a complete table containing all of this data. It also adds a TND token reception address to that table, which will be used to return the amount originally paid in BTC (in TND tokens) if, for any reason, the contract cannot be validated and inserted. All of this information is then included in the Smart Contract.
The App calculates the transaction size in vBytes and prompts the issuer to set the lifetime latency.
The cost of validating and inserting the Smart Contract into the blockchain depends directly on the transaction size and on the duration specified for this latency. The App will display the cost of the Transcend Smart Contract by checking the latest costs through the explorer, which are set by the Transcend Node DAO.
Participating nodes must demonstrate their ability to decrypt the Shamir-encrypted fragments with their public RSA key every twelve hours. This process ensures the availability and decentralization of the Transcend protocol and is known as the “Encryption Challenge.” Each time nodes successfully complete the challenge, they receive newly issued TND tokens from the managing Smart Contract this is the sole method of issuing new TND tokens after the initial Genesis issuance.
The nodes responsible for encryption must overcome a challenge set by the Smart Contract. If they fail, they will be penalized by the network, losing a portion of their staked TND tokens in accordance with established rules. Any node that fails the challenge the number of times determined by the community will forfeit its staked TND tokens and be expelled from the network.
Tokens lost by a node due to non-compliance are distributed equitably among the other nodes that do not have any active penalties. When these nodes accumulate enough additional tokens to activate a new node, they can allocate their extra TND tokens accordingly and expand their participation in the network.
The issuer must pay the amount set by the network, which is based on the smart contract’s transaction size and the requested lifetime latency. Once this period expires, the issuer can make another payment to renew the Transcend Smart Contract for a new term. Failure to make this renewal payment indicates the issuer’s inability to meet the lifetime latency requirement.
When such a latency failure occurs, the contract switches to a “Shamir Recovery and Decryption” status for the designated heirs, after a security period configured by the issuer at the time of contract creation.
To insert and validate the Transcend Smart Contract broadcast by the Cuvex App, it enters a verification process executed by the assigned node. If the assigned node fails, any of the other nodes designated as verifiers and encrypters can take over by performing the following steps:
1
Verify the structure and contents of the uploaded data table to ensure they comply with the definition generated by the Smart Contract. Specifically, verify the number of Shamir-encrypted fragments, the number of unencrypted fragment hashes, the number of linked RSA keys, and that the data structure and required components are present to allow future decryption by the designated heirs.
2
Verify that the transaction size and lifetime latency align with the current network fee structure and the cost assigned to the contract.
3
Verify that sufficient funds have been deposited into the assigned on-chain BTC address (specified for receiving the contract payment) to cover the cost of the Smart Contract. The network requires waiting for the number of guarantee blocks specified by Transcend before confirming the payment.
After completing the checks above (and any additional checks identified during implementation), the validator node signs the transaction with its private key and inserts it into the Transcend blockchain, appending it to the previous block’s hash. Other nodes verify the signature to confirm that the node in question is indeed the one that won the lottery process. They also verify the contract data to validate the block and add it to their own chains.
The two verifier nodes are responsible for confirming that the validator node performed its job correctly validating and inserting the contract. If the validator node fails, the verifier nodes, following an order set out in the Smart Contract (triggered after a specified period based on BTC blockchain height), will perform the verification task. Either verifier node can validate, sign, and insert the Transcend Smart Contract into the blockchain.
In the event the designated node fails, it will be penalized by losing the amount of TND tokens corresponding to the BTC value it received, which will be transferred to the staking balance of the verifier node that completes the task.
In any case, insertion of the issuer’s Transcend Smart Contract is guaranteed. If, after reaching the last designated verifier node, the contract still cannot be inserted, the user who requested it will be refunded the same amount they paid in BTC, in TND tokens, taken proportionally from the participating nodes’ staking balances.
STEP FOUR
Encryption Nodes Challenges, Challenge Control, and Lifetime Latency
Once the Transcend Smart Contract is deployed on the blockchain, all linked nodes will issue a challenge to it every twelve hours. To do so, the nodes must monitor via a block explorer, any contract in which they are listed as encryption nodes.
The challenge consists of a timestamp seal: each node signs the timestamp (indicating when the challenge is initiated against the Smart Contract) using its private key. The Smart Contract then verifies that the signature matches the stored public key and confirms that the timestamp is valid upon receipt of the request.
This process confirms that the node linked to the Smart Contract is active and still holds the private key used to encrypt its assigned Shamir fragment.
The challenge is repeated every twelve hours for all nodes involved in the Transcend Smart Contract configuration.
This mechanism triggers the issuance of new TND tokens as a reward for those encryption nodes, representing the only way to mint the deflationary TND token.
As mentioned previously, any node that fails to complete the challenge will be penalized potentially losing its staked tokens and being expelled from the network.
Through its block explorer, the Cuvex App can continuously monitor both the status of the Transcend Smart Contract and the health of Shamir encryption across the blockchain.
If the number of disconnected encryption nodes approaches 40%, the App will issue alerts so the inheritance issuer may disable the contract and, if desired, create a new Smart Contract with the available active nodes.
Should the contract’s balance be depleted without receiving an update linked to a new BTC payment for the validator node that wins the random draw, the “Shamir Recovery and Decryption” process will be activated for the designated heirs.
A Transcend Smart Contract sets an additional safety period after the designated lifetime latency has expired. During this period, the issuer can replenish the contract balance to prevent its status from switching to “Shamir Recovery and Decryption.”
If the contract is not replenished within the safety period, the encryption nodes enter a monitoring mode, awaiting the contract’s status change in order to initiate the final process.
STEP FIVE
Shamir Recovery and Decryption for Designated Heirs
When the lifetime latency period expires without any action taken by the inheritance issuer, the Transcend Smart Contract can be claimed by the designated heirs.
To initiate this process, heirs must download the Cuvex App and activate it as inheritance recipients. The App will prompt them to:
-
Disconnect from all external networks (internet, Bluetooth, etc.).
-
Bring their Heir Card close to the device.
When the card is scanned, the App reconstructs the SHA-256 hash that must be linked to the inheritance contract.
The App then deletes all generated and stored information, leaving only the hash that identifies the heir in the smartphone’s secure element.
Next, the App requests permission to reconnect to the internet to locate the contract on the Transcend block explorer and check its status:
-
If the contract has not yet expired, it will display: “Lifetime Latency Active.”
-
If the contract has expired, it will display: “Lifetime Latency Expired. Shamir Recovery and Decryption can begin in X hours.”
Once Shamir Recovery and Decryption becomes available, the heir must make a new transaction on the smart contract to initiate the Recovery and Decryption process. The transaction fee will be the amount set at that time by the Transcend Node DAO for this operation.
To begin, the smart contract is executed again to randomly select the node that will validate the new Recovery and Decryption contract, as well as its verifier nodes. The designated node then creates a new Bitcoin payment address and signs it with its private key, recording the random draw details in the contract.
From there, based on the current fees, the designated node inserts the request into its verification process. In this specific verification process, the node only needs to wait for on-chain BTC payment confirmation from the inheritance recipient. Once this payment is verified according to the network’s rules, the node signs the Recovery contract update with its private key and broadcasts it to the blockchain.
Verifier nodes will certify that the validator node is properly performing its duties. If not, they can step in to complete the process, collecting payment in TND tokens as a penalty from the validator node designated by the random draw.
All remaining nodes will verify the parameters of this validated contract update to ensure it meets the requirements before accepting it and adding it to the network.
DECRYPTION PROCESS
The recipient pays the transaction fee to validate the Recovery and Decryption Smart Contract. The request will only be accepted if it originates from the SHA-256 hash of a designated Heir Card.
Once the transaction is validated on the blockchain with the required block confirmations, the encryption nodes begin the decryption process, which also serves as a signature capacity challenge. In return, they receive payment in TND tokens, which the Smart Contract issues specifically for this process.
Each node must:
-
Retrieve its encrypted Shamir fragment from the original inheritance contract.
-
Decrypt it using its private key.
-
Return the decrypted fragment to the Recovery and Decryption Smart Contract.
The Smart Contract verifies each decrypted fragment by comparing it to its original hash. If they match, the fragment is stored in the appropriate table and the node is rewarded with newly issued TND tokens. If they do not match, the node forfeits payment and is additionally penalized.
Once 51% of the nodes have completed decryption and submitted their fragments, the heir can download them and proceed with final decryption. After an additional 12-hour period from the moment 51% of the fragments have been decrypted, the Smart Contract penalizes all nodes that did not participate in the decryption process, thereby encouraging continuous 24/7 availability of the nodes.
SHAMIR RECONSTRUCTION
The Cuvex App locally downloads the decrypted fragments from the Smart Contract. Once 51% of the necessary fragments have been obtained, the App reassembles the Shamir scheme.
-
The App then instructs the user to once again disconnect from all external networks.
-
The user holds the Heir Card close to the device.
-
The App reconstructs the BLAKE2 key used to encrypt the original secret and decrypts the AES-256-GCM.
-
Finally, the App displays the decrypted secret, which contains the second password required to decrypt the Heir Card on a Cuvex device.
At this final stage, the sovereign and decentralized process of transferring cryptoassets as inheritance is completed.
CONCLUSION
The Transcend Node platform, powered by Cuvex, offers a fully decentralized, private, and secure solution for transferring cryptoassets as an inheritance ensuring the issuer retains complete control while alive, and granting sovereign access to designated heirs at the appropriate time.
Because the Transcend Node Blockchain does not store any personal or security information, in practice, the only data passed on to the heirs is one of the two passwords required to decrypt the secret stored on their NFC cards, entirely offline.
As you have reached the end of the page, we invite you to subscribe to our waitlist. In doing so, you can stay informed about our next steps and, if interested, take part as a developer, promoter, advisor, or investor gaining direct access to the first Node network that will deploy the Transcend Node platform.