Scale your agentic revenue

AI agents work non-stop. Monetize every interaction without payment friction.

Fund once, earn continuously, and let your agents transact across any chain.

Read Docs

Earn while agents spend

Deposits generate yield that offsets costs

One pool, infinite endpoints

No per-channel collateral or prefunding

Spend now, settle later

Built-in credit with cryptographic guarantees

Gasless, cross-chain

Works across x402, MPP, and more

Explore the platform

How it works

Deposit once, spend anywhere

Collateral earns yield in Aave. Agents transact on credit. 4Mica settles later.

Start BuildingBrowse Docs

Collateral routes to Aave

Agent deposits once. Funds flow directly into Aave — earning APY while you spend. One pool, unlimited credit.

Deposit · step 1/5
await client.user.approveErc20(
usdc.address, AMOUNT
)
await client.user.deposit(
AMOUNT, usdc.address
)
✓ routed to Aave · aUSDC accrues yield

Trusted by

Partners that trust 4Mica

Teams running AVS compute, API monetization, and agentic commerce on 4Mica's credit layer

Aligned LayerChaosChain

Open-source core

Contracts and SDKs are public on GitHub

Testnet live

4Mica is live on testnet — deposit, spend, and settle today

Non-custodial

Collateral stays in Aave until settlement or on-chain claim

Start BuildingStar us on GitHub

Quick start

Integrate in seconds

Drop the middleware into your server and wrap your HTTP client. That's it.

1import { wrapFetchWithPaymentFromConfig } from "@x402/fetch";
2import { FourMicaEvmScheme } from "@4mica/x402/client";
3import { privateKeyToAccount } from "viem/accounts";
4
5const account = privateKeyToAccount("0xYourPrivateKey");
6const scheme = await FourMicaEvmScheme.create(account);
7
8const fetchWithPayment = wrapFetchWithPaymentFromConfig(fetch, {
9 schemes: [
10 {
11 network: "eip155:84532", // Base Sepolia
12 client: scheme,
13 },
14 ],
15});
16
17const response = await fetchWithPayment("https://api.example.com/resource");
18const data = await response.json();
Full docs at /resources/technical-docsSDKs: TypeScript · Python · Rust soon

Security model

Plain UX, hard guarantees

Keep funds on-chain and verify every claim before collateral moves

  • Non-custodial collateral stays in Aave until settlement or claim
  • Guarantees are BLS-signed with domain separation and versioned configs
  • AccessManaged roles, Pausable, and ReentrancyGuard protect critical flows

FAQ

Common questions

Defaults are pulled from Core4Mica contract parameters.

What is a payment tab?

A tab is a credit session opened by the recipient via POST /tabs. It is identified by a tabId, a TTL, and a guarantee version (V1 or V2). The version determines which on-chain decoder the contract uses when the recipient calls remunerate(). Each individual spend within the tab is tracked by a reqId, which increments with every signed guarantee.

What is a payment guarantee?

A guarantee is a signed claim the payer attaches to their request as an X-PAYMENT header. It carries tabId, reqId, userAddress, recipientAddress, amount, totalAmount, asset, and a timestamp. Payers sign with EIP-712 (default) or EIP-191. The facilitator verifies the signature and issues a BLS-signed certificate on-chain.

Do you support both V1 and V2?

Yes. V1 is the baseline EIP-712 signed guarantee flow. V2 extends it with a full on-chain validation policy — validationRegistryAddress, validationRequestHash, validationChainId, validationSubjectHash, and a jobHash — which gates remuneration on a passing ValidationRegistry status.

When can recipients claim collateral?

Recipients call remunerate() after the remunerationGracePeriod (default 14 days) and before tabExpirationTime (default 21 days). For V2 guarantees, the ValidationRegistry must also return a passing status that satisfies the signed policy before the contract releases funds.

When do users settle?

The product flow asks users to call payTabInERC20Token() after 7 days. If they do not, the recipient's on-chain claim window opens at 14 days (remunerationGracePeriod) and closes at 21 days (tabExpirationTime).

How do withdrawals work?

Users call requestWithdrawal() to start the timelock, then finalizeWithdrawal() once withdrawalGracePeriod (default 22 days) has elapsed. A synchronizationDelay (default 6 hours) prevents race conditions between a withdrawal request and a tab opened at the same time.

Which assets are supported?

ETH and stablecoins. Stablecoin deposits route through depositStablecoin() and are forwarded to Aave to earn yield. USDC and USDT are enabled by default; other ERC-20s revert unless explicitly configured.

How is a dispute handled?

With V2 guarantees, dispute resolution is fully on-chain via ERC-8004's ValidationRegistry. The payer signs a guarantee that commits to a validationRequestHash — a hash binding the specific validator, agentId, minValidationScore, requiredValidationTag, and jobHash to the exact payment claims (tabId, reqId, amounts, asset). When the recipient calls remunerate(), the ValidationRegistryGuaranteeDecoder checks the ValidationRegistry on-chain: if the validation is still pending, the response score is below minValidationScore, the validator or agentId don't match, or the tag doesn't match, the call reverts and collateral stays locked. Validators — stakers re-running the job, zkML verifiers, or TEE oracles — post a response (0–100) to the registry, and can update it multiple times for progressive finality.

How does the facilitator work?

The facilitator (x402-4mica) exposes /tabs, /verify, /settle, and /supported. POST /tabs issues a tab JSON with tabId and nextReqId. POST /verify checks the X-PAYMENT signature. POST /settle issues a BLS-signed certificate the recipient uses for on-chain remuneration.

Deposit once. Spend anywhere. Settle later.

Your collateral earns yield in Aave while your agents transact on credit — no prefunding, no gas per request.

Start Building