KiroPay

• Name: KiroPay
• URL: https://kiropay.app/
• Category: machine-payments router / ERC-4337 account-policy wrapper
• Tags: ethereum-ecosystem
• Summary: KiroPay is an ERC-4337 policy shell wrapped around machine-payments routing. The account, treasury, and rules are the point, not the rail.
• What it does:
  • Routes agent payments across x402, MPP, and fiat rails through one integration surface
  • Provides ERC-4337 smart accounts with multisig control, session keys, spending policies, social recovery, and gas sponsorship
  • Maintains a yield-bearing treasury for agent funds, with official materials naming USDC, USDT, DAI, and Aave or Compound-style strategies
  • Enforces enterprise controls through a policy registry with spend limits, allowlists, and emergency pause behavior
  • Ships smart contracts, a Python SDK, examples, docs, and a public Sepolia-facing product surface
• Key claims:
  • The interesting part is the account-and-policy stack, not the multi-rail pitch
  • ERC-4337 accounts, session keys, treasury defaults, registry rules, and recovery all sit under one operator surface
  • The repo makes that plain: policy, treasury, and routing are first-class, not side details
  • Treat KiroPay as policy-heavy operator middleware above stronger paid-request and account-control rails, not as a payment standard
• Whitepaper: An official KiroPay whitepaper is linked from the docs and GitHub README and was saved locally as ../whitepapers/kiropay-whitepaper.pdf. The clearest current source of truth in this pass was the homepage, docs overview, repo README, and the linked whitepaper artifact; see ../whitepapers/kiropay-primary-sources-2026-05-02.md.
• Sources:
  • https://kiropay.app/
  • https://docs.kiropay.app/
  • https://docs.kiropay.app/whitepaper.pdf
  • https://github.com/kiropay-labs
  • https://raw.githubusercontent.com/kiropay-labs/transaction-router/main/README.md

Internal linkages

• Strongest upward reads: x402 and safe.

Control surface

• The leverage sits in route selection, treasury defaults, policy-registry rules, session-key scope, and account ownership.

• Sponsorship, yield routing, and recovery matter because they keep more of the spending stack under one operator surface.

• Account-policy and routing middleware above stronger paid-request rails, not a canonical payment rail.

• Last reviewed: 2026-06-18 UTC