Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

The Minting and Burning Process

The minting and burning process for GUSD and G-Series Stablecoin 2.0 is designed to:

  • keep on-chain supply tightly aligned with reserves

  • maintain peg stability and solvency

  • ensure that risk metrics (CR, LCR, σ, haircuts) are respected at all times

This section describes the high-level lifecycle of GUSD and G-Series from the perspective of minting, burning, and redemption.

1. GUSD Minting

GUSD is minted against an over-collateralized reserve of major dollar stablecoins (such as USDT and USDC) and, over time, selected RWA-type assets.

1) Eligibility and Access (Permissionless with Guardrails)

To maximize accessibility in the early phase while maintaining a basic level of compliance, GUSD minting is designed to be permissionless yet protected:

  • Open Access Any user or smart contract can deposit eligible collateral to mint GUSD directly via the protocol. No manual whitelisting is required for standard users at the contract level.

  • Automated Sanctions Screening To prevent sanctioned or clearly high-risk addresses from contaminating the reserve, the protocol integrates on-chain compliance or sanctions-screening oracles. Addresses flagged on global sanctions lists (e.g., OFAC and similar) are automatically blocked from minting or burning at the smart contract level. Transactions from such addresses revert.

  • Front-End Controls While the core contracts are open, front-end interfaces provided by WANNA or partners may apply additional:

    • geo-blocking

    • KYC/AML checks

    • policy filters as required by local regulation and licensing

This model keeps the protocol DeFi-native and composable, while adding a baseline defense against obviously illicit flows.

2) Collateral Deposit

To mint GUSD:

  1. A user calls the mint function and deposits eligible collateral (e.g., USDT, USDC) into the GUSD contract.

  2. The protocol:

    • checks the caller against the sanctions/compliance oracle

    • verifies the collateral type and amount

    • applies any conservative haircuts and risk adjustments

    • recalculates the Collateral Ratio (CR) and Liquidity Coverage Ratio (LCR)

If, after the deposit:

  • CR ≥ 1.00 + σ

  • LCR ≥ 1.0

the requested mint amount is allowed to proceed. If not, the mint may be partially filled, capped, or rejected.

3) GUSD Issuance

Once the checks pass:

  • the protocol mints GUSD to the caller’s address

  • updates total GUSD supply

  • records the updated reserve balances

  • updates internal views used for risk and liquidity monitoring

Minting may incur minimal protocol fees, primarily to cover operational costs and discourage spam or abusive patterns.

2. GUSD Burning and Redemption

Burning (redemption) is the process by which GUSD is destroyed and underlying collateral is released.

1) Redemption Request

To redeem GUSD:

  1. A user calls the redemption function and transfers GUSD back to the contract, specifying the desired collateral (among supported assets such as USDT, USDC).

  2. The protocol:

    • checks the caller against the sanctions/compliance oracle

    • verifies the redemption request and amount

    • ensures that risk metrics remain within acceptable ranges after redemption

If the address is flagged by the oracle, the transaction is reverted. If the address is clean, the process proceeds.

2) Burning GUSD

  • The specified amount of GUSD is burned from the user’s address.

  • Total GUSD supply is reduced by the same amount.

3) Release of Collateral

  • The protocol releases the corresponding collateral (e.g., USDT, USDC) from reserves to the user, prioritizing immediately liquid assets and Tier 1 (L1) reserves.

  • If needed, positions in the yield-generating layer (L2) can be partially unwound to restore L1 balances.

After redemption:

  • CR and LCR are recalculated

  • any necessary rebalancing actions are triggered to keep risk metrics within their target ranges

Redemptions may be subject to fees or temporary limits in periods of extreme market stress.

3. G-Series Minting and Burning

G-Series stablecoins (e.g., GKRW, GJPY, GTHB) are issued on top of GUSD, using FX-linked parameters and guardrails.

1) G-Series Minting

In simplified terms:

  1. A user or integrated service supplies:

    • GUSD

    • another supported input routed via GUSD, along with a request to mint a specific G-Series asset (e.g., GKRW)

  2. The protocol:

    • checks the caller against the sanctions/compliance oracle

    • references FX data from oracles

    • applies conservative buffers and FX-related haircuts

    • confirms that:

      • the G-Series collateral ratio remains above required thresholds

      • FX and liquidity risk metrics (e.g., FX-LCR) remain within limits

  3. If all checks pass, the protocol mints the requested G-Series tokens to the user.

Underlying GUSD (and, indirectly, the USDT/USDC reserve) is updated accordingly, keeping the system-wide balance sheet consistent.

2) G-Series Burning

To redeem a G-Series stablecoin back into GUSD:

  1. The user sends G-Series tokens to the contract and requests redemption into GUSD.

  2. The G-Series tokens are burned, reducing their total supply.

  3. The user receives the corresponding amount of GUSD, calculated using the relevant FX rate and buffers at the time of redemption.

From there, the user may:

  • keep GUSD

  • or further redeem GUSD into USDT/USDC through the GUSD redemption process

Throughout this flow, the same sanctions/compliance oracle checks apply.

4. Safety Mechanisms and Pause Conditions

To prevent adverse events from propagating through the system, the protocol includes several safety switches and pause conditions around minting and burning.

1) Metric-Based Pauses

Minting of GUSD and/or G-Series may be automatically paused or restricted if:

  • CR falls below predefined thresholds

  • LCR or FX-LCR drops below 1.0 for a sustained period

  • buffer levels, haircuts, or exposure limits indicate abnormal risk

In such cases:

  • new minting may be temporarily disabled

  • redemptions may continue under controlled conditions

  • reserve positions (especially L2) can be unwound to rebuild buffers

2) Oracle and Market Integrity Checks

Minting and burning may also be restricted if:

  • price or FX oracles are unavailable, inconsistent, or clearly compromised

  • sanctions/compliance oracle services are unavailable or degraded

  • markets show extreme volatility or clear signs of manipulation

Fallback mechanisms (such as multi-source aggregation, conservative parameter overrides, or circuit breakers) can be applied until conditions normalize.

3) Governance and Emergency Controls

In early phases:

  • certain emergency controls (e.g., protocol-wide mint pause, rapid parameter adjustment in crises) may be held by a foundation, multi-signature committee, or designated risk/operations entity.

Over time:

  • these powers are intended to be formalized and constrained under governance frameworks,

  • with transparent rules on:

    • who can use which controls

    • under what conditions

    • how interventions are disclosed to the community

5. Summary

Under the permissionless with guardrails model:

  • any address can interact with mint and burn functions at the contract level

  • clearly sanctioned or high-risk addresses are blocked via on-chain sanctions/compliance oracles

  • risk metrics (CR, LCR, FX-LCR, buffers) and pause conditions act as additional guardrails

This design aims to:

  • keep GUSD and G-Series accessible and DeFi-native in Phase 1–2

  • embed a baseline standard of compliance and risk control at the protocol level

  • provide a solid foundation for future phases where licensed partners, KYC-based access, and more formal regulatory frameworks are layered on top

PreviousTransparency, Risk Management, and GovernanceNextWhat is G-Series Stablecoin 2.0?

Last updated