Documentation Index
Fetch the complete documentation index at: https://docs.skale.space/llms.txt
Use this file to discover all available pages before exploring further.
Available on SKALE Base and SKALE Base Sepolia — Encrypted Transactions are available on SKALE Base Mainnet and Testnet.
Why Encrypted Transactions?
Public mempools leak your intent before your transaction executes. Bots monitor pending transactions and front-run, sandwich, or censor based on what they see. Encrypted Transactions solve this by hiding theto address and data fields during the mempool and consensus window — nothing is visible until after finality.
What Are Encrypted Transactions?
Encrypted Transactions hide a transaction’sto address and data fields during the mempool and consensus phases — before finality. Once decrypted and executed, details settle onchain normally like any other transaction.
The protection window is deliberate: inclusion (commit) happens before anyone can read the contents (reveal). This commit-then-reveal model prevents information leakage during the critical pre-execution phase without permanently hiding onchain activity.
Quick Example
How It Works
- Encrypt — Wallet encrypts the transaction payload using SKALE’s threshold public key
- Submit — Encrypted transaction is sent to the precompile (magic address)
- Finalize — Consensus finalizes the encrypted transaction without seeing contents
- Decrypt — After finality, the validator committee runs threshold decryption
- Execute — Decrypted transaction executes in the EVM
MEV Resistance
Encrypted Transactions are designed to prevent MEV at the source — by removing the information bots need during the window they exploit. Sinceto and data are ciphertext until after finality:
- No front-running — Intent is hidden until execution, so bots can’t insert themselves ahead of you
- No sandwich attacks — Swap parameters are invisible, so bots can’t bracket your trade
- No content-based censorship — Validators see only ciphertext, so they can’t pick which txs to include based on calldata
Use Cases
Encrypted Transactions are a good fit for single-shot protection — hiding transaction details during the mempool and consensus window. The data becomes visible onchain after execution. For persistent private state, see Conditional Transactions and Confidential Tokens.Anti-MEV Swaps and Trades
Hide swap parameters during mempool so bots can’t front-run or sandwich you:Confidential Contract Interactions
Keep function calls and parameters private during submission:NFT Mint Privacy
Hide mint metadata and recipient until the transaction lands:Need persistent privacy? Encrypted Transactions protect data during transit, not at rest. For onchain state that stays confidential — encrypted balances, sealed bids, private voting — use Conditional Transactions or Confidential Tokens.
Getting Started
- API Reference — TypeScript SDK and JSON-RPC methods
- Encrypted Transactions Cookbook — Step-by-step tutorials
