Version: Draft 1.1
Status: Working proposal
Scope: NEX base chain, wrapped NEX as UMX on CORE, KnexPay wallet behavior, bridge reserve policy
This document defines the monetary relationship between:
- NEX — the reserve settlement asset on the NEX base chain
- UMX — wrapped NEX on CORE, used as the fast transaction unit
- KnexPay — the wallet and payment interface that manages movement between them
The central objective is:
NEX holds value. UMX moves value.
The system is designed so that:
- NEX is the primary reserve and settlement asset
- UMX is the wrapped, spend-layer representation of locked NEX on CORE
- value can move between reserve and velocity states cleanly
- system behavior favors gravitational return to NEX
This is not intended to be two competing currencies. It is intended to be one monetary system with two functional states.
NEX is the asset where value is meant to rest.
NEX should be used for:
- reserve balances
- treasury balances
- long-term user savings
- final settlement
- bridge collateral
- monetary reporting
NEX is the anchor asset.
UMX is wrapped NEX on CORE. It is the unit where value is meant to move.
UMX should be used for:
- instant payments
- tap-to-pay
- merchant acceptance
- working balances
- app-native microtransactions
- short-duration transactional liquidity
UMX is the movement layer.
The system should always maintain this hierarchy:
- NEX is the superior reserve unit
- UMX is wrapped NEX and subordinate to NEX
- All issued UMX must be explainable in terms of locked NEX backing
- Treasury and long-term balances should resolve back to NEX
Internal ledger/accounting precision must use 8 decimal places.
All storage and bridge accounting must be handled in integer base units.
For ordinary user-facing interfaces:
- default display precision for UMX should be up to 3 decimals
- full 8-decimal precision remains available for audits, technical screens, exports, and reconciliation
The initial recommended policy is a fixed conversion ratio:
- 1 NEX = 1000 UMX
This ratio is recommended because it gives:
- human-friendly transaction sizing
- intuitive everyday prices
- clean psychological denomination for retail use
Under this model:
- 1 UMX = 0.001 NEX
- if NEX uses 8 decimal places internally, then 1 UMX corresponds to 100,000 raw NEX units
This ratio should be fixed and published clearly.
NEX is:
- the reserve asset
- the settlement asset
- the bridge collateral asset
- the treasury asset
- the primary unit of net worth
UMX is:
- wrapped NEX on CORE
- the payment unit on CORE
- the velocity unit of the monetary system
- the user-facing spend denomination
- the fast-layer representation of locked NEX value
UMX should not be framed as a rival reserve asset.
UMX must be presented as:
- wrapped NEX
- a transactional representation of locked NEX
- a fast movement unit
- a spend-layer instrument
- a subordinate monetary state relative to NEX
The bridge must maintain a public monetary invariant.
Locked NEX on the reserve side must equal issued UMX value on the transaction side, according to the published conversion ratio.
If:
- 1 NEX = 1000 UMX
Then:
- every 1 NEX locked in reserve authorizes issuance of 1000 UMX on CORE
- every 1000 UMX redeemed destroys that amount and releases 1 NEX back to reserve ownership
The system should publish:
- NEX reserve/lock addresses
- total bridged/locked NEX
- total issued UMX
- bridge mint events
- bridge burn/redeem events
- reserve proofs or equivalent auditable state reports
UMX may only be created through one of these paths:
- lock of NEX into bridge reserve
- explicit genesis/testnet issuance marked as non-production
UMX must not be issued as an unrelated floating asset if the goal is to preserve NEX gravity.
This direction should be:
- fast
- low friction
- low fee or subsidized
- easy to access through the wallet
Process:
- User chooses to move value from reserve into spend
- NEX is locked on the NEX chain
- The bridge verifies required confirmations
- Equivalent UMX is issued on CORE
- Wallet spend balance increases
This direction should remain available at all times, but may be more disciplined.
Process:
- User chooses to move value from spend into reserve
- UMX is burned or locked on CORE
- The bridge verifies finality and redemption eligibility
- Equivalent NEX is released from reserve
- Wallet reserve balance increases
The system should intentionally favor:
- using UMX for spending
- ending in NEX for reserve
This bias should come from:
- wallet defaults
- merchant settlement rules
- reserve reporting
- treasury behavior
- optional sweep policies
This bias should not come from arbitrary confiscation or user-hostile behavior.
KnexPay should present the monetary system as two coordinated balances:
- Reserve Balance (NEX)
- Spend Balance (UMX)
The wallet should make this feel intuitive:
- hold in NEX
- spend in UMX
- sweep back to NEX
Users should be able to define a UMX operating float.
Recommended controls:
- minimum spend threshold
- target spend balance
- maximum spend float
- minimum spend threshold: 50 UMX
- target spend balance: 150 UMX
- maximum spend float: 300 UMX
Behavior:
- if spend balance falls below 50 UMX, top up from reserve to 150 UMX
- if spend balance rises above 300 UMX, sweep excess back to reserve
This makes UMX behave like working balance rather than savings.
The default wallet behavior should treat NEX as primary.
Examples:
- portfolio summary emphasizes NEX reserve
- default “net worth” view uses NEX
- UMX is presented as available spending balance
- sweep-to-reserve is enabled by default for new users unless they opt out
Merchants are one of the strongest places to enforce monetary gravity.
Merchants should be able to:
- accept UMX instantly
- hold a configurable UMX working float
- settle excess value into NEX automatically
Example:
- merchant keeps 2,000 UMX operating float
- any excess over that float is automatically swept to NEX
- sweep occurs hourly, every 6 hours, or daily depending on preference
Merchants should be encouraged to think:
- UMX = point-of-sale liquidity
- NEX = treasury reserve
This aligns economic activity with NEX accumulation.
Treasury should overwhelmingly prefer NEX.
Treasury balances should be reported primarily in NEX.
UMX treasury balances should be minimized and used only for:
- operational liquidity
- payouts in transit
- payment rail buffering
- short-term working needs
All official financial statements should treat NEX as the reserve denominator.
UMX should appear as:
- transaction inventory
- operational float
- short-duration liquidity
not as the ultimate reserve benchmark.
If the system later introduces rewards or incentives, those rewards should favor:
- holding NEX
- returning value to reserve
- maintaining reserve discipline
- participating in verifiable bridge liquidity support
The system should avoid rewarding indefinite passive parking in UMX.
UMX should win on:
- convenience
- speed
- spendability
- merchant acceptance
- instant transfer
It should not win on:
- long-term reserve preference
- primary balance prestige
- treasury dominance
Retail and everyday prices may be shown in UMX.
This is recommended because UMX is more human-sized and easier for daily mental arithmetic.
Long-term wealth, reserve summaries, treasury reports, and settlement reports should be expressed in NEX.
Where appropriate, the wallet should offer:
- primary display in UMX for daily use
- secondary equivalent in NEX or
- primary display in NEX for reserve screens
- secondary equivalent in UMX
This dual-display policy reinforces the hierarchy without confusing users.
The system must avoid the following failure states:
This is a policy failure.
If users, merchants, and treasury all prefer to sit indefinitely in UMX, then NEX loses monetary gravity.
Countermeasures:
- reserve-first wallet design
- auto-sweep policies
- NEX-denominated reporting
- NEX-favoring treasury rules
If users do not understand whether UMX is backed, native, bridged, or synthetic, the system becomes unstable and loses trust.
Countermeasure:
- publish exact asset model
- publish reserve invariant
- publish bridge and supply data
The system should not tell users:
- “NEX is the real money”
- while also implying
- “UMX is the better money”
UMX should be described as:
- faster
- easier
- more practical for spending
- wrapped NEX for the fast layer
NEX should be described as:
- stronger
- deeper
- more final
- the reserve layer
The strongest concise description is:
NEX is the reserve asset. UMX is wrapped NEX in motion on Lumero/CORE.
Alternative phrasing:
- Hold in NEX. Spend in UMX.
- NEX is gravity. UMX is motion.
- NEX stores value. UMX circulates value.
- NEX settles. UMX flows.
- UMX is NEX on the fast layer.
Avoid calling UMX a “stablecoin” unless it is actually stabilized against an external peg.
The more accurate framing is:
- wrapped NEX
- payment denomination
- transaction unit
- velocity unit
- spend-layer representation of NEX value
- launch NEX as reserve chain
- launch UMX on CORE as wrapped NEX transaction unit
- manual convert-in / convert-out
- visible dual balances in wallet
- add auto-top-up from NEX to UMX
- add auto-sweep from UMX to NEX
- add merchant reserve settlement policies
- add treasury dashboards
- add reserve proofs
- add public invariant reporting
- optimize wallet defaults around reserve discipline
The system should always resolve toward this behavior:
Value rests in NEX, moves through wrapped NEX as UMX, and returns to NEX.
That is the policy.
If implemented correctly:
- NEX wins as gravity
- UMX wins as velocity
- users get fast payments
- merchants get working liquidity
- reserve discipline remains intact
- reserve
- settlement
- treasury
- savings
- gravity
- wrapped NEX
- spend
- payments
- merchant liquidity
- app speed
- velocity
- unified wallet
- reserve/spend orchestration
- auto-top-up
- auto-sweep
- dual-balance UX
Create a system where:
- NEX is the primary asset
- UMX is the wrapped fast payment state of NEX
- movement is easy
- reserve is favored
- the public story stays simple and strong