IRSB is trying to be a lower-layer accountability rail for delegated machine execution, not just an agent wallet add-on. The core split is between policy enforcement, receipt generation, bonded recourse, and downstream reputation export.
The README frames the project around WalletDelegate + Enforcers, receipts, bonds, disputes, and ERC-8004 reputation. That decomposition is the main reason the project belongs in the active corpus.
The protocol is explicitly dual-use across AI agents and ERC-7683-style intent solvers. That makes it a useful bridge between crypto × AI execution systems and order-routing / solver-accountability infrastructure.
The x402 guide adds another important layer: IRSB can wrap paid API flows so payment proof, result delivery, receipt issuance, and later disputes/finalization become one comparable machine-commerce pipeline rather than disconnected pieces.
The privacy architecture is more deliberate than a generic onchain audit log. Commitments, CIDs, and privacy levels are onchain; fuller payloads and evidence remain offchain and may be access-gated or Lit-encrypted.
Specific source signals worth retaining
README: best concise overview of the protocol’s control surfaces, including the five enforcers, solver lifecycle, receipt flow, and Sepolia deployment addresses.
014-AT-DSGN-privacy-design.md: most useful for understanding that IRSB is commitment-first rather than plaintext-first, and for seeing how dispute evidence and privacy levels are meant to work.
016-AT-INTG-x402-integration.md: most useful for understanding the machine-payments angle, especially how HTTP 402 flows map into ReceiptV2 fields and later onchain reputation/dispute mechanics.
Why this entry belongs in the corpus
It gives the corpus a clearer comparison point for agent guardrails than generic AI-wallet rhetoric. The important move is not just restrict the agent, but separating execution policy, execution evidence, collateralized recourse, and reputation routing into different layers.
It strengthens comparison work across Agent Passport System, Giza Protocol, Warden Protocol, x402, L402, ERC-7683, and smart-account policy systems by making receipt and recourse design first-class surfaces.
The durable insight is that delegated machine execution is not only an authorization problem. It is also a proof, monitoring, and recourse problem, and IRSB makes that decomposition unusually explicit.
Main caveats from reviewed materials
The protocol still depends heavily on offchain operations: monitoring, evidence availability, encrypted payload hosting, and timely challenges all matter.
The README and docs provide useful maturity signals, but they remain first-party claims. I did not review an independent audit or a standalone formal spec in this pass.