M&G5 Local/devnet protocol MVP · mocked reserves · mocked oracle data · not a public offering
Reserve logic first · AppChain later

M$G 5 — Monetary Stability & Gold-backed Logic.

M$G 5 is a technical MVP for `MG5`, a reserve-token protocol designed for a future EVM AppChain deployment. The model tracks stable real-world monetary assets, including Gold and major fiat-equivalent sleeves, through a basket NAV and a strictly controlled stable mathematical mean. The current work is deliberately narrow: prove the Monetary logic locally with Solidity, Foundry, mocked reserves, mocked prices, haircuts, circuit breakers and stress tests before introducing validators, bridges, custody or mainnet exposure.

protocol status
chain target Avalanche L1 / Subnet-EVM-compatible deployment path
v0 environment Local Solidity + Foundry + Anvil
reserve layer Mocked. No custody integration in v0.
oracle layer Mocked. Stale/frozen states are enforced.
test status Foundry unit, invariant and stress suites pass locally.
105%
target collateral ratio
102%
minimum collateral ratio
300s
default oracle staleness limit
0%
MGS contribution to MG5 collateral
// 01 · Purpose

M$G 5 is designed around Monetary stability mechanics, not promotional yield.

The M&G5 Global Reserve Protocol is a research and engineering project for a basket-backed reserve token. The protocol objective is simple: if a unit of MG5 is issued, the system must be able to explain what supports it, how its Monetary basket NAV is calculated, how Gold and fiat-equivalent exposures contribute to the stable mean, what happens when reserves are stressed, and why unsafe redemptions are not allowed to silently damage remaining holders.

The first MVP is not a sale, a public launch, a production stablecoin, or a real reserve product. It is a local protocol implementation intended to answer one question before anything else: does the monetary logic survive stress when confidence is removed from the model?

Design position. Confidence is not the peg-defense mechanism. Confidence is the consequence of reserves, transparent accounting, redemption rules, haircuts, waterfall logic, objective circuit breakers and repeatable stress tests.
Technical Architecture

M$G 5 — Monetary Stability & Gold-backed Logic

The core protocol architecture is designed for Monetary resilience. M$G 5 models stable real-world assets, including Gold and fiat-equivalent indices, through a basket-backed reserve framework that continuously measures NAV, collateral ratio, reserve haircuts and redemption safety around a stable mathematical mean.

// 02 · Mechanics

Minting and redemption are governed by NAV, collateral ratios and hard stop conditions.

Mint path

Deposit value is converted into MG5 at current basket NAV.

The protocol checks that minting is not paused, the oracle is fresh and unfrozen, applies the mint fee, calculates MG5 output, and refuses the transaction if post-mint collateralization would fall below the target ratio.

Redeem path

MG5 is burned only when redemption remains solvent.

Immediate redemption uses the current NAV, applies a redemption fee, checks slippage and tests the post-redemption collateral ratio. If the result would break minimum solvency, the immediate path reverts.

Queue fallback

Unsafe redemptions move into an explicit queue.

Queued requests escrow MG5. A keeper can process them only when burning the escrowed MG5 and reducing mocked reserves does not violate the minimum collateral rule.

Tokens
MG5Token MGSToken
Accounting
BasketOracle ReserveManager BasketMath FixedPointMath
Operations
MintRedeem RedemptionQueue WaterfallManager CircuitBreaker
Authority
ProtocolGovernor Oracle updater Reserve updater Keeper Pauser
// 03 · Risk model

The protocol makes failure states visible instead of pretending they do not exist.

01

Reserve haircuts are applied before solvency is measured.

USD, EUR, GOLD, CNY and BRICK/EM sleeves carry different haircut assumptions. The system uses haircut-adjusted reserves, not raw optimistic reserve value, when checking liabilities.

02

Oracle unavailability blocks NAV-dependent actions.

A stale or frozen oracle prevents minting and redemption execution. The system cannot rely on a stale NAV while continuing to issue or redeem MG5.

03

MG5 and MGS are separated by design.

MGS is only a simulated bounty reward token in v0. It does not collateralize MG5, does not defend the peg and does not receive real yield. This avoids reflexive collateral mechanics.

04

