# Financial action checks

The payment/payout profile connects an agent’s instruction to execution evidence on a supported EVM network. It evaluates the specified action—not investment quality, profitability, or a provider’s general trustworthiness.

## Bind intent to execution

The instruction identifies the operation, network, exact token contract, recipient, integer amount, timing, policy version, and finality threshold. Authenticated request evidence is preserved where available; a caller-supplied instruction alone does not establish owner authorization.

Resolve the observed transaction and its result. Verify only supported transfer patterns and token semantics. Proxies, fee-on-transfer tokens, rebasing, intermediate routers, internal calls, and ambiguous event interpretations require specific handling, not a blanket event-log match.

## Report each predicate

Check the expected context, chain, asset, recipient, amount, success state, applicable timing evidence, and finality condition. When a condition cannot be established, return INDETERMINATE with the missing evidence. A changed block association must invalidate or refresh dependent observations.

The x402 payment for hiring an execution service is separate from the payout the service was hired to perform. The first cannot stand in for the second.

## Where the value lies

Proof21’s evidence model links the instruction, service interaction, execution result, and supporting records. The receiving platform can identify the exact mismatch instead of reconciling disconnected transaction and service logs.

Existing smart contracts may already enforce minimum amounts or price limits. Do not sell the same enforced predicate as a new security property. A later swap profile must specify the supported router and order semantics; incomplete venue data cannot prove global best execution or profitability.

<!-- p21-enforcement-v10 -->

## Bind authorization to the exact action

For an execution-gated profile, the preflight finding is not enough. P21 produces or verifies an action-bound authorization whose `actionDigest` commits to the profile-defined canonical action. Depending on the execution adapter, that may cover a Bitcoin transaction/PSBT, EVM transaction or UserOperation, or a canonical API request.

Immediately before signing or invocation, the gate recomputes the actual action digest and checks the bound request, policy, network, asset, recipient/amount where applicable, nonce and expiry. A valid proof for transaction A never authorizes substituted transaction B. A stale authorization fails closed until its state-dependent predicates are refreshed.

Post-execution settlement remains independent of the receiver's later decision. A receiver may reject a confirmed transaction under its own policy, but it cannot convert confirmed settlement into non-settlement.