How Trustless Agent Agreements Actually Work

A deep dive into the oracle demo — what happened, why it matters, and how it applies to any service, not just price feeds.

The Problem This Solves

AI agents are everywhere — generating images, analyzing data, writing code, monitoring systems. But when one agent needs to hire another agent, everything breaks down. How does Agent A pay Agent B? How does Agent A know Agent B actually did the work? What happens when Agent B delivers garbage and demands payment anyway?

Today, the answer is: trust someone. Trust a platform. Trust an API provider. Trust a middleman to hold the money and decide who's right. That works until it doesn't — and it doesn't scale to millions of autonomous agents transacting without human oversight.

TXAI eliminates trust from agent-to-agent payments by replacing it with on-chain enforcement:

This isn't theoretical. The live demo mode executes real smart contract calls on TX testnet that you can verify on the explorer. The simulation mode uses live exchange prices with animated transaction flow. Here's what the demo demonstrates:

What You Just Saw

The oracle demo ran a complete trustless service agreement between AI agents — from contract formation to payment to delivery to dispute resolution to enforcement. Every step that would normally require lawyers, escrow services, or trust between strangers was handled by code on the TX blockchain.

Here's what happened in plain terms:

Why Does This Need a Jury?

This is the most common question, and it's the right one to ask.

The proof hash proves that something was delivered. It does not prove that what was delivered was correct.

Without a jury, you have two bad options:

The jury is the decentralized tiebreaker. It only activates when there's a dispute — which means the vast majority of transactions never involve a jury at all.

How the Jury Actually Works

Why Agent Juries Are Necessary — And Scalable

The most common pushback: "Why not just use an automated validator?" The answer is that automated validation only works for objective tasks. The moment you have subjective quality, ambiguity, or adversarial actors gaming deterministic rules, you need judgment — and that judgment needs to be decentralized.

The necessity argument

Consider a code audit agent. It submits a SHA-256 hash of a report. The hash proves a report exists. But did the report actually find the critical vulnerability? Did it just run a linter and call it done? No hash can answer that. A human-in-the-loop defeats the purpose of autonomous agents. A centralized arbiter creates a single point of failure — and a target for bribery.

Agent juries solve this because:

• Distributed knowledge — 6 jurors are harder to fool than 1 arbiter
• Economic alignment — jurors lose real money for wrong votes, so they have incentive to evaluate carefully
• No central target — you can't bribe a jury you can't predict. Jurors are selected from a staked pool per-dispute
• Self-correcting — bad jurors lose stake and get priced out. Good jurors accumulate rewards and reputation

The scalability argument

Juries sound expensive. They're not. Here's why:

The economic flywheel

The production design allocates a small percentage of each escrow transaction to the jury pool. Illustrative projections as volume grows:

At scale, being a TXAI juror becomes a meaningful income stream — which attracts better jurors, which produces better verdicts, which builds more trust in the protocol, which drives more transaction volume. The jury isn't a cost center. It's a growth engine.

This Isn't Just for Oracles

The oracle demo shows price feeds because they're easy to visualize. But the protocol doesn't care what the service is. The escrow contract enforces the agreement structure — payment, delivery window, proof, dispute — regardless of what's being delivered.

Swap "price oracle" for any of these:

The pattern is always the same:

Any service that an AI agent can perform can be paid for, verified, and enforced through this protocol. The memo is the API call. The escrow is the guarantee. The jury is the fallback. The blockchain is the enforcement layer.

What Makes This Different

The Numbers from the Demo

Every price shown in the demo was fetched live from real exchange APIs at the moment you clicked "Run." CoinGecko, Kraken, MEXC, Gate.io, and Uphold all returned real TX/USD market data. BitMart is intentionally forced to deliver the wrong pair (BONK/USD instead of TX/USD) so the demo always triggers a clawback — proving that trustless enforcement works end-to-end, every time. Its trust score dropped from 72 to 14, suspending it from future agreements.

What's Live vs. What's Next

We believe in building in public and being transparent about where things stand. Here's exactly what the demo does today on the smart contract, and what's coming next.

✓ What's live on-chain right now

When you click "Run Live Demo," these are real transactions on TX testnet — every one verifiable on the explorer:

The escrow contract (CosmWasm, Code ID 3466 on testnet, 589 on mainnet) enforces the full lifecycle: lock funds → verify delivery → handle disputes → enforce verdict. This is not simulated. These are real state changes on a real blockchain.

⚡ What the demo illustrates (not yet on-chain)

The jury voting animation — where 5 oracles each cast a vote — demonstrates the concept of decentralized dispute resolution. In the current contract, ResolveDispute is called by the contract owner, which means the verdict is a single transaction, not 5 independent juror votes.

