Skip to content

USE (USD stablecoin)#

Centralized USD-pegged stablecoins anchor most on-chain liquidity and activity. Their design brings censorship and regulatory risk. Refusing to interoperate isolates Ergo in a niche and reduces utility for regular users. This page lays out the case for a cost-efficient USD stablecoin for the Ergo ecosystem (USE), the core design, initial parameters and a practical roadmap for launch and operations.

Related docs: Use cases overview, Dexy

Summary#

  • Objective: deliver a cost-efficient, highly liquid USD-pegged asset (USE) that maximizes on-chain utility while preserving protocol security.
  • Positioning: a pragmatic asset that interoperates with broader crypto liquidity (USDT and peers) while keeping protocol-level safety strong and avoiding censorship-prone primitives at the platform layer.
  • Guiding principle: prioritize cost efficiency (low fees, scalable flows) without compromising security of protocol contracts.

Recent updates#

  • Jan 7: StableMiner went live for locally minting USE from an Ergo node wallet.
  • Jan 6: a VoltPay example completed an ADA -> ERG -> USE buy order.
  • Jan 7 to Jan 14: USE analytics went live at Crux Finance, Binance Chain USE/USDT liquidity was deployed, and the USE pegged-asset adapter landed in DefiLlama.
  • Jan 6: the node wallet had a USE decimal display bug open as issue #2289.
  • Apr 5: the USE buyback box moved to a new contract address and the self-output proposition check was fixed, so UIs need the updated buyback contract or NFT token ID lookup.
  • Jun 22: ergo-use-x402 published x402 and Agentic Commerce Protocol payment examples for USE on Ergo. The example flow uses Babel fees, so a payer can spend USE without holding ERG for the miner fee.
  • Caveat: some explorers assume a single mint output and can report the wrong emission amount when minting spans multiple output boxes.

StableMiner is an open-source, locally hosted platform for minting Dexy / USE stablecoins directly from an Ergo node wallet without using an exchange. Auto-swap support is planned after the initial launch.

The Binance Chain deployment used a USE/USDT concentrated-liquidity pool for cross-chain stablecoin liquidity. The DefiLlama work added USE as a pegged asset, while DexyGold work was being prepared separately.

The buyback-contract update matters for integrations: UIs should not hard-code only the old address. Integrations should update to the new contract address or resolve the buyback box by NFT token ID lookup.

The x402 example is an integration pattern rather than a USE protocol rule. It includes a stateless facilitator, ACP merchant, Nautilus path, ErgoPay path, and confirmed mainnet examples, but integrators should still treat mempool acceptance as non-final and monitor Babel-box liquidity.

Why USE on Ergo?#

  • Liquidity and onboarding: USD stablecoins function as primary on-ramps and liquidity anchors. Support for them raises accessibility for users and traders.
  • Ecosystem growth: Interoperability with the most liquid assets supports DEX volume, developer traction, and integrations.
  • Complementary design: A well-specified USE and its tooling can showcase Ergo’s advantages (privacy features, formal contracts) without forcing users to abandon familiar liquidity.

Design Choices and Recommendations#

  • Reserve model (1:1): adopt a conservative, transparent reserve approach that follows Dexy-style operational assumptions to reduce systemic risk.
  • Cost efficiency: select mechanisms that minimize fees and friction across composable flows. Dexy’s low-fee properties and Rosen Bridge integration can drive competitive costs.
    • Recommended fee targets:
      • Rosen and cross-chain bridges: enable custom fees as low as ~0.1% to remain competitive.
      • Dedicated v3 AMM instance (e.g., BSC): target 0.05% fees with a tighter price band (0.9–1.1) for stable-stable liquidity.
  • UI fees and fee caps: adopt a front-end fee that lifts after the protocol-wide collected fees for USE pass a configured threshold. The UI operator (example: C8) should set and enforce this policy for USE only.
  • Decimal precision: match major liquidity partners. Use 6 decimals as a minimum. This choice provides fine granularity (0.999999) and aligns with many stablecoins and exchanges. Avoid low-precision choices (for example, 2 decimals) that weaken tight stable-stable markets.
  • Supply considerations:
    • Supply size does not control peg mechanics. Choose a nominal supply that avoids awkward decimals and matches UX expectations.
    • Community discussions explored ranges from 50 m to very large nominal supplies. Very large nominal supplies (for example, 100 T) require 6 decimals to keep UX precise.
  • Token identifiers and governance tokens: prepare and publish canonical token IDs (pool NFT, refresh/update NFTs, oracle, reward, ballot) in initial docs and deployment manifests so trackers and UIs can follow them. Include example formats in release notes.
  • Oracles: select reliable price oracles and document decimal handling so USDT/USDC pairings behave as expected. Ensure oracle data follows the token’s decimal conventions.

