How Ultraviolet
works.

Overview

Ultraviolet runs one purpose-built application on its own execution layer above Solana: token launches, trading on a bonding curve, graduation to a constant-product pool, transfers, and SOL withdrawals.

• Pre-confirmed when you sign. A sequencer accepts signed requests and pre-confirms them right away.
• Proven on Solana. Requests are grouped into batches. Every batch is proven with a RISC Zero validity proof, and the proof is verified on Solana.
• Data on Solana. Every batch's data is published on Solana, so anyone can rebuild the state.
• Native SOL. SOL is held by a custody program on Solana mainnet. You deposit and withdraw native SOL.
• Fees burn. The protocol charges 0.25% per trade, and 100% of protocol fees buy back and burn the parent token on Solana.

Quickstart

1. Connect a Solana wallet

   Use a wallet that supports message signing. Actions on Ultraviolet are signed messages: your wallet signs the complete request (who you are, your account nonce and every argument), so nobody can change it in transit. Deposits and claims are ordinary Solana transactions that you sign in the same wallet.

2. Deposit SOL

   On the Portfolio page, send SOL from your wallet to the custody program on Solana. It's credited on Ultraviolet once the next batch processes your deposit.

3. Launch a token

   On Create, set the name and ticker, the total supply, the virtual SOL reserve and the graduation threshold. You can make the first buy in the same flow. The whole supply starts on the bonding curve. There's no mint authority and no team allocation: the creator buys in like everyone else.

4. Trade

   Buy or sell on the curve, or in the pool once a token has graduated. Pick a slippage tolerance (0.5%, 1%, 3% or 10%). The trade panel shows what you'll receive, your guaranteed minimum, and the 0.25% fee before you sign.

5. Withdraw and claim

   Request a withdrawal on Portfolio. Your Ultraviolet balance is debited right away. Once the batch containing your withdrawal is proven and settled on Solana, a Claim button appears. One Solana transaction pays the SOL to your wallet.

Concepts

Launches

A launch creates a new token on Ultraviolet with three parameters:

Total supply

A fixed number of tokens, at least two base units. All of it starts in the bonding curve; nothing is minted later.

Virtual SOL reserve

Sets the starting price shape of the curve. It affects pricing only and never counts as real collateral.

Graduation threshold

The amount of real SOL the curve must raise before the token graduates to a pool.

Token metadata (name, ticker, image) is bound by hash to the token's ID, and apps show it only when it was set by the market's creator.

Bonding curve & graduation

Until graduation, every buy and sell trades against the bonding curve. When a buy pushes the curve's real SOL reserve past the graduation threshold, the token graduates in the same transaction:

• The curve's real SOL reserve and a proportional amount of the remaining tokens form a constant-product pool on Ultraviolet.
• Surplus tokens are permanently locked in the market. They stay part of the fixed supply: locking isn't burning.
• Creators can't withdraw the pool's reserves or the locked tokens.

Edge case: graduation rounds pool tokens down. If that would leave the pool with zero tokens (very low supply or unusual reserves), the buy that crosses the threshold fails as a whole and changes nothing.

Fees & buyback

• Buys pay 0.25% of the SOL you put in. Sells pay 0.25% of the gross SOL out.
• The fee rounds up to a whole lamport, so very small trades can pay a slightly higher effective rate. Example: a 100,000-lamport buy pays a 250-lamport fee.
• A failed trade changes nothing and pays no fee.

Where the fee goes. 100% of protocol fees go into the buyback budget, kept separate from user balances, market reserves and pending withdrawals. Earned fees are claimed on Solana to the parent token's creator wallet. That wallet buys the parent token ($UV) on pump.fun (bonding curve or PumpSwap) and burns exactly what it bought, both in the same Solana transaction. You can check each burn on Solana against the parent token's mint.

Solana transaction fees, rent and venue charges are paid separately from operating funds or as part of the purchase. Fee SOL that isn't spent stays allocated to future buybacks.

Sequencing & pre-confirmations

A single sequencer receives signed requests, checks them, and returns a pre-confirmation. That's a fast answer that your request was accepted, not finality. Finality comes when the batch containing your request is proven and settled on Solana.

Each batch processes work in a fixed order: deposits first, then forced requests, then ordinary requests. A batch carries up to 16 user commands. Your account nonce is consumed only when your request succeeds.

Forced inclusion

If the sequencer ever ignores you, you don't need its permission. You can publish your signed request directly to the custody program's forced inbox on Solana. It holds up to 256 bytes plus a 64-byte signature, and you pay for its storage.

• Hard deadline. Every forced request and deposit has a deadline: its publication slot plus a fixed inclusion delay set when the network was deployed.
• Enforced before the proof. Settlement on Solana rejects any batch that leaves an overdue deposit or forced request unprocessed. That check happens before the proof is even verified.
• Deterministic outcomes. Every forced request gets one: 0 succeeded, 1 couldn't be decoded, or 2 was rejected (bad signature, stale nonce, insufficient balance or slippage). Rejected requests change no balances and pay no fee, and a malformed one can't block the ones behind it.
• Your deposit comes first. A forced request can't run until the deposits published before it are processed, so an operator can't make your withdrawal fail by skipping your deposit.
• Inbox limits. The inbox holds at most 16 unprocessed deposits and 8 unprocessed forced requests. Publishing to a full inbox fails without moving funds; space reopens as batches process entries.

If the operator disappears, anyone can rebuild the state from the public data on Solana, prove the next batch and submit it. If no prover is running at all, funds wait until one resumes. There's no administrator payout path that bypasses the proof.

Proofs & settlement

For each batch, a program running in the RISC Zero zkVM (3.0.6) replays every signed request and outputs a 550-byte journal. The journal binds:

• chain and program identities
• the guest image
• previous and next state roots
• batch number
• deposit and forced-inbox progress
• inclusion delay
• forced-request outcomes
• data commitment
• withdrawal root
• cumulative fees

The proof is compressed to a Groth16 proof and verified on Solana by the custody program against the exact compiled guest image. Development-mode or fake proofs can't settle, and there's no administrator fallback that accepts a state root without a proof.

State is a sparse Merkle tree. Each proof carries only the entries a batch touches, which keeps proof work bounded per batch as the network grows.

Time from batch to settlement depends on prover capacity and is being measured on mainnet. We'll publish it with its methodology.

Data availability

Every batch's transaction data is published on Solana (up to 8 KiB per batch), together with the finalized deposit inbox. A hash alone isn't enough, so the data itself is public. That's what lets anyone replay the history, check the state, and take over as operator if needed.

Deposits & withdrawals

Deposits

A deposit moves native SOL into escrow held by the custody program on Solana and creates an ordered, immutable deposit record. Ultraviolet credits a deposit only from that finalized, authenticated inbox; the operator can't invent one. If a deposit can't open a new account because state capacity is full, it's refunded to the original depositor through a proven refund.

Withdrawals

A withdrawal request debits your balance immediately and is included in the next proven batch. Once that batch settles on Solana, you claim the SOL with one transaction. Each claim uses a unique nullifier, so it can't be paid twice. The recipient is fixed in the signed request. Withdrawals and claims stay available even if new deposits are paused.

Reference

Parameters

Addresses

Only trust addresses listed here, in the app, or in the pinned post on @UltravioletNet. We never DM first.

Trust model

FAQ

Glossary

Batch

A group of up to 16 user commands, plus deposits and forced requests, that is proven and settled together.

Pre-confirmation

The sequencer's immediate acceptance of your signed request. Fast, but not final.

Settlement

When a batch's proof is verified on Solana and its new state becomes final.

Forced inclusion

Publishing a signed request directly to the Solana inbox so it must be included before its deadline.

Bonding curve

The automatic pricing curve a new token trades on until it graduates.

Graduation

When a curve raises its threshold and becomes a constant-product pool on Ultraviolet.

Virtual reserve

A pricing parameter for the curve. It isn't real SOL.

Journal

The 550-byte public output of each proof that Solana checks.

Nullifier

A one-time marker that stops a withdrawal from being claimed twice.

Parent token

Ultraviolet ($UV), launched on pump.fun. Protocol fees buy it back and burn it. Mint: 2gLnaQN8Y73Qc62gMmX6WtJQjFnbvE7vgzUJ37WJpump

Spectrometer

The Ultraviolet explorer: batches, transactions, accounts, tokens and the deposit inbox.