Here's what the demo shows vs. what actually happens on-chain:

The upgrade path

The Smart Contract — Message Interface

This is the actual Rust interface for the TXAI payment escrow contract deployed on TX blockchain (Code ID 3466 on testnet, 589 on mainnet). This is what the demo executes — every CreateAgreement, ConfirmDelivery, RaiseDispute, and ResolveDispute call you saw is a real invocation of this contract.

This is the message interface only — the API surface. The business logic (how funds move, how timing is enforced, how disputes are evaluated) lives in the contract implementation.

// ─── INSTANTIATE ────────────────────────────────────────────

pub struct InstantiateMsg {
    /// Contract owner — can resolve disputes, default jury
    pub owner: String,
    /// Default delivery window in seconds
    pub default_delivery_window: u64,
    /// Optional jury contract address for dispute resolution
    pub jury_contract: Option<String>,
}

// ─── EXECUTE ────────────────────────────────────────────────

pub enum ExecuteMsg {
    /// Payer sends funds with this message — the payment IS the request.
    CreateAgreement {
        provider: String,
        delivery_window_secs: Option<u64>,
        memo: String,          // TXAI:v1:action:params
    },

    /// Provider marks delivery with a proof hash.
    ConfirmDelivery {
        agreement_id: u64,
        proof_hash: String,    // SHA-256, IPFS CID, or attestation URI
    },

    /// Payer claws back on non-delivery. BLOCKED during delivery window.
    Clawback { agreement_id: u64 },

    /// Either party raises a dispute. Pauses delivery window.
    RaiseDispute {
        agreement_id: u64,
        reason: String,
    },

    /// Resolve a dispute — only callable by owner or jury contract.
    ResolveDispute {
        agreement_id: u64,
        verdict: DisputeVerdict,  // Delivered → pay provider. NotDelivered → clawback.
    },

    /// Jury-authorized force clawback — bypasses delivery window.
    ForceClawback { agreement_id: u64 },
}

pub enum DisputeVerdict {
    Delivered,
    NotDelivered,
}

// ─── QUERY ──────────────────────────────────────────────────

pub enum QueryMsg {
    GetAgreement { agreement_id: u64 },
    ListAgreements { payer: Option<String>, provider: Option<String> },
    GetStats {},
}

// ─── RESPONSES ──────────────────────────────────────────────

pub struct AgreementResponse {
    pub id: u64,
    pub payer: String,
    pub provider: String,
    pub amount: Uint128,
    pub denom: String,
    pub status: String,
    pub memo: String,
    pub proof_hash: Option<String>,
    pub created_at: u64,
    pub delivery_window: u64,
    pub window_expires_at: u64,
    pub delivered_at: Option<u64>,
    pub disputed_at: Option<u64>,
}

Notice the jury_contract: Option<String> field in InstantiateMsg. That's the plug-in point. When the jury contract module is deployed, it gets passed here — and the escrow contract will accept ResolveDispute calls from it alongside the owner. No upgrade needed to the escrow contract itself.

Two Resolution Paths — Both Trustless

The oracle demo includes a resolution mode toggle: ⚡ Auto-Verify and ⚖ Peer Review. Both paths are designed to be trustless — no human in the loop, no centralized arbiter. The difference is what evaluates delivery.

In the oracle demo, you can toggle between modes before running. In Auto mode, when BitMart delivers BONK/USD instead of TX/USD, the contract detects the mismatch immediately — auto-clawback, done. In Jury mode, the same mismatch triggers a full dispute: 5 peer oracles vote, quorum reached, verdict executed. Same outcome, different path. We include the jury path in the demo specifically to stress-test the contract's complete dispute pipeline.

Why This Demo Matters

Every agent framework today solves communication. None of them solve payment with guarantees. That's the gap — and it's the reason autonomous agent economies don't exist yet.

This demo closes that gap. In 70 seconds on a real blockchain, you watched:

• 6 agents hired — with nothing but a transaction and a memo. No accounts, no API keys, no platform.
• 5 agents paid automatically — they delivered, the contract verified, funds released. Zero friction.
• 1 bad actor caught and punished — wrong data detected, dispute raised, jury voted, funds clawed back, trust score destroyed. All autonomous.
• Every step verifiable — click any transaction hash and see it on the blockchain. Not a demo. Not a mockup. Real state changes on a real chain.

The secret sauce isn't any single piece — it's the combination. The memo protocol turns a payment into an API call. The escrow contract holds funds until delivery is proven. The jury system resolves disputes without a centralized arbiter. The trust score makes consequences permanent. And TX's native clawback enforces it all at the protocol level — not in a smart contract that could have bugs.

TXAI Protocol — Built on TX Blockchain · solomentelabs.com