top of page
background_transcend_right.jpg

WHITE PAPER

TRANSCEND
NODE

header_transcend.jpg
WHITE PAPER

TRANSCEND
NODE

ABSTRACT

The purpose of this document is to provide an initial overview of Transcend Node and its related technologies, including Cuvex 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 Transcend Node that are essential to achieving its stated objectives.

Below, you can read our white paper online on this page, or if you prefer, download it.

CUVEX

Only when you have full offline control of your seed phrase are you truly the sovereign owner of your crypto assets.

Based on this principle, as our first step, we developed the Cuvex system:


Possibly the most secure solution today for Bitcoin (BTC) wallet creation and management, as well as for seed phrase backup and recovery. The system consists of the Cuvex hardware device and the Cuvex smartphone and desktop apps.

The Cuvex system provides comprehensive support so that anyone, regardless of their technical knowledge or skills, can:

1

Create and manage a secure seed phrase recovery process, generating cryptograms with encrypted backups and storing them on NFC cards.

2

Generate a 100% offline BTC wallet, actively participating in the entropy generation process of the seed phrase using the “Dice and Coin” standard.

3

Manage their BTC wallet with advanced Coin Control privacy features, ensuring privacy by design.

4

Sign transactions using a dual AirGap PSBT process, guaranteeing physical separation of offline components required to move funds securely.

TRANSCEND

In our initial stage, we have helped our clients regardless of their technical expertise overcome the industry's most pressing challenges by delivering robust solutions based on zero-knowledge privacy policies, ensuring complete independence from our systems at all times, and developing cryptographic technology designed to uphold human freedom, privacy, and security.

Now, we take it a step further: adding value to the final transition we all inevitably face transcending the value of our crypto assets to our loved ones when we can no longer manage them ourselves.

For this purpose, enabling the sovereign automation of crypto asset inheritance, our approach is built upon the following core principles:

1

No centralized entity should ever be involved in this process. It must be a fully decentralized mechanism, relying on the guarantees of an anti-coercive network that can persist indefinitely without any form of centralized control including our own.

2

Crypto assets must remain fully accessible to the original owner until they are no longer able to maintain control. Funds cannot be locked in smart contracts that restrict access.

3

To uphold these principles, the system must be inherently designed around three fundamental pillars: Privacy, Security, and Decentralization. These must be irrevocable by definition, ensuring a seamless user experience that does not require extensive technical knowledge to execute the inheritance process.

TRANSCEND

Decentralized Crypto Asset Inheritance

Introduction

The Transcend network will be supported by a community of participants running their own Cuvex blockchain nodes.

These nodes will be responsible for managing, securing, and maintaining the efficiency of the CUVX token blockchain.

On this independent blockchain, not reliant on any external network, encrypted secrets created by inheritance issuers will be stored. These secrets will only be released to designated recipients when the issuer’s life latency challenge is not fulfilled.

Node operators must maintain a required amount of CUVX tokens in staking to participate in the network. Their role is to ensure the decentralized protection of encrypted secrets, validate transactional blocks, uphold the network’s decentralized integrity, and receive fees directly in Bitcoin (BTC) as compensation.

Any node that fails to meet availability verification challenges for decryption, or attempts to introduce fraudulent operations, will be penalized potentially losing its staked tokens. These forfeited tokens will then be redistributed among compliant nodes with no active penalties.

Conclusion

Transcend is a protocol executed through smart contracts operating on the Cuvex Blockchain, ensuring the configuration and secure delivery of an encrypted secret that grants access to an inheritance of crypto assets. The inheritance is released only when the issuer is unable to fulfill the pre-defined life latency challenge they established.

The Cuvex Blockchain will be operated by independent nodes that guarantee its security and efficiency through CUVX utility token staking. Nodes failing to perform their duties will be penalized by losing their staked CUVX tokens and being expelled from the network.

As compensation, nodes will receive operational fees directly in Bitcoin (BTC).

Background_letters.jpg

HOW TRANSCEND WORKS

1. OFFLINE MULTISIGNATURE ENCRYPTION OF THE INHERITANCE SECRET

