Storing Private Data Onchain

You encrypted data for one party. Now you need to share it with another — without revealing it to the world. Re-encryption makes this possible onchain.

SKALE's re-encryption primitive allows encrypted data to be forwarded across blocks and selectivley shared in two ways:

1. With a viewer key (i.e so each player's poker hand is encrypted for that specific player)
2. With the public bls key (i.e so the validators can decrypt and re-encrypt information across blocks)

The former is great for selective information that needs to be shared but not acted within the smart contracts on. The latter is perfect for when information needs to be stored privatley onchain and used within Solidity without leaking the information to the world.

The Problem

Once data is encrypted to a specific key, standard encryption traps it. Either the holder decrypts and re-encrypts manually (exposing plaintext) or the data stays locked to the original recipient.

Onchain, this is worse. Smart contracts [normally] can't hold secrets — any decrypted state is visible to all validators.

What Re-Encryption Enables

Re-encryption uses threshold cryptography to transform ciphertext encrypted to one key into ciphertext decryptable by another — the committee decrypts via CTX, then re-encrypts to the new recipient.

Use Cases

Onchain Information Sharing. Medical records, financial data, or proprietary research stored encrypted onchain can be selectively shared with new parties. The original holder authorizes — the chain executes the re-encryption without seeing content.

Private Data Delegation. An agent holding encrypted data can delegate access to another agent without transferring the decryption key. The delegator specifies the new recipient; validators handle the cryptographic transformation.

Confidential Tokens. Token balances encrypted to holder keys. Transfers re-encrypt to the recipient's viewer key. The contract never sees plaintext balances — only the sender and recipient can decrypt their own data.

Encrypted Messaging Patterns. Messages encrypted onchain that can be forwarded to new participants. Group membership changes without decrypting message history.

How It Works

The protocol provides two encryption modes:

• Threshold Encryption (TE) — BITE.encryptTE() encrypts data to the validator committee. Only a supermajority of validators can decrypt, triggered via a CTX callback. Think of it as a sealed envelope that only the network can open.
• Viewer Key Encryption (ECIES) — BITE.encryptECIES() encrypts data to a specific public key (secp256k1). Only the holder of the corresponding private key can decrypt — client-side, no committee required. Think of it as a sealed envelope addressed to one person.

Re-encryption bridges these. Data encrypted via TE can be decrypted through a CTX callback, then re-encrypted to any viewer key within the same callback.

The committee holds threshold shares of the private key. No single validator can decrypt alone. A supermajority must collaborate to decrypt via CTX, and the contract's onDecrypt callback handles re-encryption to the recipient's viewer key.

// Store threshold-encrypted data
bytes memory encryptedData = BITE.encryptTE(BITE.ENCRYPT_TE_ADDRESS, plaintext);
 
// Later: submit CTX to decrypt and re-encrypt in callback
BITE.submitCTX(BITE.SUBMIT_CTX_ADDRESS, gasLimit, encryptedArgs, plaintextArgs);
// The onDecrypt callback then calls BITE.encryptECIES() with the viewer key

source — docs

Real Example: Confidential Poker

The live poker demo demonstrates re-encryption in practice — read the full walkthrough here. Here's how it works:

When cards are dealt, each hole card is:

1. Threshold encrypted (encryptTE) for the showdown reveal
2. ECIES encrypted (encryptECIES) to the player's viewer key for client-side viewing

During the hand, only the player can see their hole cards — decrypted via their private key. At showdown, a CTX decrypts the threshold-encrypted version to evaluate the winner. No single entity ever sees all cards unencrypted until the protocol triggers reveal.

This pattern applies beyond poker:

• Private document sharing with viewer-key access
• Confidential escrow where terms encrypt to mediator and participants
• Selective disclosure for compliance (re-encrypt to auditor keys)

Re-Encryption + CTXs

Re-encryption becomes more powerful combined with Conditional Transactions. A contract can:

1. Store threshold-encrypted data
2. Wait for conditions (time, payment, approval)
3. Trigger a CTX that re-encrypts to a new recipient
4. The new recipient receives without ever touching plaintext onchain

This is "encrypted info block over block" — data flows through the chain, transforming in encrypted form, only decrypting at final destinations.

Building with Re-Encryption

If you're building applications that need private data sharing — onchain info sharing, data delegation, confidential tokens — re-encryption is live on SKALE chains. No external infrastructure. No TEEs. Standard Solidity patterns.

Reach out if you want to better understand how re-encryption and programmable privacy could help your business.

Sources

1. SKALE BITE Documentation, https://docs.skale.space
2. SKALE BITE Solidity Library, https://github.com/skalenetwork/bite-solidity
3. Confidential Poker Implementation, https://github.com/TheGreatAxios/confidential-poker