Skip to main content
A netting cycle is the accounting window where many accepted payment guarantees are grouped together and reduced into the amounts participants actually need to settle. Without netting, every paid API call, agent-to-agent request, model invocation, or data purchase would need its own final settlement action. That works poorly for machine-speed commerce. Agents may create many small obligations in both directions during the same task, and settling every one independently would add cost, latency, and operational noise. 4Mica uses cycles so the HTTP payment experience can stay fast while settlement happens in larger, more efficient batches. The core idea is simple:
Track every accepted payable guarantee, then settle the difference instead of settling every request one by one.

​
Why netting exists

Agent payments are often small, frequent, and bidirectional. One agent may buy data, sell analysis, call another model, provide a result to a third service, and receive payment back during the same operating period. If all of those obligations settled separately, the system would inherit the worst parts of blockchain settlement: many transactions, repeated gas costs, more reconciliation work, and more chances for delays to interrupt the user experience. Netting separates two moments: This is what lets 4Mica support instant-feeling x402 payments without requiring an on-chain transfer for every HTTP request.

​
What “bilateral” means

Bilateral netting looks at obligations between two counterparties and collapses opposite-direction claims into one net result. If Alice owes Bob for several requests, and Bob also owes Alice during the same cycle, those obligations can offset each other. The side that owes more becomes the net debtor for that relationship. The other side becomes the net creditor.
The original guarantees still matter. They prove how the net result was calculated. Netting does not erase payment history; it reduces settlement movement.
This page explains the concept of bilateral netting. A deployment may also aggregate positions across many participants and assets during a cycle. The important user-facing idea is that accepted guarantees become auditable inputs to a net settlement result.

​
The cycle model

A cycle is a bounded period of time. During the open part of the cycle, Core accepts payable guarantees into the batch. When the cycle closes, the batch is fixed. Core then computes debtor and creditor positions and commits the result for settlement. The cycle is the bridge between individual HTTP payments and final economic settlement. A seller does not need to wait for the cycle to complete before serving a request, because Core has already verified the guarantee and locked capacity. But final settlement still waits for the cycle process.

​
Which guarantees enter a cycle

Only payable guarantees enter netting. V1 guarantees usually become payable immediately after Core verifies the signature, accepted version, and collateral. V2 guarantees begin in PENDING_VALIDATION and enter netting only after they become FINALIZED_PAYABLE. This distinction is critical for V2. A V2 guarantee can lock collateral before it becomes payable, but it should not affect a clearing cycle until the validation lifecycle says it is ready. Read transaction lifecycle for the full V1 and V2 state model.

​
A simple example

Suppose two agents exchange several payable guarantees during the same cycle: Before netting, there are five payable guarantees:
Instead of settling five separate payments, the cycle can settle the net position. Alice is the net debtor for 20, and Bob is the net creditor for 20. The seller still has records for every individual paid request. Netting changes how value moves at settlement time, not what was bought or which guarantee authorized it.

​
How a guarantee moves through a cycle

The seller-facing request can complete long before final settlement. The accepted certificate is what lets the seller serve the resource before the cycle finishes. Settlement later determines whether the obligation is paid through the net debit path or covered through the eligible default path.

​
Cycle phases

Cycle timing is deployment-specific, but the lifecycle has a consistent shape: The transaction lifecycle page documents one default schedule:
Treat these timings as deployment parameters, not universal constants. A buyer or seller should rely on the active operator configuration and observed cycle state rather than assuming every network uses the same schedule.

​
Netting and collateral

Netting reduces settlement movement, but it does not remove the need for collateral. When Core accepts a guarantee, it locks enough capacity to back that obligation. The guarantee may not settle until a later cycle, but the seller has already served the resource. Collateral keeps that delayed settlement promise credible. The relationship is:
  • netting makes settlement more efficient;
  • collateral makes delayed settlement safe enough to accept;
  • collateral ratios decide how much unresolved exposure a wallet can create.
See collateral ratios for how deposited collateral turns into usable payment capacity.

​
Netting and withdrawals

