Mint and burn lifecycle

Understand how mint-style and burn-style asset records can appear around 0Pools movement, settlement, and reconciliation.

0Pools can sit next to asset issuance, redemption, swap, and settlement records. Some corridors may involve mint-style or burn-style activity around a configured 0Asset; other corridors may only move fiat and stablecoin balances. Either way, developers need a lifecycle model that connects pool quotes and trades to asset activity without relying on reserve claims, custody details, or unsupported redemption promises.

The model below covers records such as a 0COP mint event, a 0MXN burn event, or an asset movement that later appears in a swap, pool, payment, settlement report, or scan view. It explains status and reconciliation behavior; it does not mean every asset, corridor, or payout method is enabled for every account.

What this page covers

The lifecycle for mint-style and burn-style records.
Which identifiers to store so teams can reconcile activity.
How mint/burn records relate to 0Gate, 0Pools, 0Base, 0Link, and 0Pools Scan.
Which claims should not be presented unless they are part of your approved product surface.

Where mint/burn fits in 0Pools

0Pools should be the stable product abstraction. The partner should not build against a private issuance engine, a custody workflow, or a provider-specific burn route. They should store the pool record, then attach any approved asset activity records that 0Bit exposes for the workflow.

Lifecycle model

Stage	Public-safe meaning	Store or display
Configured asset	The symbol can appear in approved product contexts.	Asset symbol, fiat reference, environment, product area.
Event created	A mint-style or burn-style record exists.	Event id, asset, amount string, status, timestamp, source product.
Product reference	The event can be related to a payment, pool, swap, link, or ledger record.	Session id, quote id, trade id, transaction id, report id, partner reference.
Indexed activity	The event can become visible in 0Pools Scan where indexing is enabled.	Scan record id, status, related product links.
Reconciliation	Operations compare product records, reports, scan visibility, and partner records.	Request id, event id, settlement/report period, final status.

Status model

Use simple status language unless a product-specific API exposes a stricter contract.

Status	Meaning	Integration behavior
`created`	A mint or burn record has been accepted or observed.	Store ids and show a non-terminal state.
`processing`	Related product or settlement work is still moving.	Avoid duplicate writes; wait for signed events or trusted reads.
`indexed`	The activity is visible in a scan or activity view.	Link to the scan record for investigation, not as accounting truth by itself.
`completed`	The product workflow reached a terminal success state.	Reconcile against product records and reports before final accounting.
`failed`	The workflow did not complete.	Preserve ids and request ids for support.
`reconciled`	Activity was matched to approved reports or records.	Use for investigation and accounting review; do not treat it as standalone legal proof.

Example traces

Example	Useful for	Safe wording
`0COP` mint event	Showing how a configured 0Asset supply-changing event can appear in scan and reconciliation views.	"A mint-style activity record for 0COP was recorded and can be reconciled where the product is enabled."
`0MXN` burn event	Showing a burn/redeem-style lifecycle without promising payout timing.	"A burn-style activity record for 0MXN can be tracked through status and settlement-aware records."
`0EUR -> USDT`	Showing an asset pair through swaps, pools, or payment-style movement.	"A configured asset example used for partner-scoped availability checks."
`USDT -> 0NGN`	Showing a reverse route into a configured 0Asset.	"Availability depends on entitlement, environment, liquidity, and compliance review."

Example: pool trade with a later asset event

Step	Record	Developer behavior
User accepts quote	`quote_id` and quote expiry	Freeze the accepted terms in your order record.
Partner executes quote	`trade_id`	Move the order to a reserved or processing state.
Settlement progresses	Trade status update	Keep polling or process signed webhook events.
Asset event appears, if enabled	Mint/burn event id or scan id	Attach it as evidence, not as the only accounting source.
Reconciliation closes	Report or ledger row	Match quote, trade, asset event, amount strings, and partner reference.

Before and after

Before 0Pools	With 0Pools
Product teams had to explain token supply events and payment settlement as one messy flow.	The pool trade is the commercial execution record; mint/burn records are attached where relevant.
Support agents searched wallet activity without knowing which user order caused it.	Quote, trade, request, and event ids provide a joined trail.
Product pages risked implying reserve proof or guaranteed redemption.	The lifecycle stays at status, record, and reconciliation level.
Every asset route needed custom user copy.	User copy can say "processing", "settled", "failed", or "returned" while operations handle asset-specific details.

Product visibility

Product	How mint/burn context can appear
0Gate	A payment or ramp flow can reference asset capabilities, target assets, transactions, and settlement-aware records.
0Pools	Quotes and trades can reference configured assets, quote counterparts, pool activity, and partner-visible statuses.
0Base	Reports, ledgers, payment objects, and transaction records can carry normalized asset fields where reviewed.
0Link	Connected workflows can carry asset context into a payment, swap, account, or transaction link.
0Pools Scan	Search and detail pages can group activity by asset, event type, status, and related product id.
Operations	Reconciliation pages join events, product reads, webhooks, settlement reports, and support records.

Product boundary

Do not use mint/burn status to imply:

reserve balances
bank account details
custody or signer operations
provider or venue identities
legal redemption guarantees
fixed settlement cadence
unsupported country, rail, or asset availability
proof-of-reserves or attestation language

