Asset & recipient
First narrow which asset can be sent, and to whom.
Builders open a paid route with one line of Hono middleware; a shop with no server gets a payment URL instead. Customers order from a desktop agent and pick up in person. What arrives is tUSDC on GIWA Sepolia — testnet, not real money.
SCOPEASSET + PAYEESpecifies the asset to spend and the payee to pay
BUILT ON OPEN RAILS
The numbers are not fixed in the product. Each grant is composed for its purpose, and the agent cannot step past the engraved scope.
First narrow which asset can be sent, and to whom.
Set the cap for a single payment and for spending over a period.
The chain itself checks when the grant begins and ends.
When needed, revoke the grant immediately instead of waiting for expiry.
The agent requests a paid resource and receives the 402 payment terms.
The agent builds a one-time permission carrying only this payment's amount and recipient.
The chain checks that the asset, cap, period, and recipient are within the delegated scope.
Only transactions that pass are settled on GIWA by the relayer.
Once the settlement receipt is confirmed, the resource opens to the agent.
What will execute is simulated as-is before settlement. A payment outside the granted scope is never broadcast — no funds move, no gas is wasted.
See the trust boundaries in the technical docstransfer-amount-exceededexpired-delegationinvalid-calldataThe links below are delegated payments actually settled on testnet. They are public evidence of technical behavior, not fixed product limits or operating metrics.
The current public evidence was produced with GIWA Sepolia test assets. It does not indicate operational readiness for real-value assets.
Start autonomous payments without handing over your wallet.