An AI agent proposes a WETH → USDC swap. Before execution, it may see an oracle reference price and a simulated route quote. After execution, it can observe the actual fill.
Those are three different numbers backed by three different kinds of evidence. Treating them as interchangeable can hide a bad route, an overbroad authorization, or an unexpected execution result.
1. Oracle reference: the comparison point
An independent oracle assessment answers a question about market data: what reference price and risk signals were available for WETH and USDC at that time?
It gives the agent a basis for reviewing a proposed trade. It does not say that a particular router will deliver that price.
2. Simulated quote: this call at this block
A route quote needs to be tied to the transaction the agent actually intends to submit: chain, sender, router, calldata, token amounts, recipient, minimum output, and deadline.
Insight's assessV3Swap() reviews a prepared Uniswap V3 exactInputSingle call against two signed pre-trade oracle assessments. It checks the router's reviewed runtime code hash, decodes the call, and simulates it from the intended sender at one RPC block. It then compares the simulated output with the oracle reference and the transaction's minimum output.
A simplified integration looks like this:
import { InsightGuard } from 'oracle-insight-guard';
const guard = new InsightGuard({
apiKey: process.env.INSIGHT_API_KEY!,
});
const { transactionRisk } = await guard.assessV3Swap({
source: {
asset: 'WETH',
destinationAsset: 'USDC',
chainId: 1,
action: 'swap',
tradeAmountUsd: 1000,
},
destination: {
asset: 'USDC',
destinationAsset: 'WETH',
chainId: 1,
action: 'swap',
tradeAmountUsd: 1000,
},
receipt: { settlementChainId: 1 },
transaction: preparedExactCall,
routerCodeHash: reviewedRouterCodeHash,
reader: publicClient,
});
if (transactionRisk.status !== 'ACCEPTABLE') {
throw new Error(
`${transactionRisk.status}: ${transactionRisk.reasonCodes.join(', ')}`
);
}
Here, preparedExactCall and publicClient come from the integration. The expected router code hash must come from an independently reviewed deployment configuration, not from the agent proposing the trade. The USD amount is illustrative; a real integration must use the intended trade scope.
The result has three possible statuses:
-
ACCEPTABLE: the exact call met the configured policy at the observed block. -
RISK_REJECTED: available evidence showed a policy or minimum-output failure. -
UNASSESSABLE: required evidence was missing or could not be checked. This is never approval.
The transaction review is local, unsigned SDK output. The signed Insight proofs cover the oracle assessment; they do not turn an RPC simulation into a guaranteed future fill.
3. Actual fill: what happened after submission
The simulated quote describes one block. Between review and inclusion, pool state can change. A post-trade check therefore needs the observed transaction, receipt, relevant token movements, and the finality level appropriate to the application.
Compare the actual input and output with the authorized call and the earlier evidence. Preserve the original review even if the transaction fails, is reorganized, or remains uncertain. A transaction hash by itself is not a complete account of the fill.
Where authorization fits
Price review and permission review answer different questions. If PriorSeal is used alongside Insight, it can bind user or organizational authorization to the exact call and produce evidence relating authorization to observed EVM execution. It does not make the oracle price correct or guarantee the output amount.
The operational rule is simple: review the prepared call immediately before authorization, authorize that exact call, and examine the observed result afterward. If calldata changes or evidence expires, review again.
The current assessV3Swap() adapter covers the original Uniswap V3 SwapRouter exactInputSingle path described in the documentation. Other routers need separately reviewed adapters.
Technical references:
Top comments (0)