01 / XMR20 DOCS
About XMR20
Public records on Monero. Trading on Solana. One token supply.
XMR20 is an experimental protocol for recording token launches and signed token operations inside Monero transactions. The index verifies those records and combines them with Solana supply and bridge escrow data to show token history, balances and holders.
The XMR20 protocol and the XMR20 genesis token are related but distinct: the protocol defines how records are checked; the genesis token is a specific launch with its own Solana mint and Monero deployment receipt. Always check the mint, not just the ticker.
The launchpad, token index and wallet are live on mainnet. Supported XMR20 tokens can bridge from Solana to Monero, transfer between Monero addresses, and bridge back to Solana. The index publishes verified inscriptions, supply and holders.
Monero carries the public records.
The index applies the token rules.
Solana provides trading and bridge escrow.
XMR20 is independent of the Monero project. It is not native XMR, and Monero consensus does not enforce XMR20 balances or bridge rules.
02 / XMR20 DOCS
Inside an inscription
A signed XMR20 instruction is carried in a Monero transaction’s tx_extra field. The record identifies the operation and token, with the relevant amount, address and signature. The index checks the record and its confirmations before changing a balance.
- Create and sign a token instruction.
- Publish the record in a Monero transaction.
- Wait for at least 10 confirmations and protocol validation.
- Check the indexed result and its transaction proof.
These records are public. The index decodes them; it does not decrypt private XMR payments. Sending native XMR alone does not transfer XMR20.
How the inscription is encoded and verified
The signed envelope starts with XMR20M1 and contains a record and signature. Numbered XM2 fragments carry it in transaction extra. The decoder parses those fragments and reassembles them in order; converting the entire extra field to text is not a complete decoder.
The index checks the format, network, authorization, token identity, duplicate protection and confirmations. Bridge credits also require a matching finalized Solana deposit. Finding a marker or valid JSON alone does not create a token balance.
ON-CHAIN EXAMPLE / XMR20
From a Monero transaction to the XMR20 index.
This is the actual XMR20 genesis deployment. The yellow highlight points to tx_extra, displayed as “Extra” by the explorer: the public bytes that carry its signed token record.
MONERO TRANSACTION · EXPLORER EXCERPT
Tx hash: 2b545793fe0b5659090d2657b805613e3bbcf59b6f4f6e32940e6e58d74cba51
Tx public key: 08cb8f6a429a3a67b1d62efe5443bd5b9803e42eba7f3ededfb5f8ea5a57c3a6
← Scroll the highlighted bytes to see the complete field →
- Recorded on Monero
- 29 Sep 2026 · 14:59:22 UTC
- Network fee
- 0.00004312 XMR
- Transaction extra
- 665 bytes
- XMR20 message
- 598 bytes in 3 parts
1. Find the XMR20 pieces inside extra
Each pair of hex characters is one byte. Extra also contains normal Monero metadata. Only the three numbered XM2 fragments belong to this XMR20 message.
Select a block to inspect its exact bytes and decoded contents. Byte positions start at zero.
Selected raw bytes
Exact byte offsets and fragment headers
| Offsets | Header | Contents |
|---|---|---|
| 0–32 | 01 08 | Transaction public key · outside the XMR20 message |
| 33–280 | 02 f5 01 58 4d 32 00 03 | XMR20 part 0: 240 message bytes |
| 281–528 | 02 f5 01 58 4d 32 01 03 | XMR20 part 1: 240 message bytes |
| 529–653 | 02 7b 58 4d 32 02 03 | XMR20 part 2: 118 message bytes |
| 654–664 | 02 09 01 | Encrypted payment ID · outside the XMR20 message |
02 marks an extra-nonce container. The following length is a variable-length integer: f5 01 means 245 bytes. The marker 58 4d 32 spells XM2; the next bytes identify the fragment number and total count.
REASSEMBLE THE MESSAGE
Remove the container and fragment headers, then join the payloads in order.
XMR20M1 (7-byte marker) + {"record":{…},"signature":"SigV2…"} (591-byte JSON)
2. Decode the token’s signed record
Hex decoding reveals compact JSON. The message contains the deployment record and a signature; it contains neither a private key nor a seed phrase.
Read the actual decoded JSON
{
"record": {
"chain": "mainnet-beta",
"creator": "6WSAHauyYVefgV5YZCNkAEQ8swt2dgRKi8p6a2EY3Wgq",
"fee": "150",
"initial": "0",
"max": "1000000000000000",
"meta": "59d9cf8b1d1fe5669e9385a7e22f6b6c5f0afc9cce1aa337bfde2f18a7ad5562",
"mint": "Cy5TzDyJ4mo6MBAbpwUcAgdfNiXYKrYUPrvhPGVU6XMR",
"net": "mainnet",
"nonce": "280f790e5b1c7b5a3a518cff585a728c",
"op": "deploy",
"owner": "4AMg1kDaXkWckE3uyd1YqoBKvn4z8ATxmWQVdtjF6aGU4sT278XoyhUV1Ve88ZMCXNXQJpjW2553NWERfMZcNsBtCkMLiNM",
"p": "xmr20",
"tick": "XMR20",
"v": 1
},
"signature": "SigV21UnpWt5TWS9bYXccWr9EKWY9x4g7UxHWnPdEPXDfAYJ3fvPZxfJ2aF4d2xbSL3Bg5iXCDWseXyfFD8pSxzmkWy4A"
}What each field means
p / vxmr20 / 1Protocol and record version.
op / tickdeploy / XMR20Registers the XMR20 deployment; this is not a bridge credit.
mintCy5TzDyJ4mo6MBAbpwUcAgdfNiXYKrYUPrvhPGVU6XMRLinks this Monero record to one exact Solana token.
creator6WSAHauyYVefgV5YZCNkAEQ8swt2dgRKi8p6a2EY3WgqThe Solana wallet associated with the launch.
net / chainmainnet / mainnet-betaMonero mainnet record, Solana mainnet token.
max1000000000000000One billion tokens in six-decimal base units.
initial0Zero initial Monero availability; later credits need locked backing.
fee150150 basis points = 1.5%, declared for this launch. Separate from the XMR network fee.
meta59d9cf8b1d1fe5669e9385a7e22f6b6c5f0afc9cce1aa337bfde2f18a7ad5562SHA-256 commitment to metadata. The image itself is not in this transaction.
owner4AMg1kDaXkWckE3uyd1YqoBKvn4z8ATxmWQVdtjF6aGU4sT278XoyhUV1Ve88ZMCXNXQJpjW2553NWERfMZcNsBtCkMLiNMMonero address whose spend-key signature authorizes this deployment.
nonce280f790e5b1c7b5a3a518cff585a728cRecord identifier for replay protection; different from the extra-nonce containers.
signatureSigV21UnpWt5TWS9bYXccWr9EKWY9x4g7UxHWnPdEPXDfAYJ3fvPZxfJ2aF4d2xbSL3Bg5iXCDWseXyfFD8pSxzmkWy4AThe SigV2 signature authenticates the canonical record under the XMR20 signing domain.
The meta hash commits to the token metadata, including its name, description and image link. The image bytes are hosted separately. A matching hash verifies the metadata commitment; it does not put the image itself on Monero.
3. Validate the record and build its history
- Read the chain. The index parses transaction extra and joins the three XMR20 fragments. It reads transaction bytes, not this explorer view.
- Check authorization. It checks the format, network, signature, deployment authority and protocol rules, then waits for at least 10 confirmations. Valid JSON alone is not enough.
- Follow later operations. This deployment transaction identifies the token. Later credits, transfers and return burns must satisfy their own signature, balance and backing rules.
- Publish checked balances. The index combines the Monero ledger with finalized Solana supply and escrow data. A deployment receipt alone does not prove a completed Solana launch or create a Monero token balance.
Open this XMR20 inscription →View the Monero transaction ↗Download bytes + decoded JSON
03 / XMR20 DOCS
Launch an inscription token
The launch flow pairs a Monero deployment record with a Solana token and wXMR trading pool. Launch actions take place in a compatible launch interface, with wallet approval.
- Connect a Solana wallet and choose a Monero mainnet address. Enter a name, ticker, image, optional description and project links.
- Choose Normal or Turbo mode and an optional initial purchase in SOL.
- Review the displayed inscription service fee, currently 0.01 SOL. It is separate from the initial purchase and network/account costs.
- Wait for the Monero inscription to reach 10 confirmations.
- Approve any SOL-to-wXMR conversion and the Solana launch. The token appears in the public index once the required proofs are verified and the listing policy allows it.
Turbo reaches graduation with less funding, so purchases have greater price impact and the graduated pool starts with less liquidity.
Each launch starts with 1 billion tokens and six decimal places. An inscription alone creates no spendable Monero balance; confirmed locked Solana backing is required. Browser-saved launch recovery depends on retaining the original browser’s stored data.
04 / XMR20 DOCS
Wallets & recovery
Your Solana wallet approves Solana transactions. Your Monero spend key authorizes XMR20 instructions for the associated Monero address. The index tracks the token balance; an ordinary Monero wallet may show only native XMR.
Keep the recovery backup for every Monero address you use. Saving a public address or signing in with a Solana wallet does not recover a lost Monero key. Where a compatible interface supports local recovery, it depends on the encrypted backup still being present on that device.
Browsing the index does not require a wallet connection. Launching and transferring use the connected wallet. Monero recovery material stays on your device; only the signed instruction is submitted to the service.
Saving a Monero address chooses a destination; it does not prove ownership or give a Solana wallet access to its spend key. Sending native XMR to that address does not move an XMR20 token balance.
05 / XMR20 DOCS
Bridge between networks
Move a supported XMR20 token between Solana and its indexed Monero balance using the connected wallet. This does not exchange native SOL for native XMR or create a second token supply.
Solana → Monero
- Open your wallet, select the token and choose Bridge to Monero.
- Review the amount and destination, then approve locking the tokens in the Solana bridge vault.
- The service verifies the finalized deposit and inscribes a credit record on Monero.
- After 10 confirmations and validation, the index credits the Monero address. The Solana backing stays locked.
For tokens with a transfer fee, the credited amount follows the net backing actually received.
Monero → Solana
- Select the token in your Monero wallet view and choose the return bridge.
- Sign a return-burn instruction naming the amount and destination Solana wallet.
- After confirmation and verification, the operator attests to the burn and the receiving Solana wallet approves release.
- The vault releases the existing backing. It does not mint replacement tokens; transfer fees may reduce the amount delivered.
Saved bridge progress distinguishes wallet approval, source confirmation, inscription and destination confirmation. Wait for the recorded operation to finish before starting another transfer.
Each transfer is limited to 50 million tokens, or 5% of the original supply. This is a per-transfer limit, not a limit on the entire vault. Bridging requires a supported token with an activated escrow.
Backing and bridge trust
Locked backing is not a second supply. A return burn removes the Monero representation so the same backing can be released on Solana.
The bridge depends on an operator attestor. Solana does not independently execute the Monero indexer’s rules. A compromised attestor could authorize an invalid withdrawal; an unavailable attestor can delay returns. Comparing two Monero nodes helps check chain data but does not remove this dependency. The bridge has not been independently audited.
06 / XMR20 DOCS
Transfer on Monero
A dedicated XMR20 transfer instruction moves an indexed token balance from one Monero address to another. The sender signs it; the index checks ownership, available balance, duplicate protection and confirmations before debiting the sender and crediting the recipient.
Use the XMR20 wallet to transfer supported tokens between Monero addresses. Transfers update the indexed balances after signature verification and 10 confirmations. You can then bridge the balance back to Solana.
The record’s Monero carrier transaction needs an XMR network fee. The treasury pays that fee for instructions accepted by the operated service. This does not make native Monero transactions free. The sender’s authorization and the carrier’s fee payment are separate.
07 / XMR20 DOCS
Trade against wXMR
XMR20’s Solana market pairs the token with wXMR. In a compatible SOL-funded buy flow, the amount you enter is SOL: it is converted into wXMR and then used for the token purchase. The conversion and purchase can require separate wallet approvals.
If conversion succeeds but the token purchase fails, the wXMR can remain in your wallet. Review the quote, minimum output, transfer fee and network costs before approving. Pool reserves determine price impact; an inscription does not create liquidity by itself.
Native XMR exists on Monero. wXMR is a Solana asset with public transactions and its own wrapping/redemption arrangements. Exchanging XMR and wXMR is separate from bridging an XMR20 token balance.
08 / XMR20 DOCS
Fees & allocation
The current XMR20 genesis token uses a 1.5% token transfer fee. It applies to token transfers, including relevant buys, sells and wallet transfers. Pool fees, network fees and the inscription service fee are separate; check each transaction’s quote.
Transfer-fee example
A transfer of 1,000 tokens withholds 15 tokens and delivers 985. Withheld fees remain part of the Solana token supply, but are not spendable holder balances. The index shows them separately until collected.
Collected trading-fee tokens can be converted into wXMR to fund the configured buy-and-burn process. The current fund allocation is 100% to buybacks and burns. The 0.01 SOL inscription service fee pays the inscription treasury and is not part of that trading-fee allocation.
Historical tokens keep their own on-chain settings. A change to documentation does not change a token’s fee configuration.
09 / XMR20 DOCS
XMR20 buybacks & burns
At the 29 September 2026 documentation check, the automation was paused awaiting the owner-approved contract upgrade for XMR20 buybacks. XMR20 is the intended target; this page does not claim that target is already active.
The intended flow is to collect eligible fees, convert collected tokens to wXMR, buy XMR20 and permanently burn the purchased tokens. A completed purchase and burn should be verified from its finalized on-chain receipt.
The deployed limits at this check allow up to 2 wXMR per purchase, at least five minutes between purchases and 28.8 wXMR per daily window. A separate liquidity limit can make actual purchases much smaller. The interval is an eligibility limit, not a promise to buy every five minutes. Any changed limits need the appropriate contract approval.
A historical dollar burn total records each completed purchase’s cost using its historical wXMR/USD price, then adds those saved amounts. It should not revalue past burns at today’s token price. Missing price data should be marked pending, not guessed.
The fund is controlled by a Solana program and has no private key. Its deployed rules restrict spending; the current contract has no arbitrary withdrawal function. The program remains upgradeable by its owner, so future rules can change through an approved upgrade. Automated execution also needs SOL for network costs.
Buybacks do not distribute rewards to holders or guarantee a price increase.
10 / XMR20 DOCS
Supply & holders
The original supply is 1,000,000,000 tokens. The explorer reconciles Solana balances outside escrow, confirmed Monero balances, transfers in transit, unassigned escrow and permanent burns against that original supply.
Solana backing is counted once, through the corresponding Monero balance or pending bridge category. A permanent Solana burn reduces the remaining supply; a bridge return-burn releases existing backing.
Solana accounts are grouped by owner, including pools and programs. Monero rows are public XMR20 ledger addresses. Holder percentages use current supply after permanent burns; chain shares use the original supply. Withheld transfer fees are included in Solana supply but excluded from spendable holder rows.
View current supply and holders →
For example, a confirmed Monero balance of 500 tokens is backed by 500 tokens in escrow. Those are the same 500 tokens represented on two networks: count the spendable Monero balance once, not again as circulating Solana tokens. A bridge vault is backing, not a liquidity pool.
11 / XMR20 DOCS
Indexing, privacy & recovery
The index scans the configured Monero chain range and validates signed records in block and transaction order. It checks confirmations, token identity and backing, and combines the result with finalized Solana account data.
Confirmed on-chain history remains available if the website goes offline. Rebuilding the index requires the same rules and configuration; running the service also requires preserved signing keys and operational records. Lost private keys cannot be recreated from blockchain history.
If an upstream check fails, the explorer retains the last verified snapshot and marks it delayed. Missing data must never be treated as a zero balance.
XMR20 records publish token amounts and relevant addresses. Bridge activity can connect identities across networks. Native Monero payment privacy does not make these public token records private.
The XMR20 standard at a glance.
- Protocol / version
xmr20/ versioned inscription records- Operations
deploy·credit·transfer·burn- Original supply
- 1,000,000,000 tokens · 6 decimals
- Ticker format
- 1–10 uppercase letters or digits, starting with a letter
- Ticker reservation
- Tickers can be reused by new launches. Each token is identified by its inscription and Solana mint; the index marks the first inscription of each ticker.
- Token identity
- Deployment transaction plus the exact linked Solana mint; the ticker alone is not proof of identity
- Confirmation threshold
- 10 Monero confirmations; finalized Solana receipts
- Bridge limit
- Up to 50,000,000 tokens per transfer
- Monero destinations
- Primary standard addresses on the matching network; no subaddresses or integrated addresses in this pilot
- Networks
- Monero mainnet + Solana mainnet; a separate Monero stagenet lab
These are application rules enforced by the current implementation. They are not native Monero consensus rules or an official Monero token standard.
Working on mainnet.
Mainnet launches, inscriptions, indexing, both bridge directions and signed wallet-to-wallet XMR20 transfers have been demonstrated. Availability depends on the token, connected wallet and live verification checks. The bridge has not been independently audited.
Inscriptions, supply & holders
Deployment records, confirmation progress, Solana launch status and cross-chain supply snapshots. Solana holders appear before a first bridge, including a verified zero-Monero-holder state.
Solana lock to Monero credit
Confirmed Solana deposits back Monero XMR20 balances. The index verifies the locked amount before crediting tokens, and shows that backing separately from permanent burns.
Return bridge & wallet approval
An authorized Monero burn releases the matching escrowed tokens on Solana. The bridge checks the burn, amount and destination before allowing the return transfer. Transfer-tax tokens receive the amount remaining after the transfer fee.
Launchpad & automatic escrow
Launch tokens on Solana with a verified Monero inscription. Supported launches receive automatic escrow activation. Follow confirmation and launch progress in your saved order.
Monero wallet-to-wallet token transfers
Signed XMR20 transfer records move token balances between Monero addresses. Confirmed transfers and a return have been verified on mainnet. The connected wallet and token must be enabled for the operation; native XMR payments do not transfer XMR20 tokens.
PRACTICAL QUESTIONS
Before you launch
Does “inscribed” mean my token has launched?
Inscribing means the Monero record is awaiting confirmations. Inscribed means it has reached the required proof threshold. Launched also requires finalized Solana token creation. An inscription receipt alone does not prove a funded trading pool exists.
Where are the token name and image stored?
The deployment commits to a metadata hash. Names, descriptions and images are served separately through content-addressed links. The hash makes metadata changes detectable; it does not guarantee hosting availability.
Do I need to connect a wallet to read the index?
No. You can read inscriptions, supply, holders and transaction proofs without connecting. Launching, bridging and transferring require wallet authorization.
12 / XMR20 DOCS
Project references
Use the exact mint and transaction proof when checking a token.
- XMR20 genesis mint
Cy5TzDyJ4mo6MBAbpwUcAgdfNiXYKrYUPrvhPGVU6XMR- Network
- Monero mainnet + Solana mainnet
- Confirmations
- 10 on Monero; finalized receipts on Solana
Documentation reviewed 29 September 2026. Transaction receipts and deployed settings establish what is active. XMR20 is independent of the Monero project.