MEV Shield
SecurityPost-quantum encrypted transaction submission that protects against front-running and sandwich attacks via ML-KEM-768 and XChaCha20-Poly1305.
MEV Shield Transaction Flow
MEV Shield Encrypted Transaction Flow
Key Pair
next_key
NextKey
Inner Tx
encrypted
Submission
Commitment
Click items to navigate to their reference pages.
The Big Picture
MEV (Miner/Maximal Extractable Value) is profit that block producers can extract by reordering or front-running transactions. On Bittensor, this is especially dangerous for staking swaps and Alpha pool operations where large TAO movements are visible in the mempool. MEV Shield eliminates this attack surface by encrypting transactions so block producers cannot see their contents before committing to a block ordering. The post-quantum cryptographic scheme (ML-KEM-768) ensures the protection remains secure even against future quantum computers.
Why This Matters
MEV attacks cost DeFi users billions. When you submit a large swap in the open, bots can see it, buy ahead of you (driving up price), then sell after you buy (profiting from your trade). Encrypting your transaction means nobody can see what you're doing until it's too late to front-run.
Example Scenario
Alice wants to swap 500 TAO for Alpha on subnet 12. Without MEV Shield, a bot sees her pending transaction, buys Alpha first (raising the price), then sells after Alice's trade executes — extracting value from Alice. With MEV Shield, Alice encrypts her swap with the next block author's public key. The bot sees only ciphertext and cannot determine what Alice is doing. The block author decrypts and executes the swap honestly because they committed to their key before seeing Alice's submission.
Common Questions
- What is the nonce trap and how do I avoid it?
- The outer submit_encrypted call uses nonce N, but the inner transaction must use nonce N+1 (since the outer call increments the account nonce). Query system.account for the current nonce N, sign the inner extrinsic with nonce N+1, then sign submit_encrypted with nonce N.
- Why ML-KEM instead of classical RSA or ECDH?
- ML-KEM-768 (FIPS 203) is a post-quantum key encapsulation mechanism resistant to attacks from quantum computers. Since encrypted transactions may have long-term value (the ciphertext is stored on-chain), using post-quantum cryptography provides future-proof security.
- Can I use MEV Shield with hotkey-signed transactions?
- No. Both the outer submit_encrypted call and the inner transaction must be signed by a coldkey. The official Bittensor documentation warns that using MEV Shield with hotkey-signed transactions "may result in unintended consequences that could result in asset loss."
- What if a validator refuses to announce a key or decrypt submissions?
- MEV Shield is opt-in for validators. If no validator announces a key, NextKey is None and MEV protection isn't available for that block. If the block author cannot decrypt a submission, they call mark_decryption_failed and the DecryptionFailed event is emitted. The inner transaction does not execute in this case.
Use Cases
- Protecting large staking swaps from front-running bots
- Securing Alpha pool operations on dTAO subnets
- Private validator stake movements
- Preventing sandwich attacks on TAO/Alpha conversions
- Any coldkey-signed transaction where mempool privacy is desired
MEV Shield implements an encrypted mempool for Subtensor. Users encrypt their transaction using a public key announced by the next block author, then submit the ciphertext on-chain. The block author decrypts and executes the transaction during block production. Because the key was announced before the encrypted submission was seen, the block author cannot selectively front-run or reorder transactions based on their content.
The key lifecycle works as follows: a validator calls announce_next_key to publish their ML-KEM-768 public key, which is stored in NextKey. At the next block boundary, NextKey auto-rotates into CurrentKey. Users read NextKey for encryption, call submit_encrypted with the ciphertext and a commitment hash, and the submission is queued in Submissions storage. The block author decrypts using the private key matching CurrentKey, verifies the commitment, and executes or rejects the inner transaction.
The cryptographic scheme combines ML-KEM-768 (FIPS 203, post-quantum key encapsulation) for key agreement with XChaCha20-Poly1305 (authenticated encryption with a 24-byte nonce) for payload confidentiality and integrity. The ciphertext format is: [u16 kem_len] || kem_ciphertext || nonce24 || aead_ciphertext.
Triggers
- User wants MEV protection for a sensitive transaction (staking swap, Alpha pool operation)
- Validator announces a new encryption key for upcoming block production
- Block author processes encrypted submissions during block construction
Inputs (6)
| Item | Type | Role |
|---|---|---|
| announce_next_key MevShield | call | Validator publishes ML-KEM-768 public key for next block |
| submit_encrypted MevShield | call | User submits encrypted transaction with commitment hash |
| mark_decryption_failed MevShield | call | Block author reports decryption failure for a submission |
| NextKey MevShield | storage | Public key users should read for encrypting new submissions |
| CurrentKey MevShield | storage | Decryption-side key — block author holds matching private key |
| Submissions MevShield | storage | Queue of encrypted submissions awaiting decryption by block author |
Outputs (13)
| Item | Type | Role |
|---|---|---|
| EncryptedSubmitted MevShield | event | Emitted when an encrypted transaction is accepted into the queue |
| DecryptedExecuted MevShield | event | Emitted when inner transaction is successfully decrypted and executed |
| DecryptedRejected MevShield | event | Emitted when inner transaction decrypts and verifies but fails during dispatch (includes DispatchErrorWithPostInfo) |
| DecryptionFailed MevShield | event | Emitted when block author cannot decrypt a submission |
| NextKey MevShield | storage | Updated when validator announces a new key via announce_next_key |
| KeyHashByBlock MevShield | storage | Hash of CurrentKey per block, used to bind key_hash to the epoch at submit time |
| SubmissionAlreadyExists MevShield | error | A submission with the same ID already exists in Submissions |
| MissingSubmission MevShield | error | The referenced submission ID does not exist in Submissions |
| CommitmentMismatch MevShield | error | Recomputed commitment does not match stored commitment (thrown during block processing inherent, not by user-callable dispatchables) |
| SignatureInvalid MevShield | error | Inner extrinsic signature verification failed (thrown during block processing inherent, not by user-callable dispatchables) |
| BadPublicKeyLen MevShield | error | Announced ML-KEM public key length is invalid |
| KeyExpired MevShield | error | The MEV Shield key epoch for this submission has expired |
| KeyHashMismatch MevShield | error | Provided key_hash does not match the expected epoch key hash |
Source Files
pallets/shield/src/lib.rs