About 4Mica
What is 4Mica?
4Mica is a credit and clearing layer for x402 payments. Instead of sending an on-chain transaction for every paid HTTP request, a buyer signs a payment guarantee backed by deposited collateral. 4Mica verifies the guarantee quickly, groups payable obligations into clearing cycles, and settles net positions later. This makes frequent, low-value payments practical for agents, APIs, applications, and other automated services. Read the introduction for the basic model or how x402 works for the full request flow.Who is 4Mica for?
4Mica is for anyone building software that needs to buy or sell digital services programmatically. Common users include:- AI agents that pay for APIs, models, data, compute, storage, or other agents.
- API and agent developers who want to charge per request or per task.
- Marketplaces that need programmable payments between buyers and sellers.
- Infrastructure teams building x402 facilitators, wallets, or payment rails.
What is x402?
x402 is a machine-readable payment flow built around the HTTP402 Payment Required status.
A protected server returns the price and payment requirements in a 402
response. A compatible client chooses an accepted option, signs a payment, and
retries the same request with the payment attached. This lets software pay for a
resource without a traditional checkout flow or a pre-existing account with
the seller.
See how x402 works for the actors, headers, and
request sequence.
How is 4Mica different from a standard x402 payment?
4Mica authorizes each request with a collateral-backed guarantee and settles later, rather than transferring funds on-chain for every request. The4mica-credit scheme separates fast payment authorization from slower
on-chain settlement. Many obligations can be combined into a clearing cycle,
and only each participant’s net position needs to move on-chain. The standard
exact scheme is still useful when you want a direct transfer for each request.
Compare the flows in how x402 works and learn
about batching in bilateral netting cycles.
Is 4Mica a bank, wallet, or marketplace?
No. 4Mica is payment infrastructure. It provides protocol contracts, a facilitator, SDKs, middleware, and hosted tools for collateral-backed x402 payments. Your application can add wallets, marketplace discovery, identity, ratings, subscriptions, invoicing, and support workflows on top. See all products for the boundary between the protocol, facilitator, developer tools, and hosted app.What does the facilitator do?
The facilitator connects the seller’s HTTP payment flow to 4Mica Core. It verifies payment payloads, submits guarantees to Core, and returns settlement results and certificates. Buyers call the seller’s protected route; the seller’s middleware communicates with the facilitator from the server side. Read facilitator for its responsibilities and facilitator URLs for the safe endpoint model.Is 4Mica custodial?
4Mica is designed around protocol-controlled collateral and cryptographic authorization, not a centralized prepaid seller balance. Buyers deposit collateral into protocol contracts. Each payment is authorized by an EIP-712 signature, and settlement or default handling follows the protocol’s rules. Hosted services help operate the flow, but critical payment guarantees are enforced by signatures, collateral, and contracts. Read no custodial risk and security for the trust model.Accounts, wallets, assets, and networks
Do I need a 4Mica account?
You do not need a seller-specific account for every API you use. To pay with 4Mica credit, you need an EVM wallet or compatible signer and collateral registered on the network you plan to use. The hosted 4Mica app can make setup easier, while SDK integrations can manage the flow directly. Follow the quickstart to prepare a wallet and make your first request.Do buyers need to pre-fund every seller or API?
No. A buyer deposits collateral into 4Mica instead of maintaining a separate prepaid balance with every seller. Compatible payment flows can use that collateral to back guarantees, subject to the wallet’s available capacity, the active network and asset, and the buyer’s own spending policy. A seller may still require a particular asset, stronger prepayment, or additional application-level terms for expensive work. See deposits and withdrawals and buyer budgets.Do I need a wallet and gas?
Yes, you need a wallet or signer. You also need gas for actions that touch the blockchain, such as depositing, withdrawing, or settling. Ordinary payment guarantees are signed off-chain, so each paid HTTP request does not require its own blockchain transaction. For production, use a dedicated service wallet, hardware-backed signer, MPC wallet, or managed key system rather than a personal wallet. See the wallet setup in the quickstart and the wallet concept guide.Which assets does 4Mica support?
4Mica supports ETH and deployment-configured assets. USDC and USDT are the default stablecoins where the active deployment enables them. A route can only accept assets advertised in its payment requirements, so the buyer must use the same asset, network, and token address as the seller. Check supported networks before integrating, and inspect each route’s payment requirements for its accepted asset.Which networks are supported?
Base is the production network, while Base Sepolia and Ethereum Sepolia are available for development and compatibility testing. 4Mica identifies networks with IDs:- Base:
eip155:8453 - Base Sepolia:
eip155:84532 - Ethereum Sepolia:
eip155:11155111
Can I pay by card or bank transfer?
The native 4Mica flow uses a wallet, supported on-chain assets, and deposited collateral. An application can offer cards, bank transfers, or an internal balance as an on-ramp or user-facing funding method, but that application layer is separate from the 4Mica guarantee and settlement protocol. Learn what agents pay with in agentic payments.What costs should I plan for?
Plan for the seller’s price, eventual network gas, and the operating costs of your own application. One task can also trigger paid model calls, data access, compute, storage, retries, or downstream agents. 4Mica reduces the need for per-request on-chain settlement, but it does not remove those product costs. Show an estimate before work begins, enforce a maximum budget, and report actual spend when the task ends. Buyers should review hidden costs. Sellers should include all fulfillment costs in their pricing model.Paying for services
How does a buyer make a paid request?
The buyer uses a 4Mica-compatible client to call a protected URL. The server returns HTTP402 with its price and payment requirements. The
client checks those terms against policy, creates a unique request ID, signs a
guarantee, and retries the request. After verification, the server returns the
protected response.
Follow the buyer quick start or use the
automatic paid-request guide.
What is a payment guarantee?
A payment guarantee is the buyer’s signed commitment to pay a specific amount to a specific recipient. It binds the payer, recipient, amount, asset, request ID, and timestamp. 4Mica Core checks the signature and collateral before issuing a BLS certificate. The certificate tells the seller that Core accepted the obligation and provides the evidence needed for settlement or a default claim. Read transaction lifecycle for the signed fields, certificate fields, and states.How do I know the price before paying?
The server must advertise the price and accepted payment options before the client signs. Fixed prices appear in the HTTP402 payment requirements. For dynamic work,
the seller should provide a quote that identifies the task, maximum amount,
expiration, and completion rule. The buyer should reject any option that is
outside its budget or policy.
Buyers can configure controls with
budgets and spending limits. Sellers can
design clear terms with pricing and monetization.
Can I limit or approve what an agent spends?
Yes. Spending policy belongs in the buyer application. You can set limits per request, task, seller, category, asset, network, or time window. You can also require manual approval for new sellers, high-value payments, purchases, or any request that exceeds an automatic-spend threshold. If the budget is exhausted, the agent should stop before signing. See budgets and spending limits and safety and permissions.Can I stop an agent or revoke its payment authority?
Yes. Build an emergency stop path before allowing autonomous spending. Pause execution, disable signing, remove allowed sellers, lower budgets, revoke agent credentials where supported, and rotate the signer if necessary. Before withdrawing collateral, check for guarantees or settlement obligations that are still open. Use the revocation and emergency stop guide and review agent identity for delegated authority.How do I verify a seller before paying?
Compare the seller’s domain,payTo address, route metadata, and public profile
against a trusted source.
Do not sign if these values conflict. Reviews and reputation can help, but they
should complement address and domain verification rather than replace it. For
new sellers, start with a sandbox or a small paid test.
Use the checklist in trust and verification.
Can I see what each payment was for?
Yes, if your application records payment context with the task. Store the task ID, request ID, guarantee ID, seller, amount, asset, network, reason, policy decision, response status, and resulting artifact together. This produces an audit trail that can support receipts, invoices, debugging, and disputes. See payment proof and audit for recommended records and notification behavior.Who controls the data an agent can access, store, or share?
Your application controls data permissions; 4Mica handles payment evidence. Define what the agent may read, which sellers or tools may receive it, whether downstream sharing is allowed, and how long payloads and logs are retained. Redact sensitive fields before external calls. Check each seller’s privacy and retention terms, especially if inputs or outputs may be used for training or resale. See safety and permissions. For privacy-sensitive delivery evidence, follow proof and disputes.What happens if the result is wrong or the task fails?
Stop further spending, preserve the task and payment records, and follow the seller’s published retry, credit, or refund policy. 4Mica can prove payment authorization and settlement state, but it does not automatically decide whether subjective AI output was good enough. For outcomes that can be validated objectively, a V2 guarantee can make payment conditional on a trusted validation policy. Read quality and outcomes and proof and disputes.Can I get a refund?
Refund eligibility depends on the seller or application’s published policy. The parties should define what counts as non-delivery, technical failure, duplicate payment, or unacceptable output before the transaction. Payment and delivery logs help establish what happened. For very small payments, automated credits or retries may be more practical than manual refund processing. See buyer spending guidance and seller refund guidance.Selling APIs, agents, and digital services
What can I sell with 4Mica?
You can sell any digital service that can be delivered or initiated through an HTTP request. Examples include API responses, AI inference, agent tasks, datasets, search, compute, storage, media processing, and access to specialized tools. You can charge per request, per unit of usage, per task, or from a quote. See seller quick start and use cases.How do I add payments to an API?
Protect a route with 4Mica-compatible x402 middleware and configure its price, network, asset, and recipient address. The middleware should return402 before expensive work, verify or settle the
payment, and only then serve the protected response. Start with one inexpensive
route on Base Sepolia before adding dynamic pricing or production traffic.
Follow the seller quick start and
payment middleware guide.
Can I charge per request, usage, or completed task?
Yes. 4Mica supports several pricing patterns. Use a fixed route price for predictable calls. Meter tokens, compute, data, or time in your application for usage-based pricing. For uncertain work, quote the task first and use caps, stages, or validation rules so the buyer understands the maximum cost and completion condition. Compare the patterns in pricing and monetization.Can I charge fractions of a cent?
Yes, if the asset precision and your product economics support it. 4Mica avoids an on-chain transaction for every request, which makes tiny payments more practical. You should still account for compute, data, support, failed requests, settlement, and eventual network fees when choosing a minimum price. Use the checklist in microtransactions.Can other agents pay my agent automatically?
Yes. A compatible buyer agent can read the402 response, apply its spending
policy, sign a guarantee, and retry your route without human approval for every
request.
The buyer controls its authority and budget. The seller controls pricing,
accepted buyers, rate limits, and when paid work begins.
See agent-to-agent payments.
How do buyers know my service is legitimate?
Publish a consistent domain,payTo address, agent or service name, route
description, pricing terms, and support policy.
Use the same identity information in your documentation, marketplace profile,
registry listing, and payment requirements. This gives buyers a canonical
reference and makes impersonation easier to detect.
Follow trust and legitimacy.
When is it safe to deliver the paid response?
Deliver after the payment has passed the verification level appropriate for the cost and risk of the work. For inexpensive resources, you can settle directly and serve after success. For expensive compute, call the facilitator’s verification endpoint before doing the work, then settle when you are ready to accept the guarantee. Persist the returned certificate and connect it to your delivery record. See verify vs settle and payment middleware failure behavior.What if a buyer has insufficient collateral or does not settle?
Do not serve paid work when the guarantee cannot be issued. Core rejects a guarantee that is not adequately backed. If an accepted payable obligation later reaches default, the settlement process can use locked collateral to cover the recipient according to the active deployment’s rules and deadlines. Read microtransaction failure handling and transaction lifecycle.Can I block abusive or suspicious buyers?
Yes. Enforce controls in both your application and payment flow. You can rate-limit unpaid traffic and block by wallet, account, API key, IP, identity, domain, or observed behavior. Keep pre-payment work cheap, return402 before expensive execution, cap trials, and pause a route if activity
looks unsafe.
See risk and abuse prevention.
Settlement, validation, and yield
When does settlement happen?
Payable guarantees enter a clearing cycle and settle according to that deployment’s configured cycle phases. A cycle accepts guarantees, closes, computes net positions, commits the clearing result on-chain, and opens payment and finality windows. Timings are configuration values, so integrations should read current deployment parameters rather than hard-code assumptions from an example. See settlement cycle phases and settlements.What is bilateral netting?
Bilateral netting offsets what two parties owe each other before funds move. If two agents repeatedly buy from one another, 4Mica can reduce the gross set of obligations to a smaller net position. Clearing cycles then settle net debits and credits instead of every individual request. Read bilateral netting cycles.What is the difference between V1 and V2 guarantees?
V1 becomes payable after Core verifies it. V2 waits for its validation condition to resolve. Use V1 for known-party or agreed payments that do not need external outcome validation. Use V2 when payment should depend on a trusted validation registry, validator identity, score threshold, job hash, or other signed policy fields. See the V1 and V2 comparison.How are disputes handled?
Payment facts and delivery quality are separate questions. 4Mica records signatures, guarantees, certificates, lifecycle state, and settlement evidence. Your product policy handles subjective quality, retries, refunds, and support. For objectively verifiable jobs, V2 can enforce a signed validation policy before the obligation becomes payable or before the validation-based remuneration path succeeds. Read proof and disputes and the V2 lifecycle.Does deposited collateral earn yield?
Supported stablecoin deposits can earn yield when the active deployment routes them through its configured yield strategy. Yield behavior, rates, supported assets, and risk depend on the deployment and underlying protocol. Treat yield as variable rather than guaranteed, and verify the current configuration before depositing production funds. See earning yield for the protocol model.How do withdrawals work?
Withdrawals use a request-and-finalize process rather than an immediate exit. The delay gives the protocol time to account for open guarantees, clearing cycles, and claims. A withdrawal can only be finalized after the configured grace period and when no obligation prevents it. Check current deployment parameters instead of assuming a fixed duration. Read deposits and withdrawals.Integration and troubleshooting
Which languages and frameworks can I use?
4Mica provides integration paths for TypeScript and Node.js, Python, and Rust. The documentation also includes framework-specific quick starts for Next.js, Express, Hono, Nuxt, SvelteKit, Remix, Bun, FastAPI, and Flask. Choose the closest example, then use the backend SDK reference for lower-level control. Browse the quick-start guides and backend SDKs.Does 4Mica work with existing x402 clients and servers?
Yes, when the integration can register or advertise the4mica-credit scheme.
On the buyer side, add the 4Mica scheme adapter to an x402-compatible fetch or
request wrapper. On the seller side, configure middleware that advertises the
scheme and verifies signed guarantees. Your normal HTTP route and response body
can remain unchanged.
Start with the client integration or
server integration guide.
Should I test on mainnet?
No. Start on Base Sepolia with a dedicated test wallet and small amounts. Test successful payments, unsupported networks, insufficient collateral, duplicate request IDs, rejected signatures, budget limits, timeouts, retries, seller mismatches, and any refund or dispute workflow before using production funds. Use the buyer sandbox checklist or seller sandbox checklist, then review the matching go-live guide.How can my application monitor payment and collateral changes?
Use durable application logs for request-level context and webhooks for asynchronous state changes. Webhooks can update dashboards, entitlements, collateral state, and settlement status after the original HTTP request has finished. Verify every webhook signature, store event IDs, ignore duplicates, and fetch current state when events arrive out of order. Start with the webhooks overview, then follow the webhook security guide.Why did my paid request fail?
Most failures come from network, collateral, price policy, seller identity, signature, request ID, or facilitator configuration. Do not retry blindly. Record the task and request IDs, seller domain,payTo
address, amount, asset, network, failure reason, and retry count. Retry temporary
transport errors with a small backoff limit; do not automatically retry policy,
identity, or over-budget failures.
Use error handling for diagnosis and safe retry rules.
What should I do if a payment looks suspicious?
Stop before signing or serving more work. Verify the domain,payTo address, network, asset, amount, and request history.
Pause the agent or route, preserve logs, disable automatic
signing if necessary, and rotate a key if you believe it was exposed. Review
open obligations before attempting to withdraw collateral.
Buyers should follow trust and verification.
Sellers should follow risk and abuse prevention.
What should I never put in logs or support messages?
Never share a private key, seed phrase, raw signing secret, or unrestricted credential. Share public wallet addresses, transaction hashes, request IDs, guarantee IDs, timestamps, network IDs, route URLs, and redacted error messages instead. Remove personal data and confidential request content unless it is necessary and safe to disclose. Review security before moving to production.Where can I get more help?
Check the role-specific guide first, then send a concise diagnostic report to support@4mica.io. Include:- Whether you are a buyer, seller, or infrastructure operator.
- The network and asset.
- The affected route and public wallet addresses.
- Request, guarantee, cycle, or transaction identifiers.
- The time of the failure and the exact error message.
- What you expected and what happened instead.