Risk management

Risk management in 4Mica is about making exposure explicit. 4Mica lets agents pay at machine speed by accepting signed guarantees before final settlement is complete. That creates a powerful user experience, but it also introduces a real risk surface: buyers can sign too much, sellers can serve before final settlement, collateral can be locked, validation can fail, settlement windows can be missed, and integrations can mis-handle payment evidence. The goal is not to pretend those risks disappear. The goal is to identify where each risk lives, which layer controls it, and what a user or builder should monitor.

​

The core tradeoff

4Mica separates request-time access from final settlement. At request time, the buyer signs a guarantee, Core verifies it, and the seller can serve. Later, payable guarantees enter netting cycles and settle as net positions. Collateral protects the delay between those two moments. This architecture improves speed and capital efficiency, but it means every participant should understand the difference between: Risk management is the discipline of keeping those questions separate.

​

Risk map

The full 4Mica process has several categories of risk. No single mechanism manages all of these. Collateral helps with settlement risk; it does not decide buyer intent. Signatures protect payment fields; they do not prove output quality. Validation can gate payment; it does not replace key management.

​

Buyer intent risk

Buyer intent risk is the risk that an agent signs a payment it should not have signed. The payment can be perfectly valid at the protocol level and still be a bad purchase. The seller may be fake, the price may be too high, the route may not match the task, the agent may be looping, or the request may leak sensitive data. Before signing, buyer policy should check: Read trust and verification and safety and permissions for buyer-side policy design.

​

Signer and wallet risk

Signer risk is the risk that a key authorizes payments outside the user’s intent. This can happen because the key is stolen, copied into an unsafe environment, shared too broadly, or attached to an agent with weak policy. It can also happen without a key leak if the signing service blindly signs whatever the agent asks for. The safest pattern is: Important controls include dedicated wallets, environment separation, scoped signing services, key rotation, emergency pause, and least-privilege access to signing infrastructure. Read wallet and security for the wallet and signer security model.

​

Payment integrity risk

Payment integrity risk is the risk that a payment is malformed, replayed, redirected, or interpreted differently by the buyer and seller. 4Mica reduces this risk with structured signed guarantees. The payer signs the specific payer, recipient, request ID, amount, asset, timestamp, version, and V2 validation policy where applicable. Core verifies the submitted fields against the signature and rejects duplicate guarantee identities. Integrations still need to handle the surrounding application behavior: See how x402 works and transaction lifecycle for the payment fields and lifecycle states.

​

Collateral and capacity risk

Collateral risk is the risk that available capacity is misunderstood. A wallet may own deposited collateral but still be unable to spend or withdraw because capacity is locked behind accepted guarantees, pending validation, active cycles, settlement windows, or default handling. The raw deposit is not the same as available payment capacity. The key states are: Collateral ratios create a buffer between deposited value and guarantee capacity. That buffer protects sellers, but it can surprise buyers who expect every deposited unit to become spendable immediately. Read deposits and withdrawals and collateral ratios before relying on a wallet’s capacity for production traffic.

​

Asset and yield risk

Supported collateral assets can carry different risks. Stablecoins reduce price volatility compared with many crypto assets, but they are not risk-free. A stablecoin can face issuer risk, liquidity risk, contract risk, depeg risk, freeze or pause behavior, network congestion, or operational issues around token decimals and addresses. Where configured, 4Mica can use Aave under the hood for supported stablecoin collateral. That can keep collateral productive, but it introduces an external protocol dependency. Users should understand that Aave brings its own contract, market, liquidity, governance, and asset risks. Read no custodial risk for where Aave fits and earning yield for the purpose of yield-bearing collateral.

​

Settlement and default risk

Settlement risk is the risk that a payable obligation does not resolve through the normal payment path on time. After guarantees enter a netting cycle, the system computes net debtor and creditor positions. Net debtors need to pay during the payment window. If they miss the finality deadline, eligible claims can move to default coverage from locked collateral. Default coverage protects sellers, but default is still a negative operational outcome. It can reduce the payer’s collateral, damage trust, and indicate that payment automation or funding controls failed. Buyers should monitor upcoming payment windows and maintain enough settlement funds. Sellers should monitor whether credits become claimable, paid, or default-covered. Read bilateral netting cycles and settlements for the cycle and finality model.

​

Validation and SLA risk

V2 guarantees can make payment depend on validation. That is useful when the buyer wants evidence that a job met agreed conditions before it becomes payable. It also adds a new risk surface: Good validation policies are specific before signing. They bind the registry, validator, subject, job, score threshold, and required tag in a way Core and the contracts can verify. Read configurable SLAs and transaction lifecycle for V2 validation behavior.

​

Seller delivery and quality risk

Seller risk is not only “will I get paid?” It is also “can I prove what I delivered?” A seller should keep delivery records that connect the paid request to the work performed. This matters for support, disputes, refunds, abuse investigation, and reconciliation. Good seller controls include:

• return a 402 before expensive work;
• verify or settle payment before serving protected output;
• define completion criteria for each paid route;
• keep request, payment, delivery, and settlement records together;
• make retries idempotent;
• cap expensive jobs for unknown buyers;
• publish refund or failure policies where relevant.

Read seller risk and abuse prevention and proof and disputes for route-level guidance.

​

Smart-contract and deployment risk

4Mica reduces reliance on private ledgers, but smart contracts and deployment configuration still matter. Users and integrators should verify: Use GET /core/public-params, GET /core/tokens, and supported networks as references for active configuration.

​

Facilitator and API risk

The facilitator helps sellers validate and submit payments, but it is still a trust boundary. Risks include facilitator downtime, stale configuration, misconfigured URLs, incorrect assumptions about supported schemes, and sellers serving content after only a weak or local check. Sellers should:

• configure the intended facilitator URL per environment
• verify payment requirements match the route being served
• call /verify before expensive work when appropriate
• call /settle before treating the payment as accepted
• persist the returned certificate or receipt
• handle facilitator errors without serving unpaid work

Read facilitator, payment flow, and the Facilitator API reference.

​

Webhook and observability risk

Events are useful only if they are verified and processed safely. Webhook risks include forged events, replayed deliveries, duplicate processing, out-of-order events, missing retries, and accidental logging of secrets or sensitive bodies. Secure event handling should verify signatures over the raw body, check timestamps, store event IDs, process idempotently, queue work after verification, and reconcile against Core state when needed. Read webhook security, webhook best practices, and webhook FAQs.

​

Abuse and economic risk

Agents move quickly. Small mistakes can become expensive when repeated many times. Common abuse patterns include: Risk controls should match route cost. A tiny deterministic lookup and a long-running compute job should not use the same limits.

​

Operational risk

Operational risk is the everyday risk that systems fail in boring ways: network outages, RPC issues, clock drift, queue delays, database bugs, stale configuration, failed token approvals, retry storms, or missing logs. Production integrations should monitor: If an integration cannot observe a lifecycle state, it should be conservative about spending, serving expensive work, and withdrawing collateral.

​

Risk ownership

Different parties own different risks. This division matters. If a buyer signs an allowed payment to a fake seller, that is not the same failure as a bad signature or insufficient collateral. If a seller serves before settlement acceptance, that is not the same failure as a debtor default. Naming the layer makes the response clearer.

​

Practical mitigation checklist