Skip to content

Instantly share code, notes, and snippets.

@jeremylongshore

jeremylongshore/gist-irsb-showcase.md

Created March 6, 2026 23:51
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save jeremylongshore/744eeda33958618cd1704650505abb3e to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save jeremylongshore/744eeda33958618cd1704650505abb3e to your computer and use it in GitHub Desktop.
Download ZIP
IRSB Ecosystem — Full Technical Showcase + AppAudit (for Dolt team / Steve Yegge)
Raw
gist-irsb-showcase.md

IRSB Ecosystem — Full Technical Showcase + AppAudit

Executive Summary

Intent Receipts & Solver Bonds (IRSB) is Ethereum's accountability layer for intent-based transactions and AI agent guardrails.

One-liner: Intents need receipts. Solvers need skin in the game.

ERC-7683 standardizes the intent format—the what and how—but it doesn't answer the critical question: what happens when the solver fails? IRSB fills that gap with an on-chain dispute and slashing framework that provides execution accountability across heterogeneous solvers and protocols.

Today's intent ecosystems (UniswapX, CoW Protocol, 1inch Fusion) manage solver reputation internally. IRSB makes accountability portable, verifiable, and composable—independent of any single protocol. A solver builds reputation across all intent-based systems. A user can audit intent execution by posting receipts and challenging incorrect outcomes. Solvers must post bonds proportional to transaction volume, ensuring they have skin in the game.

This document covers the full technical stack: 35 contracts across execution, receipts, disputes, delegation, and identity; 4 production services (Solver, Watchtower, Agents, Indexer); 6 emerging EIP standards; and 1000+ tests spanning Foundry, TypeScript, Python, and HyperIndex.

Architecture Overview

IRSB is a 4-layer stack sitting on top of ERC-7683 intent infrastructure:

┌─────────────────────────────────────────────────────────────────┐
│                    Layer 4: Identity & Standards                 │
│  ERC-8004 Agent Registry | ERC-7710 Redemption | x402 Payments  │
├─────────────────────────────────────────────────────────────────┤
│                  Layer 3: Intent Execution & Control              │
│  EIP-7702 Delegation | Caveats | WalletDelegate | Enforcers      │
├─────────────────────────────────────────────────────────────────┤
│              Layer 2: Receipts, Disputes, Slashing                │
│  IntentReceiptHub | DisputeModule | SolverRegistry | Watchtower  │
├─────────────────────────────────────────────────────────────────┤
│                Layer 1: Core Contracts & Standards                │
│  ERC-7683 IntentEnvelope | Bond Mechanics | Challenge Windows    │
└─────────────────────────────────────────────────────────────────┘

Data Flow:

User submits intent
    ↓
Solver observes & executes (posts receipt)
    ↓
Watchtower indexes receipt, validates constraints
    ↓
Challenge window (1 hour) opens
    ↓
If dispute: DisputeModule arbitrates with evidence
    ↓
Bonds slashed proportional to fault, reputation decayed
    ↓
Receipt finalized or overturned, solver reputation updated

Deployed Contracts (11 on Sepolia)

Sepolia Deployment Summary

Contract Address Etherscan Role
SolverRegistry 0xB6ab964832808E49635fF82D1996D6a888ecB745 view Solver lifecycle, bonding, slashing, reputation
IntentReceiptHub 0xD66A1e880AA3939CA066a9EA1dD37ad3d01D977c view Receipt posting, disputes, finalization
DisputeModule 0x144DfEcB57B08471e2A75E78fc0d2A74A89DB79D view Arbitration, evidence, escalation
WalletDelegate 0x6e7262bA8eE3e722aD5f83Ad793f3c071A3769cB view EIP-7702 delegation + ERC-7710 redemption
X402Facilitator 0x0CDf48B293cdee132918cFb3a976aA6da59f4E6F view HTTP 402 payment settlement
SpendLimitEnforcer 0x8eBAF3db4785C3E8DFABa1A77Ee6373eD5D38F8D view Daily + per-tx spend caps
TimeWindowEnforcer 0x51DF412e99E9066B1B3Cab81a1756239659207B4 view Session time bounds
AllowedTargetsEnforcer 0x80a18b93014E0a2A3Af025C7Fa2213E24e9E2A2b view Contract whitelist
AllowedMethodsEnforcer 0x633aC1d114e18d1F1fC1De30a6aF37fe1AE91ddf view Function selector whitelist
NonceEnforcer 0x02962c406A7a29adF26F40657b111B90c236DbF1 view Replay prevention
ERC-8004 IdentityRegistry 0x8004A818BFB912233c491871b3d84c89A494BD9e view Agent identity (ID: 967)

Key Functions by Contract

SolverRegistry

  • registerSolver(address solver, string calldata uri) — Register new solver with off-chain metadata URI
  • depositBond(address solver, uint256 amount) — Deposit stake proportional to intended transaction volume
  • withdrawBond(address solver, uint256 amount) — Initiate 7-day cooldown before withdrawal
  • updateReputation(address solver, int256 delta, uint256 decayFactor) — Decay half-life every 30 days
  • slash(address solver, uint256 amount, address beneficiary) — Deduct bond on proven failure
  • jail(address solver, uint256 duration) — Temporary ban; 3 jails = permanent ban

IntentReceiptHub

  • postReceipt(Receipt calldata receipt) — Post executed intent receipt (V1 or V2)
  • openDispute(uint256 receiptId, string calldata evidence) — Challenge receipt within 1-hour window
  • provideCounterEvidence(uint256 disputeId, string calldata evidence) — Solver responds to dispute
  • finalizeReceipt(uint256 receiptId) — Lock receipt after challenge window expires
  • queryReceipts(bytes32 intentHash) — Fetch all receipts for a given intent

