How much value can this wallet safely guarantee before the protocol should stop accepting more exposure?That answer matters to both sides of a payment. Buyers want as much usable capacity as possible from their collateral. Sellers want confidence that an accepted guarantee is backed by enough value to survive the clearing and settlement window.
The basic idea
Collateral ratios are easier to understand if you separate three numbers:| Number | Meaning |
|---|---|
| Deposited collateral | The finalized asset value attributed to a wallet. |
| Credit capacity | The maximum value the protocol allows the wallet to guarantee from that collateral. |
| Locked exposure | The portion of capacity already reserved for unresolved guarantees or obligations. |
Exact collateral factors are deployment-specific. Integrations should discover
active configuration from the operator and should treat the examples on this
page as mental models, not fixed production parameters.
Why 4Mica needs a buffer
4Mica payments are designed to feel instant at the HTTP layer. A seller can serve a protected resource after Core accepts a signed guarantee, even though the final movement of funds may happen later through clearing, settlement, or a default path. That delay is what makes collateral policy important. If every dollar of collateral could be promised immediately, even a small delay or accounting mismatch could make sellers underprotected. A ratio keeps some margin inside the system so guarantees can remain credible while payments move through their lifecycle. The buffer protects against several ordinary conditions:- prices, decimals, and asset values being interpreted incorrectly
- guarantees that remain open until a clearing cycle closes
- V2 guarantees waiting on validation
- pending withdrawals reducing future capacity
- settlement windows where a debtor has not paid yet
- defaults that must be covered from locked collateral
- operational delays in event indexing or finality
Ratio, collateral factor, and overcollateralization
Different teams describe collateral policy in different ways. The same policy can be expressed as a collateral factor or as an overcollateralization ratio.| Expression | Example | Meaning |
|---|---|---|
| Collateral factor | 90% | Each $1 of collateral supports up to $0.90 of guarantees. |
| Overcollateralization ratio | 111.11% | Each $1 of guarantees requires about $1.11 of collateral. |
| Required buffer | 10% | A portion of the deposit remains outside usable capacity. |
What counts as eligible collateral
Not every token balance in a wallet counts toward 4Mica payment capacity. To become eligible, collateral must be deposited through the supported collateral flow, recognized on the correct network, and accepted by the active deployment. A token in the wallet, an allowance, or a pending transaction is not enough. For a deposited asset to contribute to capacity, Core needs to know:| Requirement | Why it matters |
|---|---|
| Network | Collateral on one chain cannot automatically back guarantees on another chain. |
| Asset address | Symbols like USDC or ETH are not enough to identify the asset safely. |
| Decimal precision | Amounts are accounted in base units, not human-formatted decimals. |
| Finality | The deposit event must be reliable enough for Core to use. |
| Deployment policy | The operator must support the asset and assign risk parameters. |
| Existing obligations | Already accepted guarantees reduce remaining capacity. |
How ratios affect a payment
When a payer signs a guarantee, Core checks more than the signature. It also checks whether the wallet has enough available capacity after the collateral ratio and existing locks are applied. The seller should treat Core acceptance as the important signal. A buyer may claim to have funds, but the guarantee is not useful until Core verifies the signed fields, policy, accepted version, and collateral. Read transaction lifecycle for how guarantees move from issuance through validation, netting, settlement, and default coverage.Locked exposure is not the same as spent money
When Core accepts a guarantee, it reserves capacity. That reservation is called locked exposure. It prevents the same collateral from backing too many payments at once. Locked exposure can resolve in different ways:| Outcome | What happens to capacity |
|---|---|
| Guarantee settles normally | The obligation is paid through settlement and capacity unlocks. |
| Guarantee is cancelled or expires under protocol rules | The reserved capacity can unlock. |
| V2 validation remains pending | Capacity stays reserved until the validation lifecycle resolves. |
| Debtor defaults | Locked collateral can be used to cover the eligible claim. |
Ratios and withdrawals
Withdrawals are constrained by the same capacity math. A wallet can only withdraw collateral that is not needed for accepted guarantees, pending settlement, validation-gated obligations, active withdrawal delays, or default coverage. If removing collateral would make the remaining position undercollateralized, the withdrawal should not be finalized.Ratios and yield
4Mica can use yield-bearing infrastructure such as Aave for supported stablecoin collateral. That makes collateral productive while it backs payment capacity, but it does not remove the need for conservative ratios. Yield and collateral capacity answer different questions:| Concept | Question |
|---|---|
| Yield | Can idle or locked collateral earn while it remains deposited? |
| Collateral ratio | How much payment exposure can that collateral safely support? |
Asset quality changes the ratio
A stable, liquid, widely supported asset can usually support a higher collateral factor than a volatile or thinly traded asset. Even among stablecoins, different assets can carry different risks. The ratio may account for:| Risk input | Why it affects capacity |
|---|---|
| Price stability | Volatile assets need a larger buffer before settlement completes. |
| Liquidity | Collateral is less protective if it cannot be converted or claimed reliably. |
| Smart-contract path | Depositing through another protocol adds dependency risk. |
| Network finality | Slower or less reliable finality increases timing risk. |
| Token behavior | Pausable, upgradeable, rebasing, or non-standard tokens may need stricter treatment. |
| Oracle or valuation method | Any external pricing dependency can introduce stale or incorrect values. |
| Concentration | Too much exposure to one asset, wallet, or counterparty can raise systemic risk. |
Netting makes ratios more efficient
Collateral ratios exist because individual guarantees create exposure. Netting reduces how much value ultimately has to move. If two participants owe each other throughout a cycle, the clearing system can settle only the net amount instead of moving value for every individual request. This is one reason 4Mica can support many small agent payments without forcing a blockchain transaction for each request. Netting does not eliminate collateral requirements. Sellers still need protection during the period before the net result is known and settled. The ratio defines how much unresolved exposure the protocol is willing to accept while waiting for that result. For more detail, read bilateral netting cycles and settlements.Capacity is not a spending budget
Available capacity tells a buyer what the protocol may accept. It does not tell the agent what it should buy. A wallet might have enough capacity to sign a payment, while the buyer’s own policy rejects it because the seller is unknown, the task is low value, the price is too high, the route is suspicious, or the daily budget has already been used. Keep these two layers separate:| Layer | Decision |
|---|---|
| Protocol capacity | Can this wallet back the guarantee under current collateral rules? |
| Buyer policy | Should this agent authorize the payment for this task? |
Accepted capacity is the signal
A seller does not need to inspect the buyer’s raw deposit and calculate every internal policy rule itself. The seller needs a verifiable indication that the payment was accepted under the active protocol rules. In a 4Mica flow, that signal is Core accepting the guarantee and returning a certificate. The certificate means Core verified the signed payment fields and locked the required capacity for that obligation. This still leaves normal seller decisions outside the collateral ratio:- whether the buyer is allowed to access the resource
- whether the requested work is legal and safe to serve
- whether the payment amount matches the protected route
- whether the seller accepts the facilitator and network
- whether additional application-level authentication is required
When capacity is insufficient
If a guarantee is rejected because capacity is insufficient, it does not always mean the wallet has no money. It may mean the deposit is pending, the asset is unsupported, too much capacity is already locked, a withdrawal is in progress, or the requested amount would exceed the ratio. Common causes include:The deposit is not finalized or synchronized
The deposit is not finalized or synchronized
A transaction receipt is not always enough. Core must observe a finalized
deposit event and update the wallet’s collateral state before the collateral
can support guarantees.
The wallet is using the wrong network
The wallet is using the wrong network
Collateral on Base Sepolia does not automatically support a guarantee
advertised for Base mainnet, and vice versa.
The asset does not match the seller's terms
The asset does not match the seller's terms
A wallet may have deposited one token while the seller requires another.
Asset address and chain are the identifiers that matter.
Existing guarantees are still open
Existing guarantees are still open
Capacity can remain locked until settlement, validation, cancellation, or
default handling finishes.
The requested payment is too large
The requested payment is too large
Even with enough total collateral, the guarantee may exceed the wallet’s
available capacity after the collateral factor is applied.
A withdrawal reduced usable collateral
A withdrawal reduced usable collateral
Pending or finalized withdrawals can reduce the collateral available to
back new guarantees.
Reading ratio information
Applications should avoid hard-coding collateral rules. The active deployment may change supported assets, accepted versions, validation registries, contract addresses, or other public parameters over time. At minimum, integrations should use:GET /core/public-paramsfor public contract, signing, guarantee, and validation configuration;GET /core/tokensfor supported token addresses, chains, and decimals;- the facilitator verification and settlement responses for whether a specific payment was accepted.