Protocol

How OrangeCurve is built, and how far it actually is

This page is the reference the rest of the site defers to. It covers the architecture, the trust assumptions, the privacy model, the fee schedule, the proof strategy, and a component-by-component statement of what is live today.

How it flows Implementation status Trust assumptions Threat model /api/status

The shield boundary

Left of the boundary, five entry flows are individually distinguishable — different lane, different label, different cadence. That is public Solana activity, and it is what an observer sees today. At the boundary the lanes converge and identity is destroyed: past it every strand is the same colour and the same width, and lane order is permuted, so which output came from which input cannot be read off the picture.

The right-hand side is drawn hatched because that property is not implemented. The diagram shows the objective; it does not imply the objective has been reached.

Shield boundary

Implementation status

Fourteen components, each with its real state. The same data drives every status chip in this application and is served as JSON at /api/status.

Implementation status by component
Component	Status	What is actually true	What would change it
Wallet connection	Devnet	Wallet Standard discovery, connect, disconnect, and a genesis-hash check that the RPC really serves the cluster it claims. No signature is requested until that check passes.	Already working
SOL balance and network reads	Devnet	Live reads against the configured cluster RPC, with real error states when the endpoint is unreachable.	NEXT_PUBLIC_SOLANA_RPC_URL
Monero address validation	Live	Genuine Bech32 and Bech32m decoding with checksum verification, Sapling payload-length checks, transparent-address rejection and network-mismatch detection. Verified against the BIP-173 and BIP-350 test vectors.	Already working
Token listings, charts, trades, holders	Beta	The full catalogue with server-side filtering, sorting, search and pagination, plus OHLCV, trade flow and holder tables on every token.	INDEXER_URL, INDEXER_KEY
SOL → XMR routing	Planned	A typed quote contract with expiry, per-hop route disclosure and a fee breakdown. Routing goes live once a provider has passed a published custody and timing-correlation review.	CONVERSION_PROVIDER_URL, CONVERSION_PROVIDER_KEY
Trading	Live	Live swaps on Solana mainnet, routed through the Jupiter aggregator. Real quotes with route and price-impact disclosure, a wallet-signed transaction, on-chain submission and confirmation polling with a real signature at the end. Quotes expire at 25 seconds and are refused rather than executed stale.	Already working
Token creation	Planned	The full launch flow is built: schema-validated configuration, browser-side image sniffing and re-encoding, immutable fee-split preview and a cost estimate from real Solana rent minimums. Minting opens with the mainnet program.	NEXT_PUBLIC_LAUNCHPAD_PROGRAM_ID + a deployed program
Rewards accounting	Beta	Time-weighted eligibility and exact-sum epoch splitting in integer zatoshi, both deterministic. Accrual is tracked per token and per holder today.	INDEXER_URL
Private XMR payouts	Planned	Rewards accrue now; claims open with the payout rail. Spending authority lives in a separate minimally-scoped signer service — placing a Monero spending key in a web application would be indefensible.	ORANGECURVE_SETTLEMENT_SIGNER_URL + a signer service
Proof of total distribution	Planned	Epochs carry a commitment hash only. A commitment lets a later disclosure be checked; it does not demonstrate the distribution followed the published rule.	Circuit design and implementation
Confidential balances	Planned	Specified as a commitment-based note model. Monero mainnet has no native custom private assets, so this needs either a protocol change or a separate proving system anchored to Monero. Today a launched token is a standard SPL token with public balances.	Protocol research track
Private order submission	Planned	Open research problem. Encrypting an order is easy; preventing a sequencer, relayer or timing observer from reconstructing it is not.	Protocol research track
Settlement proofs	Planned	Circuit design in progress for a batch-auction settlement proof including the fee split. Proving cost and latency are the binding constraints.	Protocol research track
Security audit	Planned	No audit has been performed yet. OrangeCurve is not audited and this interface does not claim otherwise anywhere.	An audit engagement before mainnet

LiveRunning on mainnet, verifiable by youBetaWorking today, with known limitsDevnetDevnet — real code path, test clusterPlannedShipping behind the beta

Protocol stack

Six layers, one contract each

Every dependency sits behind a typed interface with a declared status. Swap an implementation, keep the stack. This is the whole surface area.

layer 01 / 06 · solana-entryLive

Solana entry adapter

Connect any Wallet Standard wallet and trade on mainnet in two clicks.

Wallet connection, network verification, and mainnet swap execution.

Standard: Wallet Standard
Cluster check: getGenesisHash
Token programs: SPL + Token-2022
Router: Jupiter aggregator
Signing: Client-side only

Delivers

Wallet Standard connection (Phantom, Solflare, Backpack and any compliant wallet)
Cluster identity check via getGenesisHash before any signature is requested
Live SOL and SPL balance reads, across both the legacy and Token-2022 programs
Wallet-signed mainnet swaps with on-chain confirmation
Explorer links for every address and signature shown

Shipping

Hardware-wallet clear signing, so the device renders the swap rather than a blob
Self-hosted RPC by default, removing the last third party from the read path
Priority-fee tuning driven by live network congestion

Contracttypescript

interface SolanaEntry {
  verifyNetwork(): Promise<NetworkCheck>
  getSolBalance(addr: string): Promise<number>
  getTokenBalance(owner, mint): Promise<number>
}

Configured by

NEXT_PUBLIC_SOLANA_CLUSTER
NEXT_PUBLIC_SOLANA_RPC_URL

Full protocol documentation GET /api/status

Privacy model

OrangeCurve is designed around one asymmetry: market rules should be public so that anyone can verify them, and individual positions should not be so that participating does not publish your finances.

Today only half of that exists. Monero provides genuine private value transfer, available now. What does not yet exist is a private representation of a launched token: Monero mainnet has no native custom private assets, and saying otherwise would be the one dishonesty this project cannot afford.

So a token launched through OrangeCurve today is a standard SPL token with public balances. Routing SOL through Monero on the way in does not change that, and no amount of front-end design can. What is real today is the reward side: fees accrue in XMR and settle in the Monero.

End-to-end private participation is the protocol objective, and it is stated as an objective everywhere in this interface. The components below are what stand between here and there.

Research track

What is unfinished

Planned

Confidential balancesspecified
Must guarantee: A holder position must be readable by its owner and by nobody else, while remaining provably within total supply.
Commitment-based note model with an append-only note tree, in the shape Monero already uses for value. The open question is not the primitive but where the tree lives: Monero mainnet has no native custom private asset, so this needs either a ZSA-style protocol change or a separate proving system anchored to Monero.
Private order submissionopen problem
Must guarantee: Order size and direction must not be inferable before, during, or after execution.
Encrypting an order is easy. Preventing the sequencer, the relayer, or an observer of timing and gas patterns from reconstructing it is not. Any honest design here includes batching with a fixed cadence and a decoy policy, both of which cost latency.
Settlement proofsresearching
Must guarantee: Anyone must be able to verify that a batch settled according to published market rules, without learning any participant position.
Circuit design for a batch-auction settlement proof, including the fee split. Cost and proving time are the binding constraints, not feasibility.
Nullifier setspecified
Must guarantee: A note must be spendable exactly once, without revealing which note was spent.
Standard construction. The engineering risk is operational: nullifier-set growth, and the availability requirements on whoever serves it.
Metadata resistanceopen problem
Must guarantee: Network-level observation of OrangeCurve clients must not deanonymise participants.
The front end is the weakest link. IP addresses, request timing, and RPC provider logs can defeat on-chain privacy entirely. Mitigations exist (self-hosted RPC, Tor, client-side filtering) but none are default-on today.

Fee schedule

Every fee is a fixed share of trade value, chosen from a published menu at launch and immutable afterwards. There are no hidden spreads, no dynamic fees and no fee the creator can raise later.

Fixed

Protocol fee

0.50%

Same for every token. Funds protocol development.

Recipient

Not configured in this build. A deployment must set NEXT_PUBLIC_FEE_RECIPIENT so the address is inspectable before anyone trades.

Chosen at launch

Holder XMR rewards

0 – 1%

Routed to holders, paid as private XMR on a published cadence, weighted by time held.

0.00%
0.25%
0.50%
0.75%
1.00%

Chosen at launch

Creator fee

0 – 1.50%

Paid to the launching address. Also immutable.

0%
0.50%
1%
1.50%

Trust assumptions

Who you have to trust, and for what. A privacy protocol that will not enumerate this is asking you to trust it blindly.

You trust the front end you are reading
high
A compromised or substituted front end can show you one destination and ask your wallet to sign another. This is the single most likely attack on any application of this shape. Always read the instructions your wallet shows you, not the ones this page shows you.
You trust the RPC endpoint
medium
An RPC provider sees your IP address, your queries and the timing of both. On-chain privacy does not survive an RPC that logs everything. OrangeCurve verifies the cluster by genesis hash but cannot verify the operator. Self-host it if the privacy matters.
You would trust the conversion provider
high
Any SOL→XMR route means somebody holds value in between. That party can steal it, be compelled to freeze it, or log the correlation between your Solana address and your Monero address. No provider is configured here, and none will be adopted without publishing this analysis for that specific provider.
You would trust the payout signer
high
Private payouts require a service with Monero spending authority. That service is a custody risk and a correlation risk — it necessarily learns which addresses receive what.
You trust Solana and Monero themselves
medium
Consensus failure, chain halts and validator censorship on either chain are outside anything OrangeCurve can mitigate.
You do not have to trust the market rules
medium
This is the one place the design removes trust rather than adding it: curve parameters and the fee split are committed at launch and immutable. The long-term goal is that settlement proofs make the accounting checkable without trusting the operator either.

Networks

Deployment status

Solana cluster: mainnet-betaDevnet
Launchpad program: Not deployedPlanned
Fee recipient: Not configuredPlanned
Monero settlement: No signer configuredPlanned
Private market contracts: NonePlanned
Build: localLive

Assurance

Audit status

Planned

OrangeCurve has not been audited.

No contract has been reviewed, because no contract has been deployed. No front-end review has been performed. This interface does not display an audit badge anywhere, and it will not until a real engagement has produced a real report at a resolvable URL.

The parts that are testable are tested: the Bech32 and Bech32m implementation is checked against the BIP-173 and BIP-350 vectors, and the reward-splitting maths is deterministic and sums exactly. Neither of those is an audit.

Security

Threat model

Published

The full document covers wallet compromise, bridge custody, relayers, MEV, metadata leakage, timing correlation, reward claims and front-end compromise, with mitigations and residual risk for each.

Front-end compromise
Wallet compromise and blind signing
Bridge and conversion custody
Relayer and sequencer trust
MEV and ordering
Metadata and network-level leakage
Timing correlation across chains
Reward claim linkability

docs/THREAT_MODEL.md in the repository

The shield boundary

Implementation status

Six layers, one contract each

Solana entry adapter

Privacy model

Fee schedule

Trust assumptions

You trust the front end you are reading

You trust the RPC endpoint

You would trust the conversion provider

You would trust the payout signer

You trust Solana and Monero themselves

You do not have to trust the market rules