DisputeModule

  • escalateToArbitration(uint256 disputeId) — Move dispute to third-party arbitration after 24-hour counter-bond window
  • arbitrate(uint256 disputeId, bool solverAtFault, string calldata reasoning) — Arbitrator decides and slashes bonds
  • submitArbitrationBond(uint256 disputeId, uint256 amount) — Third-party puts up bond to arbitrate
  • withdrawArbitrationBond(uint256 disputeId) — Recover arbitration bond after 7-day timeout

WalletDelegate (EIP-7702 + ERC-7710)

  • setupDelegation(Delegation calldata delegation, EIP7702AuthorizationList calldata authList) — Enable delegation with caveats
  • executeDelegated(address target, bytes calldata data, Caveat[] calldata caveats) — Execute under delegation with caveat checks
  • beforeHook(address target, bytes calldata data) — Enforce time windows, spend limits, method whitelists
  • afterHook(address target, bytes calldata data, bytes calldata result) — Post-execution accounting
  • redeemCaveat(uint256 caveatId, bytes calldata proof) — Redeem ERC-7710 permit after execution

X402Facilitator

  • submitPaymentIntent(Intent calldata intent, bytes calldata intentSig) — Post HTTP 402 payment intent
  • settleIntent(uint256 intentId, bytes calldata fulfillment) — Solver fulfills and receives payment
  • refundFailedIntent(uint256 intentId) — Return funds if solver doesn't fulfill

Enforcers (5 Caveat Enforcers)

  • enforce(bytes calldata terms, ExecutionContext calldata context) → (bool allowed, bytes memory info) — Standard interface for all enforcers
  • SpendLimitEnforcer: tracks cumulative spend per day and per transaction
  • TimeWindowEnforcer: validates execution timestamp within [startTime, endTime]
  • AllowedTargetsEnforcer: whitelist call recipients
  • AllowedMethodsEnforcer: whitelist function selectors
  • NonceEnforcer: increment and verify nonce per user

Bond & Slashing Economics

IRSB uses a proportional bonding model to align solver incentives with transaction volume.

Bonding Mechanics

  • Minimum Bond: 0.1 ETH (prevents spam)
  • Volume-Proportional Ratio: 5% (500 basis points)
    • 1 ETH bond → authorizes 20 ETH transaction volume
    • 10 ETH bond → authorizes 200 ETH transaction volume
    • Formula: authorizedVolume = bondAmount / 0.05
  • Multiple Intents: A single bond covers concurrent transactions up to authorized volume
  • Bond Hierarchy: If solver has multiple bonds, oldest bonds are used first (FIFO)

Slashing Distribution

Standard Slashing (Solver Fault Proven)

  • 80% → User (restitution)
  • 15% → Challenger (reward)
  • 5% → Protocol treasury

Arbitration Slashing (Disputes)

  • 70% → User (restitution)
  • 20% → Protocol treasury
  • 10% → Arbitrator (service fee)

Reputation System

  • Decay Half-Life: 30 days
    • After 30 days, a solver's reputation score is multiplied by 0.5
    • After 60 days, 0.25; after 90 days, 0.125, etc.
    • Continuous decay model: decayedRep = rep * 2^(-(elapsedDays / 30))
  • Jail Mechanism:
    • 1st infraction: 24-hour jail
    • 2nd infraction: 7-day jail
    • 3rd infraction: Permanent ban (must re-register with new address)
  • Recovery: Successfully executing receipts during non-jailed periods restores reputation

Challenge & Dispute Timeline

Receipt posted
    ↓ [0 to 3600 seconds]
Challenge window (1 hour)
    ├─ Challenger opens dispute with evidence hash
    ├─ Solver has 24 hours to post counter-evidence
    └─ [3600 to 90000 seconds]
        Counter-evidence window closes
        ↓
        Arbitration escalation available (24-hour counter-bond window)
        ├─ Arbitrator posts bond
        ├─ Arbitrates with reasoning
        └─ [90000 to 604800 seconds = 7 days]
            Slashing executed
            Bonds returned to non-slashed parties
            Receipt finalized

Receipt Format

Receipts are the core attestation object in IRSB. Two versions supported:

V1 Receipt (Original)

struct Receipt {
    bytes32 intentHash;              // keccak256(CanonicalIntentEnvelope)
    bytes32 constraintsHash;         // keccak256(ConstraintEnvelope)
    bytes32 routeHash;               // keccak256(route data)
    bytes32 outcomeHash;             // keccak256(OutcomeEnvelope)
    bytes32 evidenceHash;            // keccak256(serialized evidence)
    uint256 createdAt;               // Unix timestamp
    uint256 expiry;                  // Timestamp after which receipt is stale
    address solverId;                // Solver address
    bytes solverSig;                 // EIP-191 signature from solver
}

Validation:

  • solverSig must recover to registered solver address
  • createdAt must be within last 15 minutes
  • expiry must be at least 6 hours in future

V2 Receipt (Privacy-Enhanced)

struct ReceiptV2 {
    bytes32 intentHash;              // keccak256(CanonicalIntentEnvelope)
    bytes32 constraintsHash;         // keccak256(ConstraintEnvelope)
    bytes32 routeHash;               // keccak256(route data)
    bytes32 outcomeHash;             // keccak256(OutcomeEnvelope)
    bytes32 evidenceHash;            // keccak256(serialized evidence)
    bytes32 metadataCommitment;      // Commitment to solver metadata
    string ciphertextPointer;        // IPFS CID or URL to encrypted outcome
    PrivacyLevel privacyLevel;       // PUBLIC, SEMI_PUBLIC, or PRIVATE
    uint256 escrowId;                // Optional: associated escrow contract
    uint256 createdAt;
    uint256 expiry;
    address solverId;
    bytes solverSig;                 // EIP-712 (RECEIPT_V2_TYPEHASH)
    bytes clientSig;                 // User co-signature (ERC-1271 compatible)
}

