Grant review package

Spending controls for agents paying with USDC.

Kestrel helps teams set spending limits and review what happened to a payment. Start with the testnet demo or inspect an existing transfer with the read-only Arc mainnet verifier, and help us test the failure cases that matter to your application.

Reviewer console

One place to understand Kestrel.

First review

Inspect the workflow, then challenge one assumption.

01Inspect spending controlsOpen Money Movement and inspect network, amount, recipient and policy states. Connecting a wallet is optional for this review.Open this step
02Inspect the evidenceOpen Proof Center. Distinguish an intent, a submitted transaction and a confirmed transfer; a receipt is a separate claim.Open this step
03Check the measurementsOpen Grant Evidence and read the source, sample limits and verification status alongside the figures.Open this step
04Share one failure caseTell us how your agent handles a timeout after payment, a duplicate request or a provider that does not deliver.Join the discussion

Review snapshot · 14 October 2026

Evidence you can inspect.

Revision fb7bd63 passed 60 unit tests, contract checks, lint and builds for four workspaces, 13 local API checks and an isolated data-fallback check. These are engineering checks; they do not prove real payment activity or customer adoption.

Circle and Arc fit

Integration status matrix.

Implemented
USDC spending policy

Amount caps, recipient allowlists and wallet-signed authorization before supported execution paths.

Gated pilot
Arc mainnet Send

A narrow Arc-to-Arc USDC Send path, disabled in the production configuration. Mainnet requires explicit execution flags and a recipient allowlist. No Kestrel-initiated mainnet payment has been verified.

Configuration-ready
Circle Wallets

The existing server-controlled settlement path targets Arc Testnet. Credentials and operator configuration are required for execution.

Testnet demo
Bridge / Unified Balance

App Kit route and recovery surfaces are implemented for the existing testnet workflow. Completed mainnet integrations are not claimed.

Configuration-ready
Swap

Server-only signer and Kit Key support is implemented. Execution stays blocked when the required configuration is missing.

Implemented
Payment evidence

Public-field JSON export and a read-only direct Send verifier. The verifier checks RPC transaction facts, not policy authenticity or API delivery.

Unverified
Provider fulfillment

The demo includes provider receipt structures. A real external provider's delivery linked to an Arc mainnet payment remains to be demonstrated.

Unverified
Collected fee revenue

Direct Send models no Kestrel developer fee. Collected revenue remains unverified; estimates and accrued amounts must be reported separately.

Known limits

What remains to be demonstrated.

  • The existing demo uses Arc Testnet. A production web deployment does not establish mainnet payment activity.
  • The read-only verifier can inspect existing third-party mainnet transfers. No Kestrel-initiated mainnet payment, external provider fulfillment or collected Kestrel fee revenue is claimed.
  • Money proof exports are browser records, not a durable public archive. RPC verification does not establish policy signatures, Kestrel provenance or API fulfillment.
  • Mainnet compliance uses a labeled Ethereum identity signal; native Arc screening is not claimed.
  • Workspace catalog counters and seed data are not independently verified adoption. Local timeout tests do not establish that the production database or alert delivery has recovered.
  • The milestones below are a proposed development sequence. Budget, delivery dates and grant acceptance have not been agreed.

Proposed roadmap

From controlled Send to a useful paid API workflow.

Proposed milestone 1Reviewable Send pilot

Publish a reviewer-accessible deployment, document recipient and amount limits, then preserve one separately authorized transaction and a durable evidence record.

Proposed milestone 2One paid API workflow

Bind a provider response to the paid request, handle timeouts and duplicate requests, and distinguish payment confirmation from successful delivery.

Proposed milestone 3External builder validation

Work with a target of two external teams, record their actual attempts and failure cases, and publish reproducible integration guidance.