RFC: Extensibility of Constraint Vocabulary to Support Environmental Execution States (environment.market_state)

[LembaGang]

Overview

This RFC proposes registration of the environment.market_state constraint type in the Verifiable Intent constraint vocabulary. The constraint is placed in mandate.constraints[] and gates autonomous financial agent execution on a cryptographically signed, independently verifiable oracle receipt (Signed Market Attestation, SMA) at execution time — not at intent generation time.

Rationale

The existing Verifiable Intent constraint vocabulary covers authorization, financial caps, and asset selection. All current constraint types are evaluated at intent generation time and remain static for the life of the credential. Autonomous agents, however, execute asynchronously — long after the intent was generated. A cryptographically authorized order can still execute into:

• a closed exchange (after-hours)
• a circuit breaker halt (trading suspension)
• a settlement window (post-close processing period)

causing real financial harm regardless of authorization validity.

Without environmental attestation, an issuer cannot distinguish between an agent that executed correctly in a broken environment versus an agent that went rogue. This is a liability attribution problem for the issuer network, not merely a technical edge case.

Proposal

environment.market_state is a fail-closed constraint type. It requires a fresh SMA — a cryptographically signed, independently verifiable oracle receipt — to be fetched and verified at execution time before any action proceeds.

Constraint structure:

{
  "type": "environment.market_state",
  "exchange": "XNYS",
  "required_status": ["OPEN"],
  "oracle": {
    "endpoint": "https://headlessoracle.com/v5/status",
    "public_key": "03dc27993a2c90856cdeb45e228ac065f18f69f0933c917b2336c1e75712f178",
    "key_algorithm": "Ed25519",
    "max_receipt_age_seconds": 60
  }
}

If the oracle cannot produce a valid SMA, the agent MUST NOT proceed. The receipt_id from every successful verification provides issuers with dispute-grade evidence that the execution environment was valid at the exact moment of action.

Cryptographic Mechanics

The SMA receipt is signed with Ed25519. Verification is a deterministic, single-function operation executable in any environment with access to a Web Crypto API or equivalent:

1. Fetch receipt from oracle endpoint
2. Verify signature field against canonical payload (alphabetically sorted JSON fields, excluding signature)
3. Check expires_at against current time (MUST be in the future)
4. Check status field matches required_status
5. Log receipt_id for audit trail

If any step fails, the constraint fails and execution MUST halt.

Reference Implementation

• Oracle: headlessoracle.com — 23 exchanges, Ed25519, REST + MCP
• Verification SDK: @headlessoracle/verify — zero-dependency JS/TS, Web Crypto only
• SMA Protocol Spec: github.com/LembaGang/sma-protocol
• Agent Pre-Trade Safety Standard (APTS): github.com/LembaGang/agent-pretrade-safety-standard

The full RFC text is in spec/environment-market-state.md and includes: normative constraint schema, evaluation algorithm, multi-exchange composition rules, SMA receipt field reference, verification pseudocode, error taxonomy, security considerations (replay attacks, oracle compromise, clock skew), and IANA-style registration template.

---

This submission follows PR #9 from the same contributor.