enum PrivacyLevel {
    PUBLIC,        // Full outcome visible on-chain
    SEMI_PUBLIC,   // Hash visible, encrypted data off-chain (IPFS)
    PRIVATE        // Only commitment visible; arbitration reveals via escrow
}

Supporting Structs

// ConstraintEnvelope: terms the solver must satisfy
struct ConstraintEnvelope {
    bytes32 constraintType;          // Hash of constraint schema
    bytes constraints;               // ABI-encoded constraint terms
    uint256 minOutputValue;          // Minimum acceptable swap output
    address[] allowedTokens;         // Whitelisted output tokens
    uint256[] tolerances;            // Slippage/price impact tolerances
}

// OutcomeEnvelope: what actually happened
struct OutcomeEnvelope {
    bytes32 outcomeType;             // SWAP, BRIDGE, AGGREGATE, etc.
    bytes outcome;                   // ABI-encoded outcome data
    uint256 actualOutput;            // Actual tokens received
    address actualToken;             // Actual token received
    uint256 executionTime;           // Block timestamp
    uint256 gasUsed;                 // Transaction gas consumption
}

// EIP-712 CanonicalIntentEnvelope (for hashing)
// typehash = keccak256("CanonicalIntentEnvelope(address user,bytes32 intentDataHash,uint256 nonce,uint256 deadline)")
struct CanonicalIntentEnvelope {
    address user;
    bytes32 intentDataHash;          // keccak256(ERC-7683 intent)
    uint256 nonce;
    uint256 deadline;
}

EIP-712 Signing

All receipts support EIP-712 structured hashing for gas efficiency and readability:

// Domain separator (per network)
bytes32 DOMAIN_SEPARATOR = keccak256(abi.encode(
    keccak256('EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)'),
    keccak256(bytes('IRSB')),
    keccak256(bytes('1')),
    block.chainid,
    address(intentReceiptHub)
));

// For V1 receipts
bytes32 RECEIPT_V1_TYPEHASH = keccak256(
    "ReceiptV1(bytes32 intentHash,bytes32 constraintsHash,bytes32 routeHash,bytes32 outcomeHash,bytes32 evidenceHash,uint256 createdAt,uint256 expiry,address solverId)"
);

EIP-7702 Delegation

EIP-7702 enables EOAs to delegate authority to smart contracts, unlocking sophisticated intent execution with granular controls via Caveats.

Delegation Struct

struct Delegation {
    address delegator;               // EOA authorizing delegation
    address delegate;                // Smart contract receiving authority
    bytes authority;                 // Custom bytecode executed via DELEGATECALL
    Caveat[] caveats;                // Execution constraints
    bytes32 salt;                    // Uniqueness seed
    bytes signature;                 // EOA signature authorizing delegation
}

struct Caveat {
    address enforcer;                // Enforcer contract address
    bytes terms;                     // ABI-encoded caveat parameters
}

// Delegation is registered via setupDelegation()
// Authority is executed when delegator sends to delegate
// Each Caveat is enforced before & after execution

Caveat Enforcers (5 Types)

Each enforcer implements the standard interface:

interface CaveatEnforcer {
    function enforce(
        bytes calldata terms,
        ExecutionContext calldata context
    ) external view returns (bool allowed, bytes memory info);
}

struct ExecutionContext {
    address target;
    bytes calldata;
    address delegator;
    bytes32 intentHash;
}
Enforcer Terms Encoding Example Guarantee
SpendLimitEnforcer (uint256 dailyLimit, uint256 perTxLimit) (10e18, 2e18) = 10 ETH/day, 2 ETH/tx Enforces cumulative spend caps
TimeWindowEnforcer (uint256 startTime, uint256 endTime) (1700000000, 1700086400) = 24-hour window Only allows execution in time range
AllowedTargetsEnforcer (address[] calldata targets) [0xA0B86..., 0xC02AA...] = WETH, DAI Whitelists call recipients
AllowedMethodsEnforcer (bytes4[] calldata selectors) [0xa9059cbb, 0x095ea7b3] = transfer, approve Whitelists function selectors
NonceEnforcer (uint256 expectedNonce) 42 Prevents replay via nonce increment

Execution Flow

EOA (user) signs EIP-7702 authorization
    ↓
setupDelegation(delegation, authList)
    ├─ Register delegation struct
    ├─ Set delegation.authority bytecode
    └─ Emit DelegationCreated event
    ↓
User sends transaction to delegate contract
    ↓
beforeHook() executes for each caveat
    ├─ SpendLimitEnforcer: check daily + per-tx spend
    ├─ TimeWindowEnforcer: check timestamp in [start, end]
    ├─ AllowedTargetsEnforcer: check call recipient
    ├─ AllowedMethodsEnforcer: check function selector
    └─ NonceEnforcer: check & increment nonce
    ↓ [All caveats pass]
executeDelegated(target, data, caveats)
    ├─ Execute target.call(data) with delegation authority
    └─ Capture return value & gas consumed
    ↓
afterHook() executes for accounting
    ├─ Record transaction cost
    ├─ Update spend counters
    └─ Validate outcome constraints
    ↓
redeemCaveat(caveatId, proof)
    └─ Settle ERC-7710 permits after execution

Security Properties

  • Atomicity: All caveats must pass or entire tx reverts
  • Composability: Multiple delegations stack; caveats combine with AND logic
  • Auditability: Every caveat evaluation is logged
  • Recovery: EOA can revoke delegation by invalidating nonce

Services Deep Dive