The product surface supports asset capability reads, settlement/report concepts, and scan visibility. Liquidity, treasury, reserve, provider, and onchain prototype details are outside the partner integration contract. Keep your integration at the record, status, and reconciliation level.

User-facing language

Use plain status language that explains the user's order without overclaiming the asset mechanics:

Situation	Better wording	Avoid
Pool trade is accepted	"Your conversion is locked and processing."	"Your token is guaranteed."
Asset activity is indexed	"Related asset activity is visible for investigation."	"This scan page proves reserves."
Settlement is delayed	"The trade is still processing; keep the reference id for support."	"The rail/provider is delayed."
Corridor is not enabled	"This asset or route is not available for your account."	"0Pools does not support this country."

Implementation checklist

Store amounts as decimal strings where APIs expect string amounts.
Store asset symbols exactly as returned by the product API.
Keep partner order ids or user references separate from 0Bit ids.
Verify signed webhooks before mutating durable records.
Link scan views for support visibility, not as the only truth source.
Reconcile against product reads and reports before final accounting.
Confirm asset support, regional availability, and live status before presenting production availability to users.

Asset event boundary

Mint and burn language can create confusion if it is used too early in the user journey. Use it only when the product has an asset event or settlement record that justifies it.

Stage	Safe wording	Avoid
Firm quote	"Rate locked until expiry."	"Tokens minted."
Reserved trade	"Transfer processing."	"Stablecoin delivered."
Settlement pending	"Awaiting final status."	"Burn completed."
Terminal settled	"Asset movement completed."	Over-specific chain claims not returned by the product surface.
Returned/released	"Movement did not complete; funds were released or returned."	"Mint reversed" unless that is the actual returned record.

Event join model

{
  "trade_id": "pt_live_9A2",
  "pool_status": "settled",
  "asset_event": {
    "type": "stablecoin_delivery",
    "asset": "USDT",
    "network": "polygon",
    "amount": "107.42",
    "reference": "asset_event_51"
  },
  "ledger_entry_id": "ledger_0pools_772"
}

Product controls

Keep quote/trade status separate from asset-event status.
Do not show mint/burn copy unless the returned product record supports that wording.
Preserve network, asset, amount, and reference id for support.
If delivery fails after a reserved trade, keep the user in a pending/failed state until the returned or released outcome is known.

Implementation depth

This page is about understanding mint-style and burn-style accounting around pool movement. For developers, the durable boundary is simple: your product should depend on asset event records, trade references, statuses, and reconciliation links; it should not depend on custody details, internal token control, and settlement service internals. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A partner sees a pool trade followed by an asset event. The trade records the accepted liquidity movement; the mint-style or burn-style event records how the product reflects the settled asset outcome.

Before and after in practice

Before 0Pools	With 0Pools
Products describe every asset movement as a transfer, hiding whether value was created, redeemed, returned, or unwound.	The product separates trade execution from asset event accounting and keeps reconciliation explicit.
Product teams infer liquidity behavior from provider-specific screens or manual notes.	Product teams branch on 0Pools objects: pool, quote, trade, balance, webhook, and ledger.
Support asks engineering to reconstruct state from logs.	Support starts from request id, quote id, trade id, event id, and ledger id.

System flow

Records to keep

Record	Why it matters	Example
`asset_event_id`	Tracks the mint/burn-style record.	`ae_123`
`linked_trade_id`	Connects it to 0Pools execution.	`pt_test_456`
`event_type`	Explains the accounting shape.	`mint_recorded`
`reconciled`	Shows finance review state.	`true`

A useful implementation stores these records before adding optional analytics. Analytics can be rebuilt from durable state; missing ids usually cannot be reconstructed after a customer-impacting failure.

Example product record

{
  "product_area": "mint-burn-lifecycle",
  "partner_reference": "partner_order_123",
  "pool_id": "EUR-USDT",
  "quote_id": "pq_test_123",
  "transact_id": "pt_test_456",
  "status": "reserved",
  "request_id": "req_01HZY0POOLS",
  "reconciliation_state": "open"
}

This record is intentionally partner-facing. It references 0Pools objects and your own product ids, but it does not include private liquidity routes, treasury balances, raw provider payloads, or customer secrets.

Failure modes and recovery

Failure mode	Product response
Asset event without trade link	Hold for investigation before ledger close.
Burn described as failure	Distinguish normal redemption from failed trade.
Returned state omitted	Model return events separately.
Customer copy too technical	Translate lifecycle states into clear product messages.

Use-case patterns

Pattern	How 0Pools helps
Stablecoin issue/redeem products	Track accounting records around pool trades.
Treasury reporting	Join asset events to trade ids.
Support timelines	Explain why a trade and asset event have different timestamps.

Developer checklist

Read runtime discovery and capabilities before rendering enabled actions.
Create firm quotes only when the user is ready to accept the terms.
Execute from your server with an idempotency key.
Treat webhooks and status reads as the source of truth for settlement state.
Reconcile by durable ids first, then by amount and timestamp.
Do not branch product behavior on provider names, route names, reserve balances, or treasury assumptions.