The clearing house for the agentic economyThe clearing houseclearing housepayment infrastructuretransaction layerclearing housefor the agentic economy

Yes, as long as the client and server can register the 4mica-credit scheme. Buyers add the scheme adapter to the fetch wrapper they already use; sellers configure their x402 middleware to advertise and verify it. You do not need to change your HTTP logic.

ETH and the ERC-20 tokens enabled by the active Core deployment. USDC and USDT are the defaults where enabled, and operators can configure others. A route only accepts the asset it advertises, so check the deployment's token list before going live.

Configured stablecoin collateral is supplied to Aave, and the protocol holds the interest-bearing aTokens. Collateral keeps accruing while capacity is reserved for guarantees, and the yield belongs to the collateral position — the payer — not the seller. Yield is variable and not guaranteed, so verify the current deployment configuration before depositing production funds.

It is the layer between authorising a payment and moving money. Instead of a transfer per request, buyers sign collateral-backed guarantees that are batched into clearing cycles. A cycle accepts guarantees, closes, computes net positions, and commits those positions on-chain — the same job a clearing house does for traditional payments.

Standard x402 turns every request into its own on-chain transfer. 4Mica's 4mica-credit scheme authorises the request against collateral-backed credit and settles later, so requests clear off-chain in one round trip and only net positions ever move on-chain.

x402 facilitators first: adding the 4mica-credit scheme lets every seller behind your endpoint take credit-backed payments, with 4Mica running as the clearing layer behind your brand. Then API and service providers who want to charge per request without accounts, invoices, or prepaid balances, and agent frameworks that want paid tool use built in. The fit is high-volume, low-value payments where checkout and invoicing infrastructure is the bottleneck.

Authorisation is separated from settlement. For each request, there is an off-chain signature and a Core verification — no chain write, no gas. Payable guarantees then enter a clearing cycle and settle as net positions: 40 outgoing and 27 incoming guarantees become a single net debit of 13, so one movement replaces 67. Netting changes settlement movement, not payment history — every individual record stays intact.

Yes. Base (eip155:8453) is the production network. Base Sepolia (eip155:84532) is the development network and Ethereum Sepolia (eip155:11155111) is there for cross-network compatibility testing. We recommend building against Base Sepolia first and moving to mainnet once your flows are tested.

Existing x402 facilitators add the 4mica-credit scheme to their /supported response, call Core from their settle logic to submit guarantees and return the BLS certificate, validate both V1 and V2 guarantee structures, and use CAIP-2 network identifiers. You can also point sellers at the hosted facilitator instead of running your own.

The buyer's signed commitment to pay a specific amount to a specific recipient. It binds payer, recipient, amount, asset, request ID, and timestamp, and travels with the request. Core verifies the signature and available collateral, then issues a BLS certificate — that certificate is what proves the guarantee was accepted.

Guarantees enter clearing cycles configured per deployment. A cycle accepts guarantees, closes, computes net positions, commits them on-chain, and opens the payment and finality windows. Check your deployment's parameters rather than assuming a fixed schedule.

V1 guarantees become payable once Core verifies them. V2 guarantees wait on a validation condition — a registry, validator, score threshold, and job hash committed in the signature — so payment is bound to an objectively verifiable outcome. 4Mica records signatures, certificates, lifecycle state, and settlement evidence; subjective quality, retries, and refunds stay a product policy decision.