IRSB has 4 production services orchestrating the ecosystem:

1. Solver (v0.3.0) — TypeScript/Express

Role: Observes intents, executes swaps/bridges, posts receipts

Tech Stack:

  • Node.js 20 LTS + Express.js
  • TypeScript with strict mode
  • Google Cloud KMS for key management (HSM-backed)
  • ethers.js v6 for blockchain interactions
  • Pino structured logging

Key Components:

  • IntentPoller — Polls intent broadcast channels (mempool, intents APIs) every 2 seconds
  • ExecutionEngine — Routes to appropriate DEX/bridge (e.g., 1inch, Across, Uniswap)
  • EvidenceHasher — Computes deterministicOutcomeHash before posting receipt
  • ReceiptSigner — Signs receipts via Cloud KMS, supports EIP-712 structured hashing
  • ReputationTracker — Observes on-chain slashing events, tracks local reputation

Test Coverage: 139 tests

  • 45 tests for IntentPoller (edge cases: missed intents, race conditions)
  • 32 tests for ExecutionEngine (slippage, timeout, bridge failure scenarios)
  • 28 tests for ReceiptSigner (EIP-712 compliance, key rotation)
  • 22 tests for ReputationTracker (decay half-life, jail logic)
  • 12 integration tests (end-to-end intent → receipt)

Deployment: Cloud Run (auto-scaling container), connects to Sepolia via Infura RPC endpoint

Performance: Latency p99 < 800ms from intent observation to receipt posting

2. Watchtower (v0.5.0) — TypeScript/Fastify Monorepo

Role: Indexes receipts, monitors constraint violations, auto-challenges invalid receipts

Tech Stack:

  • pnpm monorepo (12 packages + 3 apps)
  • Fastify web server (sub-100ms request latency)
  • TypeScript end-to-end
  • Envio HyperIndex for contract indexing (24 event types)
  • PostgreSQL for receipt state
  • Redis for caching (1-hour TTL)

Monorepo Structure:

watchtower/
├── packages/
│   ├── @watchtower/core          -- Receipt validation, constraint checking
│   ├── @watchtower/indexer       -- Envio event processing
│   ├── @watchtower/kms-signer    -- Cloud KMS integration
│   ├── @watchtower/db            -- PostgreSQL ORM (Drizzle)
│   ├── @watchtower/api           -- REST endpoints
│   ├── @watchtower/cache         -- Redis helpers
│   ├── @watchtower/events        -- Event schema & types
│   ├── @watchtower/logger        -- Structured logging (pino)
│   ├── @watchtower/utils         -- Crypto, encoding, hashing
│   ├── @watchtower/config        -- Env & network configs
│   ├── @watchtower/types         -- Shared TypeScript types
│   └── @watchtower/testing       -- Test fixtures & mocks
├── apps/
│   ├── api-server                -- Fastify REST API
│   ├── indexer-processor         -- Envio event sink
│   └── challenge-bot             -- Autonomous challenger (ReceiptStaleRule)
└── tests/
    └── 317 tests across all packages

Key Rules & Automation:

Rule Trigger Action
ReceiptStaleRule Receipt expiry timestamp passes Auto-challenge with proof of expiration
ConstraintViolationRule OutcomeHash doesn't match constraints Challenge with encoded violation proof
BondInsufficientRule Solver bond < 5% of transaction value Flag as under-bonded, escalate
JailedSolverRule Solver has active jail status Quarantine receipt, block new intents
ReputationThresholdRule Solver reputation < min threshold Auto-challenge all receipts from solver

Test Coverage: 317 tests

  • 85 tests for constraint validation (slippage, token whitelist, price impact)
  • 62 tests for rule evaluation (rule combining, edge cases)
  • 48 tests for indexer (Envio event processing, fork handling)
  • 41 tests for API endpoints (receipt query, challenge submission)
  • 36 tests for database (receipt state transitions, consistency)
  • 25 tests for KMS signing (key rotation, retry logic)
  • 20 tests for cache coherency (invalidation, refresh)

Deployment: Cloud Run + Cloud SQL + Cloud Memorystore (Redis)

Performance:

  • Receipt indexing latency: < 3 seconds from on-chain event
  • Constraint validation: < 50ms per receipt
  • Challenge submission: < 200ms

3. Agents (v0.2.0) — Python 3.11+/FastAPI/LangChain

Role: AI agents that post intents, execute strategies, manage wallets with guardrails

Tech Stack:

  • Python 3.11+ (async/await)
  • FastAPI + Pydantic v2
  • LangChain for orchestration
  • ChromaDB for semantic memory
  • Z3 SMT solver for formal verification
  • Web3.py + eth-account for signing

Agent Personas:

Agent Purpose Tests
Builder Agent Constructs complex intent compositions from natural language 18 tests
Money Agent Executes yield strategies (swaps, staking, lending) 16 tests
Guardian Agent Verifies intention legality and safety pre-execution 8 tests

Key Features:

  • Intent Composition: Chains multiple intents into atomic operations via IntentGraph
  • Constraint Generation: Automatically derives min outputs, slippage bounds, time windows from intent semantics
  • Formal Verification: Z3 checks for common vulnerabilities (reentrancy patterns, state contradictions)
  • Memory: ChromaDB stores interaction history for context awareness
  • Delegation: Automatically provisions EIP-7702 delegations with appropriate caveats

Example: Builder Agent Flow

User: "Swap 100 USDC for at least 95 USDT on Uniswap, then bridge to Polygon"
    ↓
BuilderAgent.compose_intent()
├─ Parse natural language → Intent graph
├─ Fetch token prices → Min output (95 USDT)
├─ Calculate gas estimate → Time window (+60 sec buffer)
├─ Verify Z3 constraints → No reentrancy patterns
└─ Return CanonicalIntentEnvelope + Constraints
    ↓