2. CREATION AND DEPLOYMENT OF THE TRANSCEND SMART CONTRACT ON THE CUVEX BLOCKCHAIN

1.

OFFLINE MULTISIGNATURE ENCRYPTION OF THE INHERITANCE SECRET 

blog cuvex encrypt

A

Encryption Process with Cuvex

Using the Cuvex device, users can generate a BIP39 seed phrase, either for Bitcoin or any other compatible crypto asset. Additionally, the Cuvex device can encrypt any other seed phrase, even if it was not originally generated on the device.

The AES-256-GCM encryption of the seed phrase is performed entirely offline within the Cuvex device, ensuring maximum security. Furthermore, multi-signature access control can be applied to the resulting cryptogram.

For use within the Transcend system, the protected secret (which is intended to be delivered to the heirs) must be secured with at least a 2-of-2 multi-signature access control mechanism. This means that at least two passwords will be required to decrypt the secret.

Once the wallet’s encrypted seed phrase intended for the heirs has been generated, the resulting cryptogram is stored in the memory of an NFC card, referred to in this document as the "Original Card".

B

Cloning the Original Card

The Cuvex device allows the cloning of the Original Card. The inheritance issuer must create as many clones as necessary, corresponding to the number of designated heirs. It is recommended to generate at least five clones to ensure system redundancy.

These cloned cards will be referred to as "Heir Cards".

CONCLUSION

By the end of this first step, the inheritance issuer has:

1. Securely encrypted a seed phrase and its passphrase using AES-256-GCM in a dedicated cryptographic hardware device.

2. Established a 2-of-2 multi-signature access requirement for decryption.

3. Stored the cryptogram on multiple NFC cards, including the Original Card and several Heir Cards.​

 

The inheritance issuer will then physically distribute one or more Heir Cards to the designated heirs, providing them with only one of the two required passwords for decryption.

The second password required to unlock the Heir Cards will be retrievable from the Transcend platform once the issuer is unable to renew the life latency challenge.

bitcoin

2.

CREATION AND DEPLOYMENT OF THE TRANSCEND SMART CONTRACT ON THE CUVEX BLOCKCHAIN

Once the inheritance issuer has encrypted their seed phrase and passphrase onto both the Original Card and Heir Cards, they can proceed with the creation and deployment of the Transcend Smart Contract on the Cuvex blockchain. This smart contract is responsible for safeguarding one of the two passwords required to decrypt the Heir Cards. This process consists of the following 5 steps:

STEP ONE
Smart Contract Creation

The issuer uses the Cuvex smartphone app to initiate the creation of a Transcend Smart Contract. The app first instructs the user to disconnect from all external connections (Bluetooth, internet, etc.) and then prompts them to scan the Original Card.

Hash and Key Generation

  • Using the encrypted binary data stored on the Original Card, the Cuvex app while in offline mode generates a SHA-256 hash, which serves as a unique identifier for the smart contract and links it to the inheritance issuer.

  • Additionally, the app derives an RSA key pair (private and public) from the same encrypted binary data of the Original Card. This key pair will be used later to sign transactions and requests on the Cuvex blockchain.

Backup Heir Card Option

  • The app allows the issuer to designate a Heir Card as an additional Original Card, providing a backup method for managing their digital inheritance in case the Original Card is lost.

Heir Card Processing

  • Next, the issuer is instructed to scan each Heir Card one by one.

  • For each Heir Card, the app generates two distinct hashes: a BLAKE2 hash and a SHA-256 hash, both derived from the encrypted binary data of the card.

  • Similar to the Original Card process, the app also derives an RSA key pair (private and public) from each Heir Card’s encrypted binary data, which will be used to sign transactions and blockchain requests.

Encryption of the Multi-Signature Password

  • Once all Heir Cards have been scanned, the app prompts the issuer to enter the multi-signature password that was established during the Original Card's creation. This password is the one that was not given to the heirs.

  • The Cuvex app then encrypts this password using AES-256-GCM, with each Heir Card’s BLAKE2 hash serving as the encryption key.

  • This results in one cryptogram per Heir Card. For example, if the issuer registers five Heir Cards, the app generates five distinct AES-256-GCM cryptograms, each using its corresponding BLAKE2 hash as the encryption key.

