Looking for a Developer to Test SAAX's Signed Agent-Commitment Flow

I'm building SAAX Protocol, an open standard that gives agent-to-agent purchases a signed, verifiable commitment record: what was agreed, who authorized it, what counts as fulfillment, and how disputes resolve. The hard problem is that a payment record alone does not describe every obligation. SAAX binds authorization, agreed terms, fulfillment evidence, recovery rules, and settlement references into one verifiable commitment.

What already works (and is publicly deployed)

The nonfinancial part of the flow is live on saax-protocol.com:

• Signed discovery - a provider profile at /.well-known/saax.json, signed with an Ed25519 JWS; clients confirm the provider key out-of-band before trusting it.
• Free preflight - POST /prepare-commitment returns a provider-signed, nonbinding proposal. No agreement, no funds, no reserved capacity.
• Buyer acceptance - POST /accept-commitment verifies a registered buyer's signed acceptance and durably records exactly one authenticated commitment. Identical retries return the same operation; reusing a single-use proposal with a new key is rejected.
• Independent verification - a separate-process verifier checks the export without application database access and returns VERIFIED or NOT VERIFIED against a pinned profile.

This first pilot does not move funds. No purchase, deposit, escrow funding, or paid participation. Real Base Sepolia escrow release and refund exist as a separate operator-run testnet demonstration with complete independent export verification, but that is testnet preview, not a public financial API, and not part of this pilot.

What I need from you

One developer (or a small handful) to act as the buyer in this flow:

1. Fetch and verify the signed discovery profile.
2. Request a free proposal (preflight) for a sample capability.
3. Sign a buyer acceptance with your own key and create one commitment.
4. Run the independent verifier on the resulting export.

I provide exact steps, the supported signing client and key type, and help with any step. Onboarding uses a verified public key and proof of control - you keep your own keys; I never ask for private keys, seed phrases, or credentials.

What I'm missing without you

Internal tests and operator-run demonstrations are not external adoption. I need a developer who has never touched SAAX to tell me:

• How long integration actually took (I will confirm an estimate during onboarding; I have no measured data yet).
• Which steps were confusing or undocumented.
• Whether verification results matched expectations.
• Any failure cases hit - especially retries, replay, or expired proposals.

I am the author building SAAX; all roles in existing demonstrations are operator-controlled, and I disclose that plainly. There is no compensation, guarantee, or implicit partnership in participating - it is a technical pilot for feedback.

How to join

• Comment on this post with a note that you are interested, or
• Email [e-mail] (the verified contact address on the site).

Verified documentation: status and maturity, integration guide with quickstart, versioned specification. I will reply to every interested developer.

Originally published on SAAX Protocol.