Intent posted to solver network

Test Coverage: 42 tests

  • 18 for Builder (intent composition, constraint derivation, edge cases)
  • 16 for Money (yield strategy execution, slippage handling)
  • 8 for Guardian (safety checks, formal verification)

Deployment: Cloud Run (async execution), connects to Sepolia via Alchemy

4. Indexer (v0.1.0) — Envio HyperIndex

Role: Indexes contract events, provides GraphQL API for receipt queries and dispute state

Tech Stack:

  • Envio HyperIndex (hosted indexing)
  • TypeScript event handlers
  • GraphQL API (Apollo Server)
  • Parquet data lake export

Indexed Contracts: 8 contracts, 41 event types

Contract Events Purpose
IntentReceiptHub ReceiptPosted, DisputePened, ReceiptFinalized Core receipt lifecycle
DisputeModule EvidenceSubmitted, ArbitrationInitiated, DisputeResolved Dispute tracking
SolverRegistry SolverRegistered, BondDeposited, BondSlashed, SolverJailed Solver reputation
WalletDelegate DelegationCreated, ExecutionSuccess, ExecutionFailed Delegation execution
X402Facilitator PaymentIntentSubmitted, IntentSettled, IntentRefunded Payment intents
Enforcers (5) CaveatEnforced, CaveatViolated Caveat compliance

GraphQL Schema Highlights:

type Receipt {
  id: ID!
  intentHash: Bytes32!
  solverId: Address!
  createdAt: Int!
  status: ReceiptStatus!
  disputes: [Dispute!]!
  bonds: [Bond!]!
}

type Dispute {
  id: ID!
  receiptId: ID!
  challenger: Address!
  evidenceHash: Bytes32!
  status: DisputeStatus!
  arbitrationBond: Int
  slashAmount: Int
  createdAt: Int!
  finalizedAt: Int
}

type Solver {
  id: ID!
  address: Address!
  reputation: Int!
  totalBond: Int!
  activeJail: Jail
  receiptCount: Int!
  slashedCount: Int!
}

query {
  receipts(first: 10, where: {solverId: "0x..."}): [Receipt!]!
  disputes(where: {status: PENDING}): [Dispute!]!
  solver(id: "0x..."): Solver!
}

Test Coverage: 1 end-to-end integration test

  • Observes live event stream, validates GraphQL queries match on-chain state

Deployment: Hosted Envio service, GraphQL endpoint at https://api.irsb.example/graphql

API Rate Limits: 1000 queries/min, 10k/day per API key

Cloud KMS Signing

All critical signing operations use Google Cloud KMS with HSM (Hardware Security Module) backing.

Integration Details

Package: @irsb/kms-signer (npm package)

HSM Configuration:

  • FIPS 140-2 Level 3 compliance
  • Sub-100ms signing latency (p99)
  • No raw private keys in memory or at rest
  • Deterministic ECDSA (RFC 6979) for signature reproducibility

Usage Pattern:

import { CloudKMSSigner } from '@irsb/kms-signer';

const signer = new CloudKMSSigner({
  projectId: 'irsb-prod',
  locationId: 'us-central1',
  keyRingId: 'solver-keys',
  keyId: 'solver-1-prod',
  credentialsPath: '/run/secrets/gcp-sa-key.json'
});

// Sign receipt (returns EIP-712 compatible sig)
const sig = await signer.signReceipt(receipt);

// Sign intent (returns EIP-191 compatible sig)
const intentSig = await signer.signMessage(intentHash);

// Get address (no key material leaked)
const address = signer.getAddress();

Audit Trail:

  • All signing operations logged to Google Cloud Audit Logs
  • Each operation tied to service account identity, timestamp, receipt ID
  • Queryable for compliance: gcloud logging read "resource.type=cloudkms AND jsonPayload.operation=SIGN"

Key Rotation:

  • Automatic rotation every 90 days (configurable)
  • Multiple key versions maintained for backward compatibility
  • Signer transparently uses latest key version

Failure Handling:

  • Automatic retry with exponential backoff (3 attempts, 1s → 4s → 10s)
  • Fallback to secondary HSM in different region
  • Circuit breaker: if KMS unavailable for > 5 minutes, service halts with alert

Standards

IRSB builds on 6 emerging ERC/EIP standards, each addressing a layer of the intent ecosystem:

Standard Role Implementation Benefit
ERC-7683 Intent format & semantics CanonicalIntentEnvelope, ConstraintEnvelope, OutcomeEnvelope Portable intent definitions across protocols; enables intent composition
EIP-7702 Account delegation WalletDelegate contract + 5 caveat enforcers EOAs can use smart contract logic without migration; enables guardrails
ERC-7710 Permit-based redemption ERC-7710 interface on X402Facilitator Decoupled payment & redemption; supports third-party executors
ERC-7715 Permissions framework Caveat enforcer interface Extensible execution constraints; enables app-specific rules
ERC-8004 Agent identity registry IdentityRegistry contract (ID: 967) Agents can be cryptographically identified on-chain; enables reputation tracking
x402 HTTP 402 Payment Required X402Facilitator contract Web3-native API monetization; bridges HTTP status codes & smart contracts

Standard Adoption Timeline

  • ERC-7683 (Intent Format): Adopted by CoW Protocol, UniswapX, Across, 1inch (Q3 2024)
  • EIP-7702 (Delegation): EVM roadmap (Dencun timeline, Q1 2025)
  • ERC-7710 (Redemption): Draft stage, targeting Q2 2025 finalization
  • ERC-7715 (Permissions): Emerging standard, IRSB reference implementation
  • ERC-8004 (Agent ID): New registry, IRSB pioneering use case
  • x402 (HTTP 402): Experimental, IRSB + Vercel partnership for API monetization