Secure Data Storage and Automatic Data Deletion

Once the process is complete, the app permanently deletes all read and generated data, ensuring that no sensitive information remains. Only the following data is securely stored within the smartphone’s secure element:

  • All cryptograms created for the registered Heir Cards.

  • All generated hashes, including those of the Original Card (and its backup) as well as the Heir Cards, signed with the issuer’s private RSA key.

  • All generated public RSA keys, both for the Original Card (and its backup) and the Heir Cards.

STEP TWO
Smart Contract Deployment and Node Selection

Once Step One is completed, the Cuvex App prompts the user to enable internet connectivity to establish a connection with a Cuvex block explorer. This connection allows the user to select a preferred Cuvex node to interact with, provided they have one.

Randomized Node Selection for Inheritance Validation

Upon connecting to a Cuvex block explorer, the app instantiate a smart contract that initiates a randomized assignment of nodes to serve as validators and encryptors for the inheritance process. These nodes are linked to the SHA-256 hash of the Original Card, signed with the issuer's private RSA key obtained in the previous step.

Once this smart contract is instantiated on the Cuvex blockchain, an auditable lottery mechanism is triggered across the network, selecting 370 nodes to act as validators and encryptors for the Transcend Smart Contract, which is uniquely identified by the SHA-256 hash of the Original Card, signed with the issuer’s private RSA key.

Additionally, this lottery determines which of these 370 nodes will act as the primary node (the winning node), which will receive a Bitcoin (BTC) transaction fee from the inheritance issuer in exchange for registering the contract.

A maximum of 369 nodes is set as validators and encryptors, as each node's RSA key is used to encrypt a Shamir secret share of the inheritance recovery key. This number of fragments ensures the integrity and resilience of the encryption stored on the Cuvex blockchain. Further details on this process will be provided later in this document.

Ensuring Fair Node Participation: The Hourglass Selection Process

Once a node has been selected as a winning node, it is excluded from future lotteries until all other nodes on the network have had an opportunity to act as a primary node for a different contract. This approach, referred to as the "Hourglass Process", ensures equal participation by systematically rotating the selection until all nodes have played a role in contract validation and insertion.

BTC Payment Address Generation

The selected primary node generates an on-chain BTC address to receive its compensation fee. It then signs this address with its private key and sends it to the smart contract in charge of the lottery.

The lottery smart contract then returns the following information to the Cuvex App:

  • The public RSA keys of the 369 selected nodes that will be used for encryption.

  • The BTC on-chain payment address of the primary node, which will be linked to the Transcend Smart Contract.

 

If, for instance, there are only 200 active nodes, all 200 nodes will be assigned as encryptors and validators. In this case, the smart contract will notify the app, providing:

  • The 200 RSA public keys of the assigned nodes.

  • The on-chain BTC address created by the primary node, where the issuer must send the required payment.

Shamir Secret Sharing and Encryption

Using the received node information, the Cuvex App performs the following:​

1. Shamir Secret Sharing Scheme (SSS) Fragmentation

Each cryptogram stored in the secure element of the smartphone is split into 200 fragments (following the example of 200 active nodes).

To reconstruct the secret, at least 51% of the fragments will be required.

2. Hashing and Encryption

The app generates a SHA-256 hash for each fragment.

Each fragment is encrypted using the RSA public key of a different node.

A table is created with the following information, which will be submitted to the Transcend Smart Contract:

SHA-256 hashes signed with the issuer’s private RSA key, identifying the inheritance issuer.

SHA-256 hashes signed with the issuer’s private RSA key, identifying the designated heirs.

All RSA public keys, including those of the Original Cards and Heir Cards.

The SHA-256 hash of the unencrypted Shamir fragment.

The encrypted Shamir fragment, secured with the node’s RSA public key.

The on-chain BTC payment address of the primary node linked to the Transcend Smart Contract creation.

 

This encryption and distribution process is repeated for all 199 remaining fragments and for each cryptogram stored in the secure element of the smartphone, ensuring that all cryptographic shares are properly secured and distributed across the network.

