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

G-Series: FX Pegging Model & Price Feeds

G-Series Stablecoin 2.0 is an FX-pegged stablecoin family

To maintain a robust link between each G-Series token and its target fiat currency, the protocol relies on:

  • an FX-aware collateral model

  • a multi-source price feed architecture for both USD and local FX rates

This section explains how the peg is maintained and how price/FX data is sourced, aggregated, and used inside the protocol.


1. FX Pegging Overview

Each G-Series stablecoin (e.g., GKRW, GJPY, GTHB, GVND) is soft-pegged to its reference fiat currency through:

  • USD-based collateral at the GUSD layer

  • FX-linked parameters (collateral ratios, haircuts, safety margins, liquidity indicators) at the G-Series layer

Conceptually:

  • G-Series tokens represent claims denominated in local currency units

  • but are ultimately backed by USD stablecoins and RWAs at the GUSD layer

The protocol does not promise an absolutely rigid peg at all times. Instead, it is designed to:

  • maintain a tight operational band around the target FX value

  • remain solvent and liquid across a wide range of market conditions


2. Oracle and Price Feed Architecture

The protocol does not rely on a single oracle. Instead, it combines three broad categories of data:

  1. On-chain DEX Data

  2. Centralized Exchange (CEX) Data

  3. Institutional FX / Off-chain Feeds

These sources are aggregated to produce a clean internal FX/price feed used by G-Series.

1) On-chain DEX Data

On-chain data is the most transparent and directly verifiable source of prices for:

  • pairs such as GUSD/USDT, GUSD/USDC,

  • and G-Series pairs such as GKRW/GUSD, GJPY/GUSD, where liquidity is available.

Key design points:

  • Use of TWAP (Time-Weighted Average Price) over a defined window to reduce the impact of:

    • short-term volatility

    • price manipulation attempts (e.g., flash loan attacks)

  • Preference for deepest, most liquid pools across supported chains and DEXes.

  • Continuous monitoring for:

    • abnormal slippage

    • suspicious volume spikes

    • on-chain anomalies

2) Centralized Exchange (CEX) Data

CEX markets are used as a reference for:

  • major crypto pairs (e.g., BTC/USDT, ETH/USDT)

  • major stablecoin pairs (e.g., USDT/USDC)

  • in the future, potential GUSD or G-Series listings

Key design points:

  • Use of ticker and order book mid-prices from multiple exchanges.

  • Elimination of outlier quotes and venues that show abnormal spreads or illiquidity.

  • Optional use of volume-weighted averages across exchanges.

3) Institutional FX / Off-chain Feeds

For fiat FX rates (e.g., USD/KRW, USD/JPY, USD/THB, USD/VND), the protocol references:

  • institutional-grade FX data providers

  • bank or financial market APIs

  • other high-quality macro FX feeds

Key design points:

  • Only sources with sufficient track record and reliability are used.

  • Multiple feeds are combined to avoid over-reliance on any single vendor.

  • Stale or inconsistent feeds are discarded or down-weighted.


3. Aggregation Pipeline

The three data categories are processed through an aggregation pipeline to produce the final internal feed:

On-chain DEX TWAP CEX Tickers / Order Books Institutional FX FeedsAggregator → Clean FX / Price Feed

1) Normalization

Raw inputs are normalized to a consistent format:

  • all prices expressed in standard base/quote pairs (e.g., USD/KRW, GUSD/USDT)

  • timestamps, volumes, and confidence indicators aligned

  • data quality flags attached (freshness, spread, liquidity)

2) Filtering and Outlier Rejection

The aggregator applies filters to remove or down-weight:

  • stale data beyond a defined maximum age

  • quotes with abnormally wide spreads

  • venues with suspicious volume or behavior

  • extreme outliers outside a reasonable deviation band from the median

3) Weighted Aggregation

After filtering:

  • prices are combined using weighted medians or volume-weighted averages,

  • with configurable weights per source type:

    • on-chain DEX data may be favored where liquidity is strong

    • institutional FX feeds may be prioritized for fiat currency pairs

    • CEX data can provide redundancy and cross-checks

The final output is a Clean FX/Price Feed used internally by the protocol.


4. Use of Price Feeds in the G-Series Model

The clean feed is used in several key areas:

1) Minting and Burning

  • Convert between:

    • GUSD and G-Series amounts

    • different G-Series assets (via GUSD)

  • Determine how many units of G-Series to mint or burn for a given amount of GUSD.

  • Ensure that, after each operation:

    • collateral ratios remain above target ranges

    • FX-linked liquidity metrics (FX-LCR) stay within safe bounds

2) Risk Metrics and Guardrails

Price feeds drive:

  • recalculation of:

    • Collateral Ratio (CR) for G-Series

    • FX-LCR and related liquidity indicators

    • mark-to-market values of reserves and liabilities

  • application of haircuts on:

    • specific assets (e.g., certain stablecoins or RWAs)

    • specific FX pairs under stress

  • triggering of safety responses:

    • tightening minting limits

    • increasing haircuts or safety margins

    • or, in extreme cases, temporarily pausing certain operations

3) Internal Accounting and Reporting

  • Internal balance sheet views

  • monitoring dashboards for volatility and FX exposure

  • and periodic reporting (where applicable) to stakeholders and regulators


5. Safeguards, Fail-Safes, and Degraded Modes

Because price and FX data are critical to peg stability, the protocol includes safeguards for:

  1. Stale or Missing Data

  2. Source Divergence and Anomalies

  3. Emergency and Governance Intervention

1) Stale or Missing Data

If a critical portion of feeds becomes stale or unavailable:

  • confidence scores for those feeds are reduced to zero

  • the system may:

    • widen safety margins (σ),

    • increase haircuts, or

    • limit minting and complex operations.

In extreme cases, the protocol can:

  • switch to degraded mode, allowing only:

    • redemptions

    • or controlled operations, until reliable data is restored

2) Source Divergence and Anomalies

If major sources disagree beyond a predefined threshold:

  • the aggregator may:

    • ignore extreme outliers

    • down-weight problematic venues

    • or temporarily rely more heavily on on-chain data or institutional FX feeds, depending on context

  • Parameters such as σ, haircuts, and allowed slippage are automatically adjusted to defend the peg and buffers.

3) Governance and Emergency Controls

In early phases:

  • a foundation, multi-signature committee, or designated risk entity may have limited powers to:

    • override or update oracle configuration

    • introduce new sources or disable compromised ones

    • trigger circuit breakers in case of obvious manipulation or system-wide crises

Over time:

  • these controls are expected to be formalized under governance

  • with clear on-chain rules and transparent procedures for:

    • adding/removing oracle sources

    • adjusting weights and thresholds

    • and handling extraordinary events


6. Summary

The G-Series FX peg is not based on a single feed or simple 1:1 promise, but on:

  • multi-layer collateralization via GUSD

  • a multi-source price/oracle architecture that combines on-chain DEX data, CEX markets, and institutional FX feeds

By:

  • aggregating and filtering data

  • applying risk-aware parameters (CR, FX-LCR, σ, haircuts)

  • embedding fail-safes and governance controls

the protocol aims to keep G-Series:

  • closely aligned with their target fiat currencies

  • resilient against market volatility, data issues, and localized failures

Last updated