How MaseerOne’s Contracts Work — A One-Page Primer for Forum Readers

General
1

TL;DR
MaseerOne is an ERC-20 token with a built-in primary market (mint/redeem) whose rules live outside the token in a set of upgradeable modules. The token itself is immutable and EIP-2612-compatible; policy (pricing, capacity, permissions, settlement routing) is modular and governed by multisigs. That separation keeps the asset predictable for holders while letting operators evolve market logic without migrating the token.

Core idea

  • MaseerOne (the token): canonical ERC-20 with native mint, redeem, exit, and settle. Immutable code; standard allowances plus permit().

  • Modules (upgradeable via proxies):

    • MaseerGate — opens/closes mint/burn windows, sets capacity, cooldowns, and bps fees.

    • MaseerPrice — reports NAV used for mint/redemption math.

    • MaseerGuard — a single pass(address) gate used by transfers/approvals and sensitive calls.

    • MaseerTreasury — issuer registry and emergency/superuser burn authority.

    • MaseerConduit — off-ramp that receives surplus funds for real-world settlement (operators and destinations are allowlisted).

  • Proxies: each module sits behind its own proxy; they’re upgraded/configured by multisigs. The token does not control or mutate modules; it only reads them (or forwards funds to Conduit).

Mint flow (primary issuance)

  1. User approves the payment asset (“gem”) to MaseerOne.

  2. Calls mint(amt).

  3. Token checks, at runtime:

    • MaseerGuard.pass(msg.sender)

    • MaseerGate.mintable(), capacity(), per-address cooldown(), bpsin()

    • MaseerPrice.read() for NAV

  4. On success, token transferFrom pulls gem and mints ERC-20 to the caller.
    Why this matters: Minting is instant and predictable; policy can change without touching the token code.

Redemption flow (two-step)

  • Step 1 — redeem(amt): burns tokens immediately, creates a redemption claim (amount owed after bpsout fee, timestamp). Requires Guard.pass.

  • Step 2 — exit(id) after cooldown: anyone allowed by Guard may finalize on behalf of the redeemer. If the contract has sufficient gem, it pays and closes (partial fills remain open).
    Implications: Cooldowns pace exits; settlement liquidity can arrive asynchronously; redemptions are not volume-capped.

Transfers & approvals (permissioned ERC-20)

  • Every transfer, transferFrom, and approve (including permit()) checks MaseerGuard.pass(...) on the relevant parties.

  • If any party fails, the transaction reverts and no state changes.
    Net result: The asset is DeFi-composable for authorized participants, while providing a robust compliance switch at the token boundary.

Settlement & the Conduit

  • Mint proceeds are not owed to redeemers; they’re “surplus.”

  • settle() moves all current surplus (unsettled()) to MaseerConduit, returning the amount moved.

  • Conduit operators (on an allowlist) can send funds only to allowlisted destinations (exchanges, custodians, back to the token for top-ups, etc.).
    Design goal: Keep issuance synchronous and simple; keep RWA off-ramp logic isolated, auditable, and upgradeable.

Roles at a glance

  • User: mint (if open), redeem, exit, transfer, approve.

  • Issuer: call issue() if listed in Treasury (for administrative flows).

  • Conduit Operator: move settled funds to approved destinations.

  • Owner/Multisig: upgrade modules, tune Gate params, manage allowlists.

Upgradeability & safety model

  • Immutable token; upgradeable modules. The token’s ERC-20 semantics (balances, allowances, permit) are fixed at deploy.

  • Each module is sandboxed behind its own proxy with per-module admin.

  • Upgrades/config changes are on-chain and auditable; token logic remains untouched.
    Benefit: Holders don’t suffer migrations; operators retain flexibility to evolve policy, oracles, and plumbing.

Why this architecture works

  • Predictable asset, flexible market: immutable ERC-20 ensures durable integration; policy changes don’t break wallets, exchanges, or DeFi adapters.

  • Clear separation of concerns: pricing, permissions, throttles, and off-ramp are independent, minimizing blast radius for upgrades.

  • Compliance without bespoke wrappers: Guard gating at the token surface avoids fragile app-by-app filters.

Quick reference (functions)

  • Mint: mint(amt) → checks Guard/Gate/Price; pulls gem; mints.

  • Redeem: redeem(amt) → burns; records claim.

  • Exit: exit(id) → pays owed (full/partial) after cooldown.

  • Settle: settle() → pushes surplus gem to Conduit.

  • Permit: permit(owner, spender, value, deadline, v, r, s) → EIP-2612 approval with Guard checks.