Bank Contract: Stability and Security (Starting Properties)#

We aim for a stable peg and robust security under realistic adversarial conditions.

  • Reserves: 1:1 reserves in segregated, auditable addresses or multisig, with governance-controlled vaults.
  • Oracle design: multi-source inputs with signatures, aggregation, outlier rejection, and a pause control for anomalous readings.
  • Peg controls: conservative, auditable adjustments only; no privileged auto-minting.
  • Governance and upgradeability: minimal, explicit upgrade paths; emergency pause under multisig with time-locks to prevent unilateral actions.
  • Limits and caps: early per-block and per-wallet mint/redemption limits that reduce exposure to procedural or market errors.
  • Transparency: public reserve attestations and documented accounting procedures, with on-chain proofs where feasible.

Initial Parameter Suggestions (For Review)#

  • Decimals: 6.
  • Initial nominal supply: choose a number that avoids awkward UX. Community leaning: 250,000,000. A larger nominal supply also works when paired with 6 decimals.
  • Fee structure:
    • Protocol/bridge configurable fee floor at 0.1%, with operator flexibility for competitive rates.
    • Target 0.05% for dedicated stable-stable AMM pools.
    • UI fee waiver after a defined cumulative-fees threshold for USE (threshold set by the UI operator).
  • Oracle cadence: conservative configuration with minute-level updates plus aggregation and outlier rejection.
  • Mint/redemption onboarding: start with off-chain KYC/AML for minting partners if counterparties require it. Publish clear KYC policies.

Operational Notes and Trackers#

  • Pre-launch tokens: no tokens exist until mint. Indexers and off-chain bots should prepare to track and register token IDs once minted. Trackers should ingest token metadata when available.
  • Publication: publish all token IDs and NFT IDs for pools, refresh, update, oracle, reward, and ballot before or at launch so UIs and indexers can enable support.

Roadmap (Proposal)#

  • Finalize high-level design and governance model (multisig, time-locks, upgrade policy).
  • Decide decimals and nominal supply (community vote or dev consensus).
  • Implement bank contract and complete a security review and audit.
  • Implement oracle adapters and aggregator logic; test on testnet.
  • Prepare Rosen Bridge integration and expose custom fee options.
  • Deploy initial tokens on testnet; publish token IDs.
  • Prepare UI integrations, indexers, and off-chain bot updates.
  • Launch mainnet mint with coordinated liquidity onboarding (DEX pools, AMM instances).
  • Continue audits, reserve transparency, and fee tuning based on activity.

Suggested Role Assignments (Initial)#

  • Protocol and bridge integration: Rosen maintainers coordinate custom lower-end fee settings.
  • AMM and liquidity engineering: Dexy and AMM operators define tight stable-stable pools; consider a v3 instance on BSC for cross-chain liquidity tests.
  • UI fee policy and front-end: C8 defines the threshold and implements fee-lifting for USE.
  • Token spec and decimals: Kushti documents implementation details and minting parameters.
  • Audit and security: independent auditors and core dev reviewers oversee scope and fixes.
  • Community coordination: one or two community managers publish token IDs and coordinate with exchanges and trackers.

Open Questions Before Launch#

  • Exact nominal total supply and decimal decision
    Proposed: 6 decimals, nominal supply at 250 m or a different nominal with 6 decimals.
  • Final governance signers and time-lock parameters.
  • Audit scope and dates.
  • Oracle providers and aggregator logic.

Notes From Community Discussions#

  • Broad support exists for 6 decimals to match USDT and support tight pricing.
  • Dexy’s transparent 1:1 reserve approach and cost focus fit the target UX for USE.
  • Very low fees attract flow; security and reserve integrity remain the higher priority.
  • A UI fee-waiver after a collected-fees threshold can strengthen UX for USE.

Next Steps#

  1. Confirm the decimals and nominal supply choice and record the decision.

  2. Start the bank contract specification and nominate multisig signers.

  3. Produce a detailed technical spec for the bank contract and AMM parameters for audit.

  4. Assign owners for roadmap items and set timelines.