Circuit breakers are objective, not narrative.

The breaker layer can respond to stale or frozen oracle state, low collateral ratio, oversized redemption queue and manual emergency conditions. Minting is blocked first; queued redemptions remain possible only if solvency allows.

// 04 · Waterfall

Redemption pressure follows a defined crisis-defense hierarchy.

DEX liquidity / external market liquidity. Mocked in v0, reserved for immediate liquidity modeling.

Fee buffer. Accumulates mint and redemption fees as a protocol buffer.

War chest. Mocked emergency liquidity with a daily draw cap.

Reserve liquidation. Modeled as reserve liquidation capacity in v0.

Redemption queue. Explicit fallback when immediate redemption would be unsafe.

Circuit breaker. Final defensive state when objective failure conditions require throttling.

Plain limitation. This page describes a technical protocol MVP. It does not claim real reserves exist today, does not offer redemption against real fiat or gold, and does not invite public purchase of MG5. Production credibility would require custody, attestation, oracle integration, legal framework, operational redemption rails and independent review.
// 05 · Build and verification

The local repository is built to test the accounting and stress behavior before appchain infrastructure exists.

Area What is tested Reason
Tokens MG5 restricted mint/burn, MGS deployment and MGS-only bounty rewards. Prevents public minting and prevents MGS from becoming reflexive MG5 collateral.
Oracle Valid updates, zero price rejection, NAV calculation, freeze and staleness blocking. Prevents NAV-dependent actions from executing on invalid price state.
Reserves Mock reserve updates, haircut updates, adjusted reserve value and collateral ratio. Makes solvency dependent on conservative reserve value, not raw nominal balances.
Mint/Redeem Healthy minting, fee buffer, healthy redemption, undercollateralized mint rejection and queue fallback. Ensures issuance and redemption preserve required collateral thresholds.
Stress 20% and 40% redemption runs, oracle freeze, sleeve price shocks, haircut increases and buffer depletion. Tests the protocol under conditions where confidence alone would not be enough.
local commands foundry
buildforge build
testsforge test
stressforge test --match-contract StressRedemptionRun
invariantsforge test --match-contract Invariants
local chainanvil
// 06 · Current limitations

The honest boundary of v0 is local protocol logic.

No live reserves

Reserve balances are mocked.

There is no custody account, no tokenized gold, no fiat rail and no reserve attestation in this phase.

No live oracle

Prices are mocked.

Oracle behavior is implemented to test stale, frozen and shocked price conditions before production integration.

No bridge

Bridge design is intentionally postponed.

Cross-chain movement is not part of the first MVP because it does not prove reserve solvency.

No validators

AppChain infrastructure comes later.

The first milestone is monetary logic and stress behavior, not validator set design.

No DAO

Authority is centralized in v0.

ProtocolGovernor uses role-based administration for local testing. DAO governance is not implemented.

No yield

Stability is the product.

The protocol does not market return, interest, yield or profit. The engineering priority is redemption integrity.

// 07 · AppChain roadmap

The AppChain is the endgame, not the first problem.

Phase 1
Local Foundry MVP

Build and test the monetary logic locally with mocked reserves and prices.

Phase 2
Private EVM devnet

Move the same protocol contracts into a controlled EVM network environment.

Phase 3
Avalanche L1 / Subnet-EVM prototype

Evaluate sovereign infrastructure only after the protocol logic passes stress tests.

Phase 4
Validator set design

Define security, operational controls and governance boundaries for a dedicated chain.

Phase 5
Bridge design

Design cross-chain movement only after reserve and redemption mechanics are mature.

Phase 6
Oracle and reserve attestation integration

Replace mock inputs with verifiable external data and independent reserve reporting.

Phase 7
Legal and custody framework

Define the operational and legal structure required for real assets and real redemption.

Phase 8
Public testnet stress competition

Expose the protocol to adversarial testing before any capped production beta.

Phase 9
Capped mainnet beta

Only after monetary logic, infrastructure, custody, oracle and legal controls are defensible.

Final principle. Monetary logic first. Stress tests second. AppChain infrastructure third. Real reserves last. No reserve model, no currency. No stress survival, no appchain. No redemption path, no peg.