STEP THREE
Creation and Deployment of the Transcend Smart Contract on the Cuvex Blockchain

Once all cryptograms have been fragmented using Shamir, their hashes calculated, fragments encrypted, and linked to the corresponding metadata, the Cuvex App generates a comprehensive data table containing all this information. Additionally, a CUVX token receiving address is added to this table, which will be used to refund the amount paid in BTC (converted to CUVX tokens) in case the contract validation and insertion process cannot be completed. All this data is included in the Transcend Smart Contract.

The app then calculates the transaction weight in Bytes and prompts the issuer to define the life latency period.

The cost of validating and inserting the Transcend Smart Contract into the Cuvex blockchain depends directly on both the transaction weight and the chosen life latency period. The app displays the real-time cost by querying current network fees via the block explorer, which are set by the configuration the Cuvex Blockchain.

Decentralized Encryption Challenge ("Ciphering Challenge")

To ensure decentralization and accessibility, participating nodes must demonstrate their ability to decrypt the encrypted Shamir fragments assigned to them every twelve hours. This recurring process, known as the "Ciphering Challenge", serves to maintain the availability and security of the Transcend protocol.

  • Nodes that fail to meet the challenge requirements are penalized by losing a portion of their staked CUVX tokens.

  • If a node repeatedly fails to meet the challenge beyond a threshold set by the community, it will lose all staked CUVX tokens and be permanently removed from the network.

 

Redistribution of Penalized Tokens & Expanding the Network

  • Tokens lost by penalized nodes are redistributed among compliant nodes in an equitable manner.

  • When nodes accumulate enough additional tokens, they can activate new nodes, expand their participation, and further decentralize the network.

Payment and Renewal of the Transcend Smart Contract

  • The inheritance issuer must pay the transaction fee set by the network, which depends on the transaction weight and the chosen life latency period.

  • When the life latency period expires, the issuer can renew the contract by making an additional payment for another term.

  • Failure to make this renewal payment serves as the life latency failure indicator, signaling that the issuer is no longer available.

  • Upon confirmation of the latency failure, the contract switches to "Shamir Recovery & Decryption" mode, allowing designated heirs to retrieve the inheritance after a security period predefined by the issuer.

 

Smart Contract Validation & Deployment on the Cuvex Blockchain

For the Transcend Smart Contract to be validated and inserted into the Cuvex blockchain, the process follows a structured verification system executed by the assigned node. If the assigned node fails, any other validator node in the designated pool can take over the process.

The verification steps include:

1

Data Structure & Content Validation:

Verify that the uploaded data table adheres to the smart contract’s structure.

Check for:

Number of encrypted Shamir fragments

Number of hashes of unencrypted fragments

Number of linked RSA public keys

RSA signatures

Data structure and required cryptographic components to ensure future decryption by heirs.

2

Transaction Weight & Life Latency Period Verification:

Confirm that the transaction weight and latency period match the network’s current fee structure.

3

On-Chain BTC Payment Confirmation:

Verify that sufficient BTC funds have been deposited to the assigned on-chain address.

Wait for the required number of blockchain confirmations as defined by the Transcend network’s consensus rules.

Once all checks are completed, the validator node signs the transaction with its private key and and thus requests its review and sending to the mempool of the Cuvex blockchain

  • Other nodes verify the validator's signature to ensure it belongs to the winning node from the lottery process.

  • They also cross-check the rest of the contract data to finalize the block validation before adding it to the mempool Cuvex blockchain.

Backup Validation Mechanism

To ensure contract insertion and validation, verifier nodes are responsible for confirming that the assigned validator node has correctly completed its task.

  • If the validator fails to insert the contract, a predefined sequence of backup verifiers (determined by the smart contract) steps in to complete the validation.

  • The fallback mechanism is triggered based on the Bitcoin blockchain block height, ensuring that no contract remains in limbo.

  • The first available verifier from the sequence takes over, validates, signs, and inserts the contract into the Cuvex blockchain.

