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 live on devnet, testnet, and mainnet. 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 cost more than plaintext transactions. The extra cost covers validator decryption work and has two parts:

Higher minimum gas-unit price. Encrypted transactions pay a minimum gas-unit price of 200 Octas/gas-unit, twice the network base minimum. SDKs enforce this floor at build time; servers reject encrypted submissions priced below it.
Flat decryption charge. Each encrypted transaction is charged an extra 375 gas units on top of the gas its payload uses. If you set maxGasAmount yourself, leave room for this charge. Otherwise, the transaction is rejected during validation or runs out of gas.

As a rough guide, for a transaction without storage fees: if its plaintext version uses G gas units, the encrypted version costs about (G + 375) × max(gas_unit_price, 200) Octas. For example, a transfer that uses 150 gas units costs 15,000 Octas as plaintext at 100 Octas/gas-unit. Encrypted, it costs about (150 + 375) × 200 = 105,000 Octas (0.00105 APT). The flat charge matters most for small transactions.

Both values are governance-controlled parameters in the on-chain gas schedule (0x1::gas_schedule::GasScheduleV2): txn.encrypted_txn_min_price_per_gas_unit and txn.encrypted_txn_decryption.base. The second value is in internal gas units. Divide it by txn.gas_unit_scaling_factor to get gas units.

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.