Kordel documentation

Route model

Each route fixes one ERC-20 asset, a list of unique recipient addresses and basis-point shares that total 10,000. The route itself becomes the x402 payment recipient.

asset       USDG (mainnet)
recipients  unique addresses
shares      total 10,000 bps
payTo       route address

Payment asset: USDG on Robinhood Chain, 6 decimals. Factory: 0x31ac0fE95347989789373d05eF28F455DbFE6492.

x402 integration

The resource server returns an HTTP 402 response with an exact payment requirement. After the gateway or facilitator verifies settlement to the route, it serves the resource. Kordel does not replace verification, access policy or the resource server.

1. Client requests the protected workflow.
2. Server returns the exact asset, amount, network and route payee.
3. Client authorizes payment.
4. Gateway verifies settlement and releases the response.
5. Recipients claim their accrued route balances.

Receipt accounting

A recipient’s cumulative entitlement is total received multiplied by its fixed share. Claimed amounts are subtracted from that entitlement. Rounding dust stays in the route until later receipts make it distributable.

Stock Tokens may expose a display multiplier in application interfaces. Kordel accounting remains in raw token units and does not infer economic rights from a ticker.

Limitations and risks

Only explicitly verified standard ERC-20 assets should be enabled. Fee-on-transfer, rebasing and callback tokens require separate review. A direct transfer to a route is accounted as received value, but does not prove a workflow call occurred.

Recipients and shares cannot be changed after route creation. A mistaken recipient address cannot be repaired by an owner sweep. Contracts, payment assets, RPC endpoints and exit liquidity must be verified before mainnet use.