Who gets paid?
The destination must be the one supplied by the trusted quote.
// Payment Guard · x402 conformance
Your agent pays.
Your terms stay.
Upcoming soon · Scanning & free tools
Check what a payment will authorize before your wallet signs it. The recipient, amount, token and network must match the trusted quote.
Solana + EVMLocal inspectionNo model key needed
01 / The mechanism
Follow the payment. See the checkpoint.
The trusted quote and the agent’s proposal meet only at the signing boundary. Change the proposal to see which path opens.
Two inputs / one enforced boundaryInteractive explanation
Kept in trusted host code
01 / Independent sourceMerchant’s HTTP 402 response
The host validates and stores the quote.
The agreed termsTrusted quote
The agent cannot rewrite this reference.- Recipient
- Merchant · 0x71…A2
- Amount
- 25.00 USDC
- Asset
- USDC · 0xA0…48
- Chain
- Ethereum · 1
Built in the agent’s context
02 / Proposed actionAgent reads and prepares
Pages, tool responses and invoice text can influence it.
Still unsignedProposed payment
Authority: one transfer- Recipient
- Other wallet · 0xE9…7C
- Amount
- 25.00 USDC
- Asset
- USDC · 0xA0…48
- Chain
- Ethereum · 1
03 / Sentry checksDecode → compare → decideDestination · amount · asset · chain · extra authority
ALLOWConnected signerMay sign the matching payment
REFUSESignature withheldA recognized mismatch stops here
ABSTAINSignature withheldUnreadable is not permission
The recipient changed. The connected wrapper stops before the wallet signs.
02 / The reason
A plausible payment can still be wrong.
An agent can read an invoice correctly and still construct a payment to another wallet. Checking the words alone misses the action that matters.
Sentry compares the supported transaction or authorization with payment terms kept outside the agent’s editable context. A mismatch stops the signing path.
Why the model cannot override the policy ↗03 / Anatomy of a payment
Change one thing. Watch the boundary.
These illustrative fixtures explain the comparison. They do not connect a wallet, run the SDK or send a payment.
FieldTrusted quoteAgent proposal
RecipientMerchant · 0x71…A2Other wallet · 0xE9…7C×
Amount25.00 USDC25.00 USDC✓
Token contractUSDC · 0xA0…48USDC · 0xA0…48✓
NetworkEthereum · 1Ethereum · 1✓
AuthorityOne transferOne transfer✓
REFUSESigner stopped
Same price. Wrong destination.
The proposed recipient differs from the trusted quote. The wrapper stops before asking the wallet to sign.
04 / The agreement
Four details. No silent substitutions.
How much?
The transfer must satisfy the supported quote’s amount constraints.
Which asset?
A familiar ticker is not enough. Check the actual asset identity.
Where?
The intended chain is part of the agreement, not an afterthought.
05 / At the signing boundary
Two ecosystems. The same discipline.
Solana
Inspect the transaction.
Decode supported serialized payment instructions before the wallet signs. Check transfers against the quote and refuse recognized extra authority.
Input
↓Serialized transactionDecode & compare
↓Instructions + accountsdestination / mint / amountallow → signerother → stop
guardSigner(wallet, getQuote)
Unsupported structures or unresolved accounts cannot receive an allow verdict.
EVM
Inspect the authorization.
Check supported EIP-712 / EIP-3009 authorizations, their domain and transfer fields. A payment quote does not authorize an unrelated allowance.
Input
↓Typed authorizationDecode & compare
↓Domain + transfer fieldsrecipient / asset / chain / valueallow → signerother → stop
guardEvmSigner(wallet, getQuote)
Coverage is format-specific. Arbitrary contract calls are not treated as verified payments.
AllowSupported and conforming.
The signer may proceed.
The signer may proceed.
RefuseA known violation.
The signer stops.
The signer stops.
AbstainUnable to establish conformance.
The signer also stops.
The signer also stops.
06 / Where x402 fits
The handshake is the start.
From resource request to resource accessSimplified successful path
Agent / hostPayment GuardMerchant service
01 · Request resource→Payment required
02 · Receive trusted terms←HTTP 402 + quote
03 · Prepare unsigned payment→Inspect against quote
04 · Connected wallet may sign←Allow only
05 · Submit payment proof→Verify / settle
06 · Receive the resource←Successful response
Simplified successful path. x402 defines the payment exchange; Sentry adds a local conformance boundary. Settlement and access still depend on the merchant, network and any facilitator. Protocol documentation
07 / Connect it
Put the check where signing happens.
Wrap the wallet used by the real payment flow. A check the agent can skip is only advice.
EVM · illustrative integration
import { guardEvmSigner } from '@sentry-local/guard/evm';
// The host provides the wallet and independently trusted quote.
const guardedWallet = guardEvmSigner(wallet, () => trustedQuote);
// Use this wrapper for the actual payment signing path.
await guardedWallet.signTypedData(paymentAuthorization);The host must supply wallet, trustedQuote and paymentAuthorization.
Protect the reference. Obtain and validate the quote in trusted host code. Never let an agent rewrite both sides of the comparison.
Keep the gate mandatory. Route the actual signing operation through the wrapper. An unknown payload, timeout or error must not grant permission.
08 / Know the scope
A precise check. A clear limit.
Payment conformance.
- Supported payload matches independently supplied terms.
- Recognized mismatches and extra authority are refused.
- Only allow proceeds through the connected signer wrapper.
Everything around it.
- That the merchant is honest or the asset is valuable.
- That funds are available or a payment has settled.
- That every wallet, chain or transaction format is supported.
Connect the signer SDK to your wallet to enforce the check before signing. Hosted billing uses the separately configured payment service.
09 / A few useful answers
Before you connect.
Do I need a NanoGPT API key?
No key is needed for the offline payment inspector. NanoGPT is used separately for optional text analysis on the Sentry backend; it does not decide whether mismatched payment terms are acceptable.
Does “allow” mean the payment is safe?
It means the supported payload conforms to the supplied quote under the configured checks. It does not establish merchant trust, sufficient funds or settlement. The host is responsible for trusting the quote.
What happens if a format is unknown?
The inspector abstains. The wrapper stops before signing. Add and validate support for the format; do not convert an unchecked result into permission.
Can I use a checker without a wallet wrapper?
Yes, for inspection and diagnostics. Enforcement requires the actual action path to reject non-allow results. A separate green badge cannot constrain another unwrapped signer.