Penalties for Validator Node Failure

  • If a designated validator node fails to execute its duties, it is penalized by forfeiting CUVX tokens equivalent to the BTC fee it was supposed to receive.

  • These forfeited tokens are transferred to the staking balance of the verifier node that successfully completes the contract insertion process.

Guaranteed Smart Contract Insertion

The Transcend protocol guarantees that every inheritance contract is inserted into the blockchain, even if multiple validator nodes fail.

  • If the final designated verifier node is unable to complete the contract insertion, the BTC fee originally paid by the user is refunded in CUVX tokens.

  • The CUVX tokens used for the refund are sourced from the staking guarantees of participating nodes, with the required amount being proportionally deducted from all validator nodes.

STEP FOUR
Ciphering Node Challenges, Challenge Monitoring,
and Life Latency Management

Once the Transcend Smart Contract has been successfully deployed on the Cuvex blockchain, all linked nodes must perform a challenge against the contract every twelve hours. To participate, nodes must actively monitor the blockchain using a block explorer to detect any contracts in which they are listed as ciphering nodes.

Ciphering Challenge Mechanism

Each challenge requires the node to perform a timestamp seal by signing the exact timestamp with its private key at the moment the challenge is issued against the Transcend Smart Contract.

  • The smart contract validates the signature, ensuring it matches the stored public key.

  • The timestamp must be valid at the moment of receipt, confirming that the node remains active and still possesses the private key used to encrypt its assigned Shamir fragment.

 

This process repeats every twelve hours for all participating nodes linked to a Transcend Smart Contract.

 

Penalties for Non-Compliance​​

  • As previously mentioned, nodes that fail to meet the challenge will be penalized.

  • ​Repeated non-compliance results in losing staked CUVX tokens and permanent expulsion from the network.

 

Contract Monitoring & Network Health Management

The Cuvex App, through its block explorer, continuously monitors the status of each Transcend Smart Contract and the integrity of Shamir encryption across the Cuvex network.

  • If the percentage of disconnected ciphering nodes reaches 40% during any given challenge cycle, the app will generate alerts, notifying the inheritance issuer.

  • The issuer is then given the option to deactivate the contract and create a new Transcend Smart Contract with the currently active nodes.

 

Triggering the “Shamir Recovery & Decryption” Process

  • If the contract balance is depleted and no additional BTC payment is received to compensate the next validator node, the system will automatically activate the “Shamir Recovery & Decryption” process for the designated heirs.

  • A Transcend Smart Contract includes an additional security period following the expiration of the designated life latency period.

    • During this security window, the issuer has the opportunity to recharge the contract and prevent it from entering Shamir Recovery & Decryption mode.

 

  • If the contract is not recharged within the security period, ciphering nodes transition into a monitoring state, awaiting the final contract status change before proceeding with the recovery and decryption process.

STEP FIVE
Recovery and Decryption for Designated Heirs

Once the life latency period expires without any action from the inheritance issuer, the Transcend Smart Contract can be claimed by the designated heirs.

To initiate the recovery process, heirs must download the Cuvex App and activate it as inheritance recipients. The app will guide them through the following steps:

  1. Disconnect from all external networks (Internet, Bluetooth, etc.).

  2. Scan their Heir Card using their device.

 

Upon reading the card, the Cuvex App reconstructs the SHA-256 hash, which must be linked to the inheritance contract. Additionally, the corresponding RSA key pair (private and public) is restored.

  • The app then erases all generated and stored information, keeping only the RSA-signed hash within the device’s secure element, ensuring that the heir’s identity remains protected.

 

Verifying the Contract Status

Next, the app requests internet access to locate the Transcend Smart Contract via the Cuvex block explorer and verify its current status.

  • The app sends a request to the smart contract, including:

    • SHA-256 Hash

    • Timestamp

    • RSA-signed authentication

 

This ensures that the contract can verify the request as legitimately coming from a designated heir.

Depending on the contract’s status, the following messages will be displayed:

  • “Life Latency Active” → The inheritance contract is still within the latency period and cannot yet be claimed.

  • “Life Latency Expired. Recovery and Decryption Process will be available in X hours” → The contract has expired, and the decryption process will soon be available.

Initiating the Recovery and Decryption Process

