Encrypted Pending Transactions

Encrypted pending transactions let you submit a transaction whose Move payload (entry function, arguments, and related executable data) is encrypted while the transaction is pending—for example while it is held in mempool and propagated between nodes. Validators decrypt the payload only when preparing execution after the block is confirmed. This reduces what observers can learn from the public pending transaction stream compared to a fully plaintext payload.

This feature is currently live on devnet, with testnet support coming soon and mainnet to follow. The fullnode you use must expose a ledger encryption_key when encrypted submission is enabled. On networks or nodes where the key is absent, the client cannot build encrypted transactions.

What clients can still observe

Encryption protects the payload bytes in transit and at rest in the pending phase, but a transaction is still a signed request to the chain. Depending on configuration and payload type, clients may still see metadata such as sender, gas parameters, expiration, signatures, and—where the protocol requires it—metadata derived from the payload (for example a claimed entry function for certain multisig or sponsored flows). Treat “encrypted pending” as payload privacy, not anonymity of the whole transaction. For the precise security model, see AIP-144: Encrypted Mempool and the underlying cryptography in eprint 2025/2032. At the protocol level this feature is called encrypted mempool (AIP-144); the names are interchangeable.

Cost

Encrypted transactions pay a minimum gas-unit price of 200 Octas/gas-unit, twice the network base minimum, to cover validator decryption work. SDKs enforce this floor at build time; servers reject encrypted submissions priced below it.

Signer restrictions

Keyless, federated keyless, and account abstraction accounts cannot sign encrypted transactions. The rule is enforced both client-side (where supported) and server-side.

Relationship to orderless transactions

You can combine encrypted payloads with orderless transactions so parallel submitters use replay-protection nonces while still encrypting the executable. See the TypeScript SDK page below for build options.

Not the same as confidential assets

Encrypted pending transactions protect the transaction payload for pending transactions on the way to execution. They are unrelated to confidential assets transactions, which allow for privacy of balances and amounts even after transactions are confirmed.

SDK support

TypeScript SDK — build with options.encrypted (senderAuthenticationKey is optional; SDK auto-fetches), submit encrypted builds.