Skip to main content

Protect Transactions With the IntentGuard RPC

Submitting a transaction onchain creates an Execution Gap between the outcome shown at signing and the outcome that lands at inclusion. During this gap, the transaction's outcome is not enforceable.

The Execution Gap exposes users to two classes of risk:

  • Security risks — address poisoning seeded into wallet history, and compromised dapp frontends that swap the recipient or contract at signing.
  • Financial risks — MEV extraction, slippage from liquidity changes, sandwich attacks, and adverse state drift between simulation and execution.

IntentGuard closes the Execution Gap. Users declare the outcome conditions a transaction must satisfy before it is included onchain.

How it works

Step 1
Interact with the dapp of your choice
Use your wallet as you normally would. Sign the transaction the dapp asks for.
Step 2
The IntentGuard RPC holds your transaction
The signed transaction is held privately by the IntentGuard RPC, awaiting a matching Protection Transaction. It is not propagated to the public mempool.
Step 3
Set up protection
Open protect.intentguard.xyz and define the conditions the transaction must satisfy. If they match at execution, both transactions land onchain. If not, neither is included.

Prerequisites

A wallet that supports custom RPCs (MetaMask, Rabby, Frame), with the IntentGuard RPC added for the network in use.

Mainnet
https://rpc.intentguard.xyz/2-step-submission
Chain ID 1
Sepolia
https://sepolia.rpc.intentguard.xyz/2-step-submission
Chain ID 11155111

If the wallet does not support wallet_addEthereumChain, add the URL above as a custom RPC using the chain ID shown.


Step 1 — Submit the transaction through the IntentGuard RPC

Submit the transaction through the IntentGuard RPC the same way as with any standard provider. The IntentGuard RPC keeps the signed transaction private and does not propagate it to the public mempool. The transaction remains pending until a matching Protection Transaction is received and its constraints are validated.

Step 2 — Generate the Protection Transaction

Open the Protection app and define the outcome constraints the original transaction must satisfy. Constraints include expected outflows, inflows, and net balance changes. Sign and submit the Protection Transaction from the same wallet used for the original transaction.

The IntentGuard RPC includes the original transaction in a block only if its execution satisfies the declared constraints. If validation fails, neither transaction is included.

Protection is applied per transaction.


Failed protection costs no gas

If the Protection Transaction's constraints are not satisfied, neither transaction is included in a block. No state changes occur, no gas is consumed, and the nonce remains available for the next transaction.


Enforcer contract

NetworkAddress
Mainnet0xb96b183761008e5bbbdf03600631c7c2cbc16b2e
Sepolia0x66e15884225b3f70fe09d5ee4718c34ca0ab27e4

Mainnet is the production deployment. Sepolia is testnet.


Summary

Transactions signed through the IntentGuard RPC are held privately until matched with a Protection Transaction. If execution does not satisfy the declared constraints, the transaction is excluded from inclusion. No state changes occur, no gas is consumed, and the nonce remains available. Protection is applied per transaction.