Use Shield6
Shield6 is TKMChain's current confidential-payment system. Mainnet activated the production recipient-proof parameters on 6 November 2026 at 18:16:54 UTC, starting with the v1.21.83 release configuration. Check the connected node's current status before sending.
Open the Shield6 web wallet · Set up a local wallet · Send from the interactive console · Exchange and service-provider integration
Receive · Fund private notes · Send · Recovery
Choose your wallet
- Web wallet: register recipient keys and read your payment code using the network RPC, with the proof and signature created in your browser. Scans and payments use a configured local wallet service or optional wallet-server proving.
- Interactive console: run a synced local node and install the authenticated public parameters. The wallet proves and signs locally using your encrypted keyfile, then broadcasts through local IPC.
Both routes use the same mainnet, chain ID 8979, and registered receiving codes beginning tkmshield6r.. Your public 0x account address is not your Shield6 receiving code.
Before you start
Use an ML-DSA-87 wallet and back up its encrypted keyfile, including its saved stamp data. Account stamping and Shield6 recipient-key registration are separate steps. Keep enough public TKM for gas, even when the payment itself spends private notes.
Public TKM and private Shield6 notes are different balances. A private send can spend only owned, unspent Shield6 notes. Shielding public TKM creates a private note; registration by itself does not fund that private balance.
Receive using the web wallet
- Open the official Shield6 wallet and unlock the intended stamped ML-DSA-87 keyfile.
- If the account is not stamped, use Stamp address first and wait for successful on-chain registration. Keep the updated stamped keyfile backed up.
- Choose Register Shield6 recipient keys via network RPC. Review the public gas cost and immutable key-binding authorization. The registration proof and signature are created in this browser.
- Choose Check pending Shield6 transactions and verify 12 canonical confirmations before relying on the registration.
- Choose Show Shield6 payment code and copy the complete
tkmshield6r.code. Share that code with the payer or pool administrator.
Browser registration downloads about 217 MB of authenticated public parameters on first use and may take several minutes to prove. It does not require a localhost wallet token. Registration permanently binds the recipient-key commitment to the stamped account; restore the original keyfile instead of creating replacement keys for that account.
Fund your private balance
- Review your public TKM balance and retain gas funds.
- Enter an amount beside Shield TKM, then choose that button.
- Review the proving option and any seed-sharing consent before authorizing the deposit.
- Check the saved transaction until it has 12 canonical confirmations, then choose Refresh Shield6 balance.
A deposit publishes the public sender and deposit amount. The resulting private note is encrypted to your Shield6 wallet. A withdrawal also publishes its public destination and amount. These are visible entry and exit boundaries, not private transfers between two Shield6 codes.
Send from the web wallet
- Obtain the recipient's full, registered
tkmshield6r.code on this network. - Paste it into the recipient field and enter the TKM amount.
- Choose Send Shield6 private TKM and review the amount and proving option.
- Keep the page open while proofs are built. Once a transaction hash is returned, use Check pending Shield6 transactions to verify 12 canonical confirmations.
The wallet keeps the original request ID, recipient and amount for recovery after an interrupted response. Use Restore saved payment details to restore those fields. An uncertain request must be checked through its original proving service before starting another payment.
Local proving or wallet-server proving
With a local service, configure the loopback URL and its token in the wallet. The token stays in the page. Your local service should explicitly allow the official wallet origin. See the local setup guide.
With optional wallet-server proving, each scan or payment asks before uploading your unlocked seed over HTTPS. The server operator can sign and spend from that account while processing it. Choose this only if you accept that trust boundary. Registration and payment-code display continue to use browser-side cryptography and the network RPC regardless of the payment-prover selection.
The 16-input limit
A payment can consume at most 16 private notes. A large total private balance may therefore exceed the amount usable in a single transaction. The web wallet shows both the private balance and the maximum usable for one payment.
If a payment is rejected before submission, review the displayed diagnosis. Insufficient balance and funds spread across too many notes are different problems. Review public funding fills the deposit form for review; it does not send funds. The suggested top-up leaves one input slot for the new deposit and counts only the largest 15 existing notes. You can also choose a smaller payment amount. Retain the original recipient and amount if you intend to retry them after funding.
Confirmation and recovery
A transaction hash means submission, not final confirmation. A brief network failure does not prove that nothing was submitted. A definitive not submitted result releases a rejected request for a fresh authorized attempt; a missing hash or ordinary transport error does not.
For a failed or interrupted console broadcast, save the reported transaction hash and inspect its receipt and canonical block before deciding whether to send again. See the console recovery steps.
Privacy and setup provenance
Shield6 combines encrypted notes, one-time output keys, bounded rings, CLSAG authorization, range proofs and recipient-stamp binding proofs. Public transaction hashes, inclusion, fees and protocol metadata remain visible. ML-DSA-87 protects account signatures; that does not make every proof component post-quantum.
The deployed Groth16 parameters came from a single-operator setup, not an independent multiparty ceremony, and have not received an independent cryptographic audit. Use the published parameters and consensus pins. Generating replacement keys locally does not create parameters compatible with mainnet.
Read the privacy overview · Read the recipient-proof specification · View release parameters and hashes