Category: Wallets

A self-custodial Minotari wallet with the Ootle account built in, where you can burn XTM on L1 and have it claimed on Ootle automatically, with nothing to install.

• Live app: https://universe.tari.mw
• Code: https://github.com/chironbuilds/tari-l1-wallet-ui
• Ootle SDK used by the wallet: https://www.npmjs.com/package/@chironbuilder/ootle-sdk https://github.com/chironbuilds/ootle-sdk-ts (MIT)
• Ootle wasm additions: https://github.com/chironbuilds/tari-ootle/tree/support-ootle-0.41.0

A web wallet for Tari layer 1 that also givent derived from the same 24-word recoveryphrase. Keys are generated and every transaction is built and signed locally in WebAssembly; the page talks only to the public base node query service and the O

The headline feature is Burn to Ootle: ule meant running minotari_console_walletplus the Ootle wallet daemon, copying proof files between them, and waiting. In this wallet it is one form:

• Pick an amount and burn. The burn transaction is signed in the browser and broadcast.
• The wallet watches for the burn to be minerkle proof from the base node itself.
• Once the Ootle validators accept the L1 block (about 100 blocks deep on Esmeralda, under an hour), the wallet claims it into your Ootle account as private

You can also burn to any other Ootle accountproof for them, and claim a burn madeelsewhere (for example a minotari_console_wallet proof file) from the Ootle side.

• Runs in any browser, with nothing to download and no chain to sync (scanning runs in parallel web workers agathe public query service).
• MainNet and Esmeralda testnet, chosen with a toggle when you create or restore a wallet. - Ootle built in: public and private sends, ering private funds, the testnet faucet, anda catalogue of Ootle apps. - Burn to Ootle with automatic claiming, as
• A dApp connector (window.tari) with the same provider API as the Sapient extension, so an Ootle dApp works either wallet.
• Also: PIN lock and auto-lock, sub-addresses, opt-in sender reveal, sign-now-broadcast-later, and developer to

The burn flow needed new pieces at three layers, all mirroring the reference wallets exactly:

• L1 burn builder (tari_l1_wasm, vendored in the repo): builds a burn the way the console wallet’s burn_does. The on-chain claim key is the stealth e Ootle account key never appears on chain;the encrypted value is keyed to ''DH(P, r), and r` derives from the commitment mask, so a burn’s proof can be regenerated from the seed. * Ootle wasm (burnClaimStealthSecret, ''validateBurnClaimOwnershipProof): derives the claim secret s = H(p·R) + p that seals the claim, and checks the ownedator will, before anything is submitted.
• Ootle SDK (OotleAccount.claimBurn): mints the burn with ClaimBurn and spends it into a stealth output owned by the account, sealed with s. The fee is claimed value, and a stealth-revealed fee is never refunded, so the fee is measured with a dry run (metered cost plus the engine’s estimate allowance) rather than padded.

Tested end to end on Esmeralda with real tra

• A 10 tXTM burn, mined in L1 block 914,01986744 tTARI (claim transaction 4df34e29632a2db78f4f1cb0a9766fe5d7197a88d1b1b734d03ba42deab251a4). Fee: 13,256 µT, the 13,244 metered plus the 12 µT allowance, so nothing was overpaid.
• A cross-implementation fixture: a burn built by the new L1 builder is verified by Ootle’s own ownership-proof check and decryption, in the Ootle wasm test suite
• The L1 burn passes the base node’s own transaction consistency validator in a native test.
• Two bugs found and fixed along the way, bo only by s was rejected with “no mainsigner” because the TS transaction builder leaves the seal signer unauthorised by default; and balances hid stealth funds for accounts not yet on chain, which ied burn lands.

===== Entry details =====

• Payment address: 12Gtjb5qbgYBbF9meZ31HKnEusGgnwfbDYBcZV3k4xko1htBQisjvgMW1zJL4gERkcryLntDKLqK2GQ2xEKD2i6Bq8s
• Announcement: https://x.com/Erebus_Lab/status/2103207133026406589
• Email:0xhra@proton.me