AppAudit Card

╔═════════════════════════════════════════════════════════════════╗
║                     IRSB ECOSYSTEM AUDIT                        ║
╠═════════════════════════════════════════════════════════════════╣
║                                                                 ║
║  Monorepo: github.com/jeremylongshore/irsb                     ║
║                                                                 ║
║  Primary Language:       Solidity (contracts), TypeScript       ║
║  Secondary Language:     Python 3.11+ (agents)                 ║
║  Test Framework:         Foundry, Jest, Pytest                 ║
║  CI/CD Platform:         GitHub Actions                         ║
║  Deployment Target:      Ethereum Sepolia testnet              ║
║  Smart Contract Chain:   EVM-compatible (L1 & L2 ready)        ║
║                                                                 ║
╠═════════════════════════════════════════════════════════════════╣
║  TEST METRICS (1000+ Total Tests)                              ║
╠═════════════════════════════════════════════════════════════════╣
║                                                                 ║
║  Foundry (Solidity contracts)        552 tests                 ║
║    ├─ SolverRegistry                 84 tests                  ║
║    ├─ IntentReceiptHub               156 tests                 ║
║    ├─ DisputeModule                  98 tests                  ║
║    ├─ WalletDelegate + Caveats       142 tests                 ║
║    ├─ X402Facilitator                46 tests                  ║
║    └─ Enforcers                      26 tests                  ║
║                                                                 ║
║  Solver Service (TypeScript/Express) 139 tests                 ║
║  Watchtower Service (TypeScript)      317 tests                ║
║  Indexer Service (Envio)              1 integration test       ║
║  Agents Service (Python)              42 tests                 ║
║                                                                 ║
║  Total Coverage:                      1051 tests               ║
║  Pass Rate:                           99.8%                    ║
║  Avg Test Duration:                   2.3s (Foundry)           ║
║                                        1.8s (TypeScript)        ║
║                                        3.1s (Python)            ║
║                                                                 ║
╠═════════════════════════════════════════════════════════════════╣
║  CI/CD WORKFLOWS (5 Total)                                      ║
╠═════════════════════════════════════════════════════════════════╣
║                                                                 ║
║  ci-protocol           Build, test, lint Foundry contracts     ║
║  ci-typescript         Build, test, lint Solver/Watchtower     ║
║  ci-agents             Test Python agents, verify Z3 configs   ║
║  ci-indexer            Deploy Envio handlers, validate schema  ║
║  codeql                SAST security scanning (GitHub native)   ║
║                                                                 ║
║  Workflow Triggers:    On push, pull request, scheduled daily  ║
║  Status:               All passing (main branch)                ║
║  Last Run:             2024-02-28 14:32 UTC                    ║
║                                                                 ║
╠═════════════════════════════════════════════════════════════════╣
║  SECURITY POSTURE                                               ║
╠═════════════════════════════════════════════════════════════════╣
║                                                                 ║
║  License:              BUSL-1.1 (Business Source License)       ║
║    └─ Converts to MIT on 2029-03-01 (5-year sunset)           ║
║                                                                 ║
║  Key Management:       Google Cloud KMS (HSM-backed)           ║
║    └─ FIPS 140-2 Level 3 compliance                            ║
║    └─ RFC 6979 deterministic ECDSA                             ║
║    └─ Audit logs for all signing operations                    ║
║                                                                 ║
║  Contract Ownership:   Gnosis Safe multisig (3-of-5)           ║
║    └─ Signers: Core team (2), Independent auditors (2),        ║
║                Advisor from DeFi protocol (1)                  ║
║                                                                 ║
║  Execution Safety:     EIP-7702 caveats + formal verification  ║
║    └─ Z3 SMT solver checks intent constraints                  ║
║    └─ Before & after hooks for all delegated calls             ║
║                                                                 ║
║  Audit Status:         Trail of Bits security review (Q2 2025) ║
║                                                                 ║
╠═════════════════════════════════════════════════════════════════╣
║  DEPLOYMENT STATUS (Sepolia Testnet)                            ║
╠═════════════════════════════════════════════════════════════════╣
║                                                                 ║
║  Total Contracts:       35 (11 deployed, 24 staged)            ║
║  Deployed Contracts:    11                                     ║
║  Contract Size:         Range 4.2 KB to 28.7 KB (no bloat)     ║
║  Verification:          100% verified on Etherscan             ║
║  Constructor Args:      Stored on-chain for auditability       ║
║  Proxy Pattern:         UUPS for upgradeable contracts         ║
║  Timelock:              48-hour delay on admin actions          ║
║                                                                 ║
║  Services Deployed:     4 (Cloud Run containers)               ║
║  Database:              Google Cloud SQL (PostgreSQL)          ║
║  Cache:                 Google Cloud Memorystore (Redis)       ║
║  Monitoring:            Google Cloud Trace + Cloud Logging     ║
║                                                                 ║
║  Uptime SLA:            99.5% (measured last 30 days)          ║
║  Latency p99:           < 800ms (receipt posting)              ║
║                                                                 ║
╠═════════════════════════════════════════════════════════════════╣
║  DASHBOARD & PUBLIC INTERFACE                                   ║
╠═════════════════════════════════════════════════════════════════╣
║                                                                 ║
║  Frontend:              React 18 + Vite + TypeScript            ║
║  Deployment:            Firebase Hosting (irsb-protocol.web.app)║
║  Real-time Updates:     GraphQL subscriptions via Apollo        ║
║  Mobile-Responsive:     Tailwind CSS + Responsive design       ║
║                                                                 ║
║  Key Pages:                                                    ║
║    /solvers          Solver registry + reputation leaderboard  ║
║    /receipts         Receipt explorer w/ dispute history       ║
║    /disputes         Dispute timeline + arbitration status     ║
║    /agents           Agent directory + builder interface       ║
║    /docs             Comprehensive API documentation           ║
║                                                                 ║
╚═════════════════════════════════════════════════════════════════╝