Once the Recovery and Decryption Process is unlocked, the heir must execute a transaction on the Transcend Smart Contract to begin Shamir Recovery and Decryption.

  • The fee required for this transaction will be based on the current Cuvex blockchain network rates.

 

This triggers the execution of the smart contract, which will:

  1. Randomly select a validator node to verify the new contract status as "Recovery and Decryption".

  2. Assign additional verifier nodes to oversee the process.

 

The designated validator node will:

  • Generate a new Bitcoin (BTC) payment address, sign it with its private key, and record it within the Transcend Smart Contract.

  • Based on the current network fees, insert the recovery request into the verification process.

 

At this stage, the only required verification step is ensuring the BTC payment transaction from the heir is confirmed on-chain.

  • Once the BTC payment is verified according to network rules, the validator node signs the contract update with its private key, linking the on-chain BTC transaction ID and inserting the update into the Cuvex blockchain.

 

Validation and Finalization by Verifier Nodes

  • Verifier nodes ensure that the validator node properly executes its task.

  • If the validator node fails to process the contract update, the verifiers step in and complete the task, receiving their fees in CUVX tokens.

  • The validator node that failed to complete the task is penalized, and the equivalent CUVX token amount is transferred to the verifier nodes.

 

Once the contract update is validated, all remaining network nodes cross-check its parameters and finalize its insertion into the Cuvex blockchain.

DECRYPTION PROCESS

1. Transaction Validation for Smart Contract Execution

The heir initiates a transaction to validate the Recovery and Decryption Smart Contract.

The request will only be accepted if it originates from a SHA-256 hash signed with the private RSA key of a designated Heir Card.

2. Ciphering Nodes Execute Decryption

Once the transaction is confirmed on the Cuvex blockchain, as per the required block confirmations, the ciphering nodes begin the decryption process.

This process is also a signature capacity challenge.

3. Decryption Steps for Each Node:

Retrieve the encrypted Shamir fragment from the original inheritance contract.

Decrypt it using their private key.

Return the decrypted fragment to the Recovery and Decryption Smart Contract.

4. Validation and Rewards

The smart contract validates each decrypted fragment by comparing it to its original hash.

If the fragment matches the expected hash, it is stored in the corresponding table.

If the fragment does not match, the node is penalized.

5. Threshold-Based Access for Heirs

Once 51% of the nodes have completed the decryption process and returned their fragments, the heir can proceed with downloading and reconstructing the secret.

After an additional 12-hour grace period following the 51% threshold, the smart contract penalizes all nodes that failed to participate, reinforcing 24/7 availability incentives for the network.

SHAMIR RECONSTRUCTION

  1. The Cuvex App downloads the decrypted fragments locally from the Recovery and Decryption Smart Contract.

  2. Once the 51% threshold of required fragments is reached, the app reconstructs the Shamir secret.

  3. The app prompts the user to disconnect from all external networks (Internet, Bluetooth, etc.).

  4. The user scans their Heir Card with their device.

  5. The app reconstructs the BLAKE2 key used to encrypt the original secret and decrypts the AES-256-GCM encryption.

  6. Finally, the app displays the decrypted secret, which contains the second password needed to unlock the Heir Card on a Cuvex device.

 

This final step completes the sovereign and decentralized transfer of the crypto-asset inheritance.

CONCLUSION

The Transcend system, powered by Cuvex, provides a fully decentralized, private, and secure solution for transferring crypto assets as inheritance. It ensures that:

  •  The issuer retains full control of their assets while alive.

  • The inheritance is securely and autonomously delivered to the designated heirs at the right time.

  • No personal or sensitive data is stored on the Cuvex blockchain.

  • The only data transferred to heirs is one of the two required passwords, enabling them to decrypt the secret stored offline on their NFC cards.

Through zero-trust principles, cryptographic security, and decentralization, Transcend ensures a trustless, censorship-resistant inheritance mechanism, guaranteeing the sovereign transfer of wealth without reliance on intermediaries.

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.

WAITLIST

TRANSCEND
WHITE PAPER

Powered by Cuvex...Soon
bottom of page