# The Composable Pre-Trade Verification Pattern for Autonomous Trading Agents

**Version**: 2.0 | **Status**: Draft | **License**: Apache 2.0

## Abstract

Autonomous trading agents need layered verification before executing trades. This document describes a composable pre-trade verification pattern — a deployment pattern in which specific execution-environment constraints (Verifiable Intent environment.* family) and adjacent authorization, signal, and payment verification steps compose into a gating sequence that must pass before any financial transaction executes.

This is a deployment pattern, not a protocol. The normative specifications are published separately: `environment.market_state` and `environment.wallet_state` in the Verifiable Intent environment.* family, and vendor-specific protocols referenced below.

## The Pattern

```
┌─────────────────────────────────────────────────┐
│  5. Trade Execution                             │
│  └─ Order submission with full proof chain      │
├─────────────────────────────────────────────────┤
│  4. Payment                                     │
│  └─ e.g. x402, on-chain USDC with tx proof      │
├─────────────────────────────────────────────────┤
│  3. Signal Verification                         │
│  └─ e.g. claim verification against live data   │
├─────────────────────────────────────────────────┤
│  2. Spend Authorization                         │
│  └─ e.g. policy-bound, human-in-loop auth       │
├─────────────────────────────────────────────────┤
│  1. Execution-Environment Verification          │
│  └─ environment.market_state (this step)        │
│     environment.wallet_state (composable)       │
└─────────────────────────────────────────────────┘
```

Each step's proof composes into the next. If any step fails, subsequent steps are skipped and the trade is halted.

## Step 1 — Execution-Environment Verification

**Specification:** Verifiable Intent environment.* family. Normative specifications for `environment.market_state` ([PR #9](https://github.com/agent-intent/verifiable-intent/pull/9)) and `environment.wallet_state` ([PR #22](https://github.com/agent-intent/verifiable-intent/pull/22)), both in coordinated drafting on the upstream `agent-intent/verifiable-intent` repository.

**Question:** Is the execution environment in an expected state? Is the venue open? Is the wallet solvent and uncompromised?

**Protocol:** Cryptographically signed constraint attestations with finite TTL, fail-closed semantics, composable via conjunction.

**Reference implementation of environment.market_state:** [Headless Oracle](https://headlessoracle.com). 28 venues, Ed25519 signing, 60-second TTL.

## Step 2 — Spend Authorization

**Question:** Is the agent authorized to commit this amount of capital?

**Example protocols:** Policy-bound authorization frameworks such as Ampersend.

## Step 3 — Signal Verification

**Question:** Is the trading signal factually accurate?

**Example protocols:** Claim-verification services such as VeroQ.

## Step 4 — Payment

**Question:** Can payment execute with cryptographic proof?

**Example protocols:** x402 (HTTP 402 with on-chain USDC on Base).

## Step 5 — Trade Execution

Submit the order with all prior-step proofs attached for audit.

## Why Step 1 Must Be Fail-Closed

1. Execution-environment state (venue open/closed, wallet solvent/not) is objective — attestable as fact, not judgment.
2. All subsequent steps depend on it.
3. Fail-closed bounds the worst outcome to opportunity cost rather than capital loss.
4. Finite TTL on the environment attestation forces re-verification before every execution window.

## Relationship to Other Specifications

This pattern references — it does not redefine — the following normative specifications:

| Concern | Specification | Status |
|---|---|---|
| `environment.market_state` | Verifiable Intent environment.* family, [PR #9](https://github.com/agent-intent/verifiable-intent/pull/9) | Coordinated drafting |
| `environment.wallet_state` | Verifiable Intent environment.* family, [PR #22](https://github.com/agent-intent/verifiable-intent/pull/22) | Coordinated drafting |
| x402 payments | [x402.org](https://www.x402.org/) | Linux Foundation, live |
| Spend authorization | Vendor-specific (e.g. Ampersend) | Integration examples |
| Signal verification | Vendor-specific (e.g. VeroQ) | Integration examples |

## Changelog

| Version | Date | Changes |
|---------|------|---------|
| 2.0 | 2026-04-22 | Repositioned from "named 4-layer stack" to "composable deployment pattern". Step 1 now references `environment.market_state` in the Verifiable Intent environment.* family as the normative specification. Vendor-specific integrations (Ampersend, VeroQ) demoted to example protocols. |
| 1.0 | 2026-03 | Initial draft. |

## Machine-Readable Discovery

JSON: `GET https://headlessoracle.com/v5/pre-trade-stack`