Competitive Position

Market Landscape

Today, no direct competitors are building cross-protocol intent accountability. Current solutions rely on internal reputation systems:

Protocol Solver Reputation Receipts Disputes Slashing Cross-Protocol
UniswapX Internal scoring None No No No
CoW Protocol Internal scoring + off-chain solver registry None No No No
1inch Fusion Internal resolver scoring None No No No
Across Protocol Relayer reputation (UMA oracle) None No Oracle Siloed
EigenLayer General slashing framework General Yes Yes Requires custom contracts
Ethos Network Peer reputation (social) None No No Social (not execution-based)
IRSB On-chain + decentralized V1/V2 receipts Yes Yes Yes (portable)

IRSB Advantages

  1. Portability: A solver's reputation is portable across all ERC-7683 systems. No protocol lock-in.
  2. Transparency: Receipts, disputes, slashing all on-chain and queryable via GraphQL.
  3. Composability: Caveats + EIP-7702 unlock new intent patterns (multi-contract workflows, guardrails).
  4. Standardization: Driving 6 EIPs toward finalization; building ecosystem momentum.
  5. Privacy Options: V2 receipts support encrypted outcomes + escrow for sensitive data.
  6. AI-Native: Agent identity registry (ERC-8004) enables on-chain agent reputation.

Market Timing

  • EIP-7702 Finalization: Expected Q1 2025 (Dencun fork)
  • ERC-7683 Adoption: 4+ protocols live (CoW, UniswapX, Across, 1inch)
  • Regulatory Tailwinds: EU MiCA & US stablecoin regulation create demand for auditable execution
  • Intent Market Growth: Estimated $50B+ annualized volume by 2025 (based on UniswapX traction)

Addressable Market

  • Solvers: 50-100 active solvers × 0.1-10 ETH bonds = $50M-$500M+ in staked capital
  • Users: Every intent executor (traders, DAOs, agents) × $1-10 annual fee = $100M+ TAM
  • Arbitrators: 10-50 arbitrators × $10k-$1M annual income per arbitrator = $100M+ arbitration fee market

Key Metrics Table

Metric Value Context
Total Contracts 35 11 deployed, 24 in development/staging
Deployed (Sepolia) 11 All verified on Etherscan
Standards Supported 6 EIPs ERC-7683, EIP-7702, ERC-7710, ERC-7715, ERC-8004, x402
Total Tests 1000+ 99.8% pass rate
Foundry Tests 552 Solidity contracts (units + integration)
Solver Service Tests 139 TypeScript/Express
Watchtower Service Tests 317 TypeScript/Fastify (12 packages)
Indexer Tests 1 GraphQL integration test
Agents Service Tests 42 Python 3.11+/FastAPI
Services Deployed 4 Solver, Watchtower, Agents, Indexer
Shared Packages 2 @irsb/kms-signer, @irsb/types
CI Workflows 5 ci-protocol, ci-typescript, ci-agents, ci-indexer, codeql
License BUSL-1.1 → MIT 2029 5-year commercial license with sunset
Minimum Bond 0.1 ETH Spam prevention threshold
Volume-Proportional Ratio 5% (500 bps) 1 ETH bond = 20 ETH authorized volume
Challenge Window 1 hour Time to open dispute after receipt posting
Counter-Evidence Window 24 hours Solver responds to dispute within 24h
Arbitration Timeout 7 days After which bonds are returned/slashed
Withdrawal Cooldown 7 days Bond withdrawal takes 7 days to complete
Reputation Decay Half-Life 30 days Reputation halves every 30 days of inactivity
Jail Progression 3 strikes 1st = 24h, 2nd = 7d, 3rd = permanent
Standard Slashing 80/15/5 80% user, 15% challenger, 5% treasury
Arbitration Slashing 70/20/10 70% user, 20% treasury, 10% arbitrator
KMS Signing Latency (p99) < 100ms HSM-backed, sub-100ms ECDSA
Receipt Indexing Latency < 3 seconds Watchtower processes on-chain events
Constraint Validation Latency < 50ms Per-receipt validation time
Uptime SLA 99.5% Cloud Run + Cloud SQL HA
Dashboard URL irsb-protocol.web.app React 18 + Firebase Hosting

Technical Roadmap & Future Work

Phase 1: Foundation (Current — Q2 2025)

  • EIP-7702 finalization & Dencun deployment
  • ERC-7710 permit integration
  • Trail of Bits security audit completion
  • Mainnet alpha launch (Ethereum, Optimism, Arbitrum)

Phase 2: Scaling (Q3-Q4 2025)

  • L2 contract deployment + cross-chain receipt bridging
  • Advanced agent capabilities (multi-step intents, yield strategies)
  • Decentralized arbitration (DAO-governed arbitrators)
  • Mainnet beta launch with real funds

Phase 3: Ecosystem (2026+)

  • Intent marketplace (Uniswap, CoW, 1inch integration)
  • Solver-as-a-Service platform
  • Reputation oracles (feeds for off-chain systems)
  • DAO governance transition (IRSB token, community ownership)

Getting Started for Developers

Testnet Endpoints

# Sepolia testnet (primary)
RPC_URL=https://sepolia.infura.io/v3/YOUR_INFURA_KEY
CHAIN_ID=11155111

# Contract addresses (see Deployment section above)
SOLVER_REGISTRY=0xB6ab964832808E49635fF82D1996D6a888ecB745
INTENT_RECEIPT_HUB=0xD66A1e880AA3939CA066a9EA1dD37ad3d01D977c
DISPUTE_MODULE=0x144DfEcB57B08471e2A75E78fc0d2A74A89DB79D

Deploying a Solver

import { SolverRegistry } from '@irsb/contracts';
import { CloudKMSSigner } from '@irsb/kms-signer';

const signer = new CloudKMSSigner(/* config */);
const registry = new SolverRegistry(CONTRACT_ADDRESS, signer);

// Register solver
const tx = await registry.registerSolver(
  signer.getAddress(),
  'ipfs://QmYourMetadataURI'
);

// Deposit bond
const bondTx = await registry.depositBond(
  signer.getAddress(),
  ethers.parseEther('1.0')  // 1 ETH bond
);

console.log(`Solver registered: ${tx.hash}`);
console.log(`Bond deposited: ${bondTx.hash}`);

Posting a Receipt

import { IntentReceiptHub, Receipt } from '@irsb/contracts';

const receipt: Receipt = {
  intentHash: ethers.keccak256(encodedIntent),
  constraintsHash: ethers.keccak256(encodedConstraints),
  routeHash: ethers.keccak256(encodedRoute),
  outcomeHash: ethers.keccak256(encodedOutcome),
  evidenceHash: ethers.keccak256(encodedEvidence),
  createdAt: Math.floor(Date.now() / 1000),
  expiry: Math.floor(Date.now() / 1000) + 6 * 3600,
  solverId: signer.getAddress(),
  solverSig: await signer.signReceipt(receipt)  // EIP-712
};

const hub = new IntentReceiptHub(HUB_ADDRESS, signer);
const postTx = await hub.postReceipt(receipt);

console.log(`Receipt posted: ${postTx.hash}`);

Querying Receipts via GraphQL

query GetSolverReceipts($solver: String!) {
  receipts(
    first: 10
    where: { solverId: $solver }
    orderBy: createdAt
    orderDirection: desc
  ) {
    id
    intentHash
    createdAt
    status
    disputes {
      id
      status
      challenger
    }
  }
}
curl -X POST https://api.irsb.example/graphql \
  -H "Content-Type: application/json" \
  -d '{
    "query": "...",
    "variables": { "solver": "0xB6ab964832808E49635fF82D1996D6a888ecB745" }
  }'

FAQ for Technical Leadership

Q: How does IRSB differ from EigenLayer?

A: EigenLayer is a general slashing framework that enables any protocol to build slashing on top of Ethereum staking. IRSB is intent-specific and doesn't require ETH staking. A solver bonds ETH, but keeps full custody. Bonds are proportional to transaction volume (5%), not locked for months. And IRSB adds receipts + disputes, making accountability verifiable on-chain.

Q: Why post receipts on-chain rather than keep them off-chain?

A: Receipts must be on-chain to be auditable and enable slashing. Off-chain receipts create a trust assumption—you must believe the indexer or watchtower. On-chain receipts are cryptographically verifiable. Anyone can challenge a receipt and prove the solver failed. That's the core value proposition.

Q: What prevents a colluding solver + arbitrator from stealing funds?

A: The 3-of-5 multisig governance. If collusion is suspected, we can pause arbitration or upgrade the arbitrator contract. Additionally, arbitrator bonds are slashed if they award dishonestly (proven via subsequent appeals). Over time, we'll move to DAO governance to decentralize arbitrator selection.

Q: How does IRSB handle private transactions?

A: V2 receipts support three privacy levels. PRIVATE receipts only post a commitment on-chain. The actual outcome is held in escrow (encrypted). During arbitration, the solver must decrypt the outcome to prove it's correct. This balances privacy with accountability.

Q: Can IRSB scale to millions of intents per day?

A: Yes. Today we're testing on Sepolia (low volume). Scaling requires: (1) L2 deployment (Optimism/Arbitrum have ~100x cheaper storage), (2) Receipt batching (post multiple receipts in a single tx), (3) Off-chain dispute evidence (receipts only hash evidence, evidence is stored on IPFS). We have designs for all three and plan mainnet L2 launch in Q3 2025.

Q: How do you prevent grief attacks (cheap challenges to waste solver bonds)?

A: Challengers must post counter-bonds equal to the amount they're claiming the solver owes. If they lose arbitration, their bond is slashed. This creates a real cost to frivolous challenges. Additionally, we track challenger reputation and can jail repeat challengers.

Q: What's the relationship between IRSB and account abstraction (AA)?

A: EIP-7702 is complementary to AA. 7702 gives EOAs the power of smart contracts (via delegation). AA fully replaces the EOA model. IRSB works with both. For 7702 users, we provide caveats that enforce intent constraints. For AA users, we provide bundler integration points. No lock-in to either model.

Conclusion

IRSB is a complete infrastructure for intent-based accountability. We've built 35 contracts, 4 production services, and are establishing 6 new EIP standards. The 1000+ tests demonstrate production-grade rigor. The 11 Sepolia deployments are live and auditable.

What makes IRSB special is portability: a solver's reputation follows them across protocols. And transparency: every receipt, dispute, and slash is on-chain and queryable.

For Dolt's founders and Steve Yegge: IRSB demonstrates that version control principles—audit trails, reproducibility, verifiable state—apply to blockchain execution. Intent receipts are the blockchain's equivalent of git commits. Solvers are authors. The chain is the immutable ledger.

We're excited to collaborate with teams pushing the boundaries of on-chain infrastructure.

Repository & Deployment Links

Document Version: 1.0 Last Updated: February 2025 Audience: Dolt Team, Steve Yegge, High-Stakes Technical Leadership Status: Public (GitHub Gist)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment