SUPRX Litepaper

A native proof-of-work asset with a wrapped access rail.

SUPRX is the chain-side asset. wSUPRX is the Base-side wrapper. The chain handles issuance and final settlement. Base handles easier wallets and public market access. The reserve is what keeps that relationship honest.

Abstract

The system in brief.

SUPRX is a native proof-of-work monetary base with a separate wrapped access rail on Base. The chain still does the real monetary work. The wrapped side exists so people can reach the asset without pretending the chain itself should disappear.

The wrapped system follows one public rule: wrapped supply should not exceed locked native reserve. The reserve does not set the market price and it does not create deep liquidity out of thin air. It only tells you whether the wrapped side is staying inside its stated backing condition.

This paper keeps the mechanism, the trust assumptions, and the public limits in one place.

1. Problem

Why keep a native chain and still use a wrapped rail.

Native-only systems

A native chain can define its own monetary schedule and settlement history, but ordinary users may still avoid it if wallets, swaps, and application rails are too narrow.

Wrapped-only systems

A token can be easy to access, but if it has no independent reserve or chain identity then its economics are fully subordinate to the host environment. It becomes a wrapper with no underlying monetary base.

The design goal is to keep the native chain as the monetary base while using Base as the access layer. This only works if the relationship stays explicit, limited, and easy to audit.

2. System model

One asset, two environments.

Native SUPRX

SHA256d proof-of-work.
Target block time of about 2 minutes.
Current block subsidy era of 25 SUPRX per block.
Long-run code-side monetary bound of about 52.56 million SUPRX.
Final settlement and redemption asset.

Wrapped wSUPRX

Base ERC-20 wrapper for SUPRX.
Contract address: 0x947CA2a80DE8Cbc62CFf1eB5e4189b85948E14B1
8 decimal places.
Official pool address: 0xD0a531930d0D4aD46e4c3ED3FfAa3D4c50f52390
Used for Base-side wallets, swaps, and application rails.

The native chain and the wrapped rail should be read as one asset in two environments, not two random systems stapled together.

3. Reserve rule

The wrapped side is limited by reserve.

The reserve rule is simple:

locked native SUPRX >= wrapped wSUPRX supply

This is the main solvency constraint on wSUPRX.

What the rule means

Native SUPRX is locked in the treasury.
wSUPRX is minted only after the native side is locked and confirmed.
wSUPRX is burned on redemption before native SUPRX is released.
Reserve surplus may exist, but it does not change the intended 1:1 relationship before fees.

What the rule does not mean

Reserve is not market liquidity.
Reserve is not a guaranteed USD floor.
Reserve surplus is not a bonus redemption ratio.
Thin pool prices are not proof of broad market value.

The intended conversion relationship remains 1 SUPRX to 1 wSUPRX before fees. Extra reserve means surplus backing, not some bonus redemption trick.

4. Conversion path

Wrap and redeem are separate operations.

Wrap

User sends native SUPRX to the official native treasury address.
User submits a wrap claim with the amount, native Transaction ID, native source address, and Base recipient address.
After the native deposit reaches the required confirmations, the operator mints net wSUPRX on Base.
Wrap fee: 0.25%.

Redeem

User connects the Base wallet that already holds wSUPRX.
User enters a native sx1... destination address.
The bridge burns the gross wSUPRX amount on Base.
After the release path confirms, native SUPRX is sent to the destination address. Redeem fee: 0.25%.

Both paths depend on correct operator execution, correct treasury custody, and enough operator gas on Base to finish the job.

5. Trust assumptions

The bridge is auditable, but it is not trustless.

What can be checked publicly

Native chain state.
Locked reserve amount.
Wrapped supply.
Bridge mint and release history.
Contract addresses, pool address, and wallet releases.

What still depends on operators

Mint and release execution.
Operator wallet security.
Operator gas on Base.
Safe-controlled administration.
Correct runtime enforcement of the reserve rule.

The bridge is operator-relayed and reserve-backed. Call it that. Do not call it trustless while runtime execution still depends on hot operator wallets and Safe-controlled admin paths.

6. Market structure

The market is separate from the reserve.

What the pool proves

The official Base pool provides price discovery, entry, and exit. It is the current public market reference for wSUPRX.

What the pool does not prove

A visible quote does not prove deep liquidity. If the pool is shallow, the displayed price can move hard under small size. Reserve backing and market depth are separate facts.

Definitions

Liquidity is not reserve.
Liquidity is not circulating supply.
Liquidity is not market cap.
Reserve coverage is not a conversion bonus.

Practical implication

Users should judge the system by both backing and depth. A backed wrapper with a thin pool can remain solvent while still being a weak market for larger trades.

7. Security and failure conditions

Failure cases should be named plainly.

Native-side failures

Chain stall or poor peer diversity.
Local wallet sync problems misread as fund loss.
Outdated releases or bad bootstrap information.

Wrapped-side failures

Operator gas depletion.
Operator wallet compromise.
Stale proof or broken explorer routes.
Reserve mismatch.
Thin liquidity causing misleading price impressions.

The system remains legible only if these risks are named before they occur, not after.

8. Why the design may matter

The native chain gives the wrapper a monetary base.

Without the chain

A token can still trade, but its economic identity is entirely subordinate to the host environment. It becomes a market object with no separate monetary base.

With the chain

SUPRX keeps its own issuance, mining, and final settlement history. The wrapper improves accessibility, but it does not replace the native monetary rail. That distinction is the core of the design.

9. Public interfaces

The paper is only useful if users can check the claims.

Primary surfaces

Canonical addresses

wSUPRX token on Base: 0x947CA2a80DE8Cbc62CFf1eB5e4189b85948E14B1
Bridge controller on Base: 0x874D9718aa2e4F55CEdDF964933D4b0280d5593a
Safe treasury/admin on Base: 0xA1F82550BE2a68437f50E3b8e6Baa51dA39E0A32
Native treasury address: sx1q2jqfp24aqhk4k2hzgjyj723zyfamcltjsl0p3y

10. Conclusion

The standard is narrow.

SUPRX does not need to claim more than it can prove. The system is coherent if the native chain remains healthy, wrapped supply remains within reserve limits, bridge history remains public, and users can still move between both sides without hidden conditions.

If those conditions hold, the native chain and the wrapped rail reinforce each other. If they do not, the wrapper becomes harder to trust and the native chain becomes harder to access. The design stands or fails on discipline, not on slogans.