What ArbiSim checks
ArbiSim runs 10 independent safety checks on every transaction. Any single check can block execution. Here is exactly what each one means, in plain English.
Transaction would fail
dangerThe transaction would be rejected by the blockchain.
Simulating the transaction caused it to revert — the smart contract rejected it mid-execution. This could be due to insufficient balance, wrong parameters, contract logic conditions, or a protocol state change. If sent for real, it would consume gas but accomplish nothing.
Example
Trying to withdraw more than your deposited balance from a lending protocol.
Price impact too high
warningThe trade moves the market price more than your acceptable limit.
In automated market makers (AMMs), large trades shift the price. If your trade is too big relative to the available liquidity, you will receive significantly fewer tokens than the quoted price suggests. ArbiSim compares the simulated output against the current price and rejects if it exceeds your max_slippage_tolerance.
Example
Swapping $50,000 of AVAX for USDC in a pool with $200,000 total liquidity — the price would move ~25%.
ReferenceUniswap V2 price impact math ↗
Someone is front-running you
dangerAnother transaction in the same block is positioned to exploit yours.
MEV (Maximal Extractable Value) bots monitor the mempool for profitable transactions. When they see a large swap, they insert their own trade before yours to profit from the price movement you create. ArbiSim detects this sandwich pattern by simulating the block state and checking for suspicious surrounding transactions.
Example
A bot buys AVAX before your large buy, then sells after you move the price.
ReferenceMEV documentation ↗
Risky token permission
warningYou are giving a contract more spending permission than this transaction requires.
ERC-20 approvals give a contract permission to spend your tokens up to a maximum amount. Many protocols request unlimited approvals for convenience, but this creates a risk: if that contract is exploited later, attackers can drain your full balance. ArbiSim flags when your approval amount significantly exceeds what the transaction actually needs.
Example
Approving a DEX for MAX_UINT256 tokens when you only need to swap 10 AVAX.
ReferenceEIP-20 allowance ↗
Signature check failed
dangerThe cryptographic signature for this transaction is wrong.
For smart account transactions (ERC-4337 UserOps), the bundler validates your signature before including the transaction. If the signature is invalid — wrong key, expired session, or tampered data — the transaction will be rejected immediately without executing. ArbiSim calls simulateValidation on the EntryPoint contract to catch this.
Example
A session key that was revoked is signing a new transaction.
ReferenceERC-4337 ↗
Permission has expired
dangerThe time-limited authorization for this action is past its deadline.
Some transaction authorization schemes include a time window. If the current block timestamp is past the validUntil time embedded in the transaction, it will be rejected. This is common with session keys in smart accounts.
Example
A trading session key set to expire at midnight is used at 12:05 AM.
ReferenceERC-4337 validity range ↗
Use the priority lane
warningYou could protect this transaction by paying a small speed fee.
Arbitrum One has a feature called Timeboost — a priority lane that gives transactions a 200ms advantage over the standard queue. In competitive scenarios (like token launches or liquidations), this advantage can mean the difference between your transaction succeeding and being beaten by a faster bot. ArbiSim calculates whether the extra fee is worth paying.
Example
Claiming a yield farming reward where bots compete to be first.
ReferenceTimeboost ↗
Smart contract hit its compute limit
dangerThe contract would run out of compute budget mid-execution.
Arbitrum Stylus allows smart contracts written in Rust, C, or C++ that compile to WebAssembly. These contracts use an "ink" compute budget rather than gas. If your transaction calls a Stylus contract that would exceed its ink limit, it runs out of budget mid-execution and fails — similar to running out of gas in a regular contract.
Example
Calling a complex Stylus DeFi contract with a transaction that triggers deep recursive logic.
ReferenceArbitrum Stylus ↗
Untrusted counterparty
dangerThe address you are interacting with has a low or unknown trust score.
ERC-8004 defines an on-chain reputation system for AI agents. ArbiSim checks the destination address against this registry. A low score (below 50/100) or an unregistered address means the counterparty has not established a verifiable history of safe interactions. This is particularly important for agent-to-agent payment flows.
Example
An AI agent receiving a payment has no on-chain reputation history.
ReferenceERC-8004 Agent Reputation ↗
Payment destination unknown
dangerYou are sending a payment to an unverified recipient.
The x402 payment protocol enables machine-to-machine payments where AI agents pay for services. ArbiSim checks both the reputation of the recipient and whether the payment amount is proportional to what was agreed. This flag fires when the recipient address has no verifiable track record in agent payment flows.
Example
An agent receiving payment for an API service has no previous transactions recorded.
Referencex402 Payment Protocol ↗