Thanks to @TheGreatAxios for advocating importance of privacy for next generation blockchains and for the great discussions on this topic!
Abstract:
Since the inception of smart contracts on Ethereum in 2015 [1], privacy has remained one of the blockchain ecosystem’s most persistent unsolved challenges. Early solutions like zk-SNARKs [2] enabled zero-knowledge proof verification but did not support private computation within smart contracts. Projects such as Enigma [3], Secret Network [4], and Zexe [5] explored different paradigms for encrypted execution, but often at the cost of developer experience, composability, or decentralization. More recently, fully homomorphic encryption (FHE) and threshold cryptography have shown promise for enabling secure on-chain computation without data leakage.
BITE (Blockchain Integrated Threshold Encryption) is a groundbreaking protocol that brings full-stack privacy to blockchain systems without compromising decentralization or Solidity compatibility. BITE introduces a phased approach to private computation on-chain, starting with encrypted transactions (Phase 1) and evolving through private smart contract execution (Phase 2), user-specific access control via threshold re-encryption (Phase 3), and culminating in the integration of threshold fully homomorphic encryption (TFHE) for confidential computation (Phase 4). This progression unlocks a wide array of privacy-preserving applications, including sealed auctions, private messaging, secure trading, confidential DeFi, encrypted gaming, private DAOs, and full-featured on-chain banking. By transforming blockchains into privacy-preserving cloud computers, BITE bridges the usability of Web2 with the trustlessness of Web3, offering developers and users a seamless path toward building and interacting with decentralized systems that respect confidentiality by design.
BITE Protocol Goals
What Users Want
- Store private information on the blockchain.
- Grant dApps fine-grained access to this information.
- Enjoy an experience similar to Web2 applications.
What Developers Want
- Continue using Solidity.
- Easy development workflows.
- Minimal learning curve.
Important Use Cases for Private Information
- Games with private user data (e.g., card games).
- Censorship resistance.
- DeFi and trading (MEV protection, secret trading algorithms, and private bids).
- Commerce (buying things without global visibility).
- Social networks (sharing data only with friends).
- Secret voting in DAOs.
- Tax filings.
- Storing private documents on-chain.
- Prediction markets with private bids.
We can progressively address all these needs in BITE (Blockchain Integrated Threshold Encryption) through stages, starting with simple algorithms and evolving to more complex ones while covering increasingly important use cases.
BITE Roadmap
Phase 1: Threshold-Encrypted Transactions (Available Now)
- Encrypt transaction data and destination address using threshold encryption.
Problems Solved:
- Censorship resistance.
- MEV resistance.
- Secure prediction market submissions.
- Concurrent moves in games (keeping moves secret until execution).
- Front-running and cheating protection for all kinds of on-chain compute protocols (e.g., ChatGPT-on-chain systems).
Phase 2: Threshold Decryption Inside Smart Contracts
We will introduce a Decryptor smart contract that decrypts data and passes it to a user-defined onDecrypt() function.
Decryptor Contract
contract Decryptor {
// decryptAndProcess takes a function pointer and encrypted data
function decryptAndProcess(
function (bytes memory) internal pure onDecrypt,
bytes memory encryptedData
) internal pure {
onDecrypt(decryptedData);
}
}
How Developers Will Use It
Here is a “Hello World” example where a smart contract takes threshold-decrypted data and decrypts it on demand.
function print(bytes memory decryptedHelloWorld) {
console.logBytes(decryptedHelloWorld);
}
function main() external pure {
bytes memory abiEncodedData = abi.encodePacked(encryptedHelloWorld);
decryptAndProcess(print, abiEncodedData);
}
In this example,
-
the developer provides an encrypted data blob and a print function that prints decrypted text .
-
BITE
Decryptorsmart contract handles decryption and processing inside Solidity, enabling privacy-preserving operations directly within smart contracts.
How it will be implemented in the protocol
- When
decryptAndProcess()is called, a transaction will be added to the beginning of the next block that will execute the function (similar toasyncfunctions in JavaScript). - All
decryptAndProcess()calls for the current block $i$ will be collected. - The corresponding threshold decryptions batch will be executed at the start of processing the next block.
- Phase 1 and Phase 2 decryptions will therefore go into the same batch.
- When all decryptions are performed,
onDecrypt()transactions will be executed at the start of block $i+1$.
Use cases for BITE phase 2.
A) Auction with Private Sealed Bids
- Users submit encrypted bids.
- The smart contract collects bids until the cutoff time $T$.
- At time $T$, the smart contract decrypts all bids at once and selects a winner.
B) Sealed Future Transfers (On-Chain Will)
- A user submits an encrypted will with encoded money transfers.
- At time
T, the smart contract decrypts the will and executes the transfers specified in the will.
C) Confidential Sealed Prediction Market
- Users submit secret predictions and bids for an event
- At the time of the event, bids are unsealed and prediction market is settled.
D) Conditional Encrypted Trading Triggers
-
Users submit encrypted conditions (e.g., “If price of ETH > $5000, sell 10 ETH”).to the exchange smartcontract.
-
On reaching certain triggers, the exchange decrypts and processes these conditional operations.
E) Time-Locked Private Messages
- Users send encrypted private messages on-chain.
- Messages automatically decrypt and become readable at a specified future time (e.g., after 1 year, in a “decentralized time capsule” app).
F) Sealed Negotiation Contracts
- Two parties submit encrypted negotiation terms.
- When both sides submit, the contract decrypts both at the same time and executes based on the agreed overlap.
G) On-Chain Secret Gifting
- Encrypted gifts (NFTs, tokens) are submitted to recipients.
- Gifts decrypt and transfer automatically at special dates (birthdays, anniversaries) without any party controlling the timing.
H) Next-Generation Secure Multisig Contract Update
- An encrypted contract update byte is submitted to the chain.
- Attackers cannot see the update until a threshold of multisig approvals is reached.
- Once the threshold is met, the update is decrypted and executed.
I) Game: Rock-Paper-Scissors
- Users submit their encrypted choices.
- Decryption occurs simultaneously once all choices have been submitted.
J) Game: Battleship
-
Each player encrypts their board (the full 10x10 grid with ships) using the threshold public key.
-
They send the encrypted board to the smart contract.
-
The smart contract waits for players to submit moves.
-
When a guess is made, the Decryptor contract triggers threshold decryption on:
- The opponent’s board.
- The guessed coordinate.
-
Only the single square at the guessed coordinate is decrypted and revealed
Phase 3: Threshold Re-encryption Inside Smart Contracts
Phase 3 differs from Phase 2 by adding re-encryption for a specific user or group.
Instead of decrypting the ciphertext and making it public, the smart contract re-encrypts it to the public key of a specific user or group, effectively granting them exclusive access to the information.
contract Decryptor {
// decryptAndProcess takes a function pointer and encrypted data
function decryptAndProcess(
function (bytes memory) internal pure onDecrypt,
bytes memory encryptedData
) internal pure {
onDecrypt(decryptedData);
}
// reencryptAndProcess takes a function pointer and encrypted data
function reencryptAndProcess(
function (bytes memory) internal pure onReencrypt,
bytes memory encryptedData,
bytes memory destinationPublicKey
) internal pure {
onReencrypt(reencryptedData);
}
}
Use cases for BITE phase 3.
Phase 3 enables a huge number of access control use cases and makes many mainstream Web 2 apps implementable in Solidity
A) Private Documents with sharing and access control
- Store AES-encrypted document on chain with AES key encrypted using threshold encryption
- Provide access to the document to a specific user by reencrypting the AES key of this document to the public key of a particular user.
B) Web-2 like social networks
- Publish encrypted messages on chain
- Provide access to the messages to your friends only.
C) Collaborative document editing
- Publish encrypted document on chain
- Provide access to the document to other users
- Collaboratively edit the document
D) On-chain licensing, access, copyright and subscription management
- Use threshold encryption to encrypt secret license key for video stream, NFT, software etc.
- Prompt he user pay subscription fee
- Re-encrypt the access key to the user public key
E) Encrypted Supply Chain Management
- Goods metadata (origin, authenticity certificates) are encrypted.
- Authorized parties in supply chain (manufacturer, distributor) get access via re-encryption.
- Protects trade secrets while ensuring provenance.
F) Private DAOs (Decentralized Autonomous Organizations)
- DAO proposals and votes are encrypted.
- Only eligible voters’ keys are authorized to decrypt and view proposals.
- Re-encryption dynamically manages access as DAO memberships change.
G) Confidential On-chain Gaming
- Game states (hands of cards, private moves) stored encrypted.
- Re-encryption gives players access to only their cards/moves.
- Enables complex games like Poker entirely on-chain.
H) Secure On-chain Escrow and Dispute Resolution
- Encrypted evidence and documents submitted during escrow.
- Re-encrypt evidence only for arbitrators when needed.
- Keeps sensitive material private unless dispute arises.
I) E-commerce with Private On-chain Orders
- Customer orders are private (address, items, payment info).
- Seller publishes product info publicly on-chain (item name, price).
- Private Purchase (Order Creation)
- Buyer creates an order.
- Buyer encrypts their delivery address, customization options, and payment proof using threshold encryption.
- Order (with encrypted private data) is posted on-chain.
- Smart contract re-encrypts the buyer’s private order details to the seller’s public key (after verifying payment or escrow deposit).
- Now only the seller can decrypt and process the order.
- Seller decrypts the order and ships the product.
- Optionally, encrypted shipment tracking data could be updated on-chain and selectively re-encrypted to the buyer.
- Order details stay encrypted forever unless the buyer/seller choose to reveal them (e.g., for dispute resolution).
J) Encrypted Resumes, On-chain University Diplomas and Transcripts
- Students encrypt their grades, degrees, certifications.
- Employers request selective re-encryption proofs of education (e.g., “Graduated with Master’s in CS”) without seeing full transcript.
- Smart contracts verify authenticity without revealing all grades.
Phase 4: Threshold Fully Homomoriphic Encryption Inside Smart Contracts
While Phase 3 of BITEs enables the majority of today’s Web2 applications to be implemented in Web3, there remains one particularly challenging area: banking.
To implement an on-chain bank that operates on encrypted user data, several capabilities are required:
-
Ability to perform basic mathematical operations on encrypted data without decryption.
For example, a user might want to move money from savings to checking, which involves subtracting from one balance and adding to another — all without exposing any sensitive information. A similar scenario is transferring funds between users while maintaining confidentiality. -
Ability to disclose high-level information about user funds without compromising overall privacy.
For instance, a user may need to prove to a credit card application that they hold more than a certain amount of funds, without revealing the actual balance or any other account details.
The capabilities discussed above are provided by Threshold Homomorphic Encryption (TFHE).
Threshold Homomorphic Encryption combines homomorphic encryption with threshold cryptography. It enables computations on encrypted data while maintaining security, with the private key shared among multiple parties. A threshold number of parties is required to decrypt, ensuring that even if some participants are compromised, the secret remains protected.
In Phase 4 of the BITE Protocol, we plan to integrate an open-source TFHE framework into SKALE.
Several open-source frameworks are available, including:
- GitHub - zama-ai/threshold-fhe: Threshold MPC protocols for FHE
- GitHub - tuneinsight/lattigo: A library for lattice-based multiparty homomorphic encryption in Go
- GitHub - openfheorg/openfhe-development: This is the development repository for the OpenFHE library. The current (stable) version is v1.2.4 (released on March 21, 2025).
We will then provide a Solidity precompiled smart contract for simple FHE operations, such as addition, subtraction, finding the maximum, and others. The goal is to offer a minimal set of basic operations that can be used to support a wide variety of dApps.
For advances users, we can later consider providing low level access to the native FHE framework such as
- GitHub - zama-ai/concrete: Concrete: TFHE Compiler that converts python programs into FHE equivalent
Use cases for BITE phase 4.
Main use case for BITE phase 4 is banking, it also enables very secure games, voting and authentication
A) TFHE Confidential Token Wrapper
- Existing ERC-20 tokens can be wrapped into a TFHE confidential token wrapper, functioning as follows:
- Each account’s balance is stored in TFHE-encrypted form.
-
Transfers are performed using the encrypted balance of the sender, the encrypted balance of the recipient, and the encrypted amount to transfer.
- A TFHE circuit homomorphically updates the balances:
- Sender’s new balance = old encrypted balance minus encrypted amount.
- Recipient’s new balance = old encrypted balance plus encrypted amount.
- The entire computation is performed on encrypted data, without revealing balances or transfer amounts at any point.
- A TFHE circuit homomorphically updates the balances:
Thus, all user balances and transfer amounts are confidential, even to the smart contract itself.
B) On-Chain Bank
The TFHE token wrapper can serve as the foundational primitive for building a fully on-chain bank, replicating the functionality of a traditional Web2 banking system. In addition to confidential transfers, the following advanced operations can be supported through TFHE-encrypted math:
-
Credit Score Calculation:
- User transaction histories (encrypted balances, repayments, etc.) can be analyzed homomorphically to compute an encrypted credit score.
- The user can selectively reveal (decrypt) the credit score, or parts of it, to authorized decentralized lending protocols.
-
Confidential Savings Accounts:
- Savings and yield can accumulate directly on encrypted balances.
- Interest computations can be performed homomorphically without balance disclosure.
-
Confidential Loans and Repayments:
-
Borrowers can receive loans tied to their encrypted balances and repay them over time, with all amounts and obligations remaining confidential.
-
KYC-less Compliance:
- Compliance checks (such as transaction limits, suspicious activity monitoring) can be enforced on encrypted data without revealing private user information.
-
Confidential Payments and Payroll:
- Businesses could use encrypted tokens to pay employees, preserving the confidentiality of salaries on public blockchains.
C) On-Chain Fully Confidential Exchange
Once On-Chain Bank is Implemented, the next step is to implement a fully confidential exchange where users can use an AMM like Uniswap to exchange TFHE-wrapper tokens,
- All balances, swaps, and liquidity pools are confidential.
- The AMM runs fully encrypted
- Each liquidity pool holds two encrypted balances: Enc(balance_A) and Enc(balance_B).|
- User submits an encrypted token amount to swap (e.g., Enc(amount_A_in) to swap
- AMM applies must apply the AMM bonding curve pricing formuila homomorphically on encrypted values.
- After a swap, update Enc(balance_A) and Enc(balance_B) using TFHE math.
- LPs can provide or remove liquidity by encrypted operations, without revealing actual amounts.
D) Fully Private DAO Voting
While banking and DeFi are the primary focus of BITE Protocol Phase 4, the protocol also unlocks many other powerful applications beyond finance.
In fully private DAO voting:
- Users submit their votes in encrypted form.
- The total vote count is computed homomorphically (using TFHE) without revealing any individual user’s vote.
This ensures complete voter privacy while maintaining full transparency and integrity of the voting process.
E) Private Staking
- Users submit their staking delegations in encrypted form.
- The total stake delegated to each validator is computed without revealing individual user contributions.
- Staking rewards are distributed in encrypted format, hiding both the reward amounts and the recipient identities.
This enables decentralized staking mechanisms that protect user privacy at every step.
References:
[1] Ethereum Whitepaper: Ethereum Whitepaper
[2] B. Bünz et al., “Zether: Towards Privacy in a Smart Contract World,” 2019.
[3] Enigma: https://enigma.co/
[4] Secret Network: https://scrt.network/
[5] B. Bünz, J. Bootle, D. Boneh, “Zexe: Enabling Decentralized Private Computation,” 2019.
But there are some very legitimate use cases for it as well.