Collateral that secures open cycle obligations cannot be treated as freely withdrawable. A wallet may have deposited funds and still be unable to withdraw all of them because some capacity is locked behind guarantees in an open cycle, a committed clearing result, a payment window, a pending validation path, or a possible default claim. Withdrawal becomes safer after the relevant obligations resolve: This is why withdrawals are not purely about wallet ownership. They are about ownership after accepted obligations have been respected. Read deposits and withdrawals for the complete withdrawal lifecycle.

​
Buyer view

For a buyer, netting means a signed payment may not cause an immediate transfer. The buyer authorizes a guarantee, Core locks capacity, and the final amount owed can be resolved later through the cycle. This gives buyers operational efficiency, especially when they both buy and sell during the same cycle. Incoming credits can offset outgoing debits before final settlement. It also creates responsibilities:
The buyer should not assume a completed API response means collateral is immediately reusable or withdrawable. The guarantee may still be waiting for cycle settlement.
Application budgets should include guarantees that have been accepted but not yet settled, cancelled, or default-resolved.
A buyer with a net debit must be able to pay during the payment window. Missing the deadline can trigger default handling.
Netting does not merge incompatible assets or networks into one settlement pool. The payment terms still define the asset and network.
The buyer experience is fast, but the accounting lifecycle continues in the background.

​
Seller view

For a seller, the important event is not the final cycle close. It is Core accepting the guarantee and returning verifiable payment evidence. Once Core accepts the guarantee, the seller can serve according to its own risk policy because the obligation is now part of the protocol lifecycle. Later, the seller’s payable guarantees contribute to a net creditor position, offset against any obligations the seller owes in the same cycle. Sellers should keep records that connect: Netting makes settlement efficient, but it does not replace seller-side observability. Sellers still need payment records for reconciliation, support, abuse handling, and audit.

​
What happens if a debtor does not pay

Cycles include a finality deadline so settlement does not remain ambiguous forever. If a net debtor pays during the payment window, creditors can claim according to the committed clearing result. If the debtor misses the deadline, the uncovered eligible position can move to default handling. Locked collateral can then be used to cover the claim according to protocol rules. This is where collateral, ratios, and netting meet: Default handling is not a normal payment path to optimize for. It is the safety mechanism that makes delayed settlement credible when the expected debtor payment does not arrive. Read settlements for the settlement and default outcome model.

​
What netting does not do

Netting is an accounting and settlement mechanism. It does not change the meaning of the original payment instructions. It does not:
  • let a payer change the amount or recipient after signing;
  • make non-payable V2 guarantees payable without validation;
  • merge different assets into one obligation unless the deployment explicitly supports that accounting model;
  • remove the need for collateral while settlement is pending;
  • replace seller access controls, buyer budgets, or application policy;
  • erase the audit trail of individual guarantees.
The signed guarantee remains the source of truth for the individual payment. The cycle explains how many signed guarantees are settled efficiently together.

​
Common questions

Usually no. The seller can serve after Core accepts the guarantee and the seller’s own risk checks pass. The cycle handles final settlement later.
Yes. If two counterparties owe each other the same amount in the same asset and cycle context, the net amount can be zero. The individual records still remain for audit.
Yes. If it becomes payable after the cycle closes, it waits for a later eligible cycle. V2 guarantees can also wait while validation is pending.
No. Netting reduces settlement movement. It does not discount the accepted payment amount or erase the seller’s claim.
The final net result is not known until the cycle resolves. Collateral stays locked so sellers remain protected during that uncertainty.

​
Practical mental model

Think of a netting cycle as the protocol’s accounting day. During the day, agents make many small payments. Sellers can serve as soon as Core accepts each guarantee. At the end of the accounting window, the protocol adds up who owes whom, offsets opposite-direction obligations, commits the result, and lets only the net amounts settle.

Fast requests

The HTTP interaction completes when the guarantee is accepted, not when the final settlement batch finishes.

Fewer settlements

Many payable guarantees can collapse into a smaller set of net debtor and creditor positions.

Protected delay

Collateral stays locked while the cycle runs so delayed settlement does not become an unsecured promise.
Netting is what makes high-volume agent commerce practical. Collateral is what makes the wait safe. Settlement is what turns the net result into final economic movement.