> ## Documentation Index > Fetch the complete documentation index at: https://tonch.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Security > What's safe about tonch, what's not, and how to verify the on-chain guarantees yourself. This page is a candid breakdown of the security properties of the tonch protocol — both the strong guarantees and the open risks. It's written for traders and deployers who want to understand the trust model before putting funds in. ## What's permanent **LP Jettons are permanently locked at graduation.** The LP locker contract has only one accepted opcode (`op::lock_lp`, received via `transfer_notification` from the LP-Jetton wallet). There is no withdrawal, no admin upgrade, no migration path. The contract source is on chain and verifiable. **The bonding curve cannot be re-priced or paused.** Once a curve is deployed, its constants (virtual reserves, target, fee bps) are immutable. The factory does not retain the ability to retroactively change a per-launch curve. **Total supply is fixed at 1B per launch.** The Jetton master mints exactly 1B at deploy time, then the curve burns the unsold remainder at graduation. No further mints are possible — the Jetton master's admin is set to a non-functional address after the initial mint. **Code hashes are deterministic.** Every launch deploys identical bytecode for the curve, Jetton master, Jetton wallet, and LP locker. You can verify this by comparing code hashes on Tonviewer against the canonical hashes in [Reference / Contracts](/reference/contracts). ## What's controllable by the protocol **The factory owner can change the treasury address.** The factory exposes a single admin opcode, `op::set_treasury`, callable only by the configured owner. This redirects future graduation cuts and launch fees to a different recipient. It does **not** affect already-deployed curves' fee accumulation or graduation behavior — only where new fees flow. **The factory has no `op::pause` or `op::set_calibration`.** Once deployed, the factory's calibration constants (supply, fee, graduation target, virtual reserves) cannot be changed. To change calibration, the protocol must deploy a fresh factory at a new address — invalidating the frontend's pointer until the env var is updated. **The keeper has no privileged actions on a per-launch basis.** The keeper triggers graduation via `op::graduate` and sweeps protocol fees, but `op::graduate` is permissionless — anyone can trigger it. The keeper is a convenience. ## What's currently single-key **The factory owner is a single keypair.** As of the current mainnet deployment, the `owner` address is a single externally-owned wallet, not a multisig. If that key is compromised, an attacker could redirect future treasury cuts to their own address. They could **not** drain existing curves' funds, change supply, unlock LPs, or affect deployed Jettons in any way — only redirect future fees. Migrating to a multisig is on the Plan 4 roadmap. **The mainnet deployer keypair was used to publish the factory.** It has no ongoing on-chain role — it's not the owner, treasury, or keeper. Compromising it now would only affect the small TON balance left in that wallet for redeploys. ## What hasn't been formally audited The bonding-curve sale, LP locker, and launchpad factory contracts are written in FunC and have been: * Tested via 118+ contract-level Sandbox tests covering the full launch → buy → sell → graduate → lock flow plus edge cases. * Tested via the off-chain simulator that exhaustively explores curve trajectories. * Validated end-to-end on testnet and mainnet smoke launches. They have **not** undergone a formal third-party audit. Plan 4 includes engaging an auditor before scaling traffic. Until then, the level of assurance is "extensive internal testing", not "audited". ## What relies on external services **DeDust v2.** Graduation depends on DeDust's pool deploy and liquidity deposit working correctly. If DeDust's contracts have a bug, a graduation could stall mid-migration. tonch's graduation is idempotent and re-triggerable, so a stalled graduation can be resumed manually if the underlying issue resolves. **TonConnect wallets.** Signing flows depend on Tonkeeper / MyTonWallet / etc. honoring the destination + value + payload they show you. A compromised wallet could rewrite the destination or amount before signing. Defense: review the destination address and value in the TonConnect modal before approving every transaction. **Indexer.** The token list, trade history, and aggregates on tonch.app are served by an off-chain indexer reading from TON. The indexer can lag, get out of sync, or display stale data. **It is never the source of truth for funds.** When in doubt, read the contract directly on Tonviewer. ## How to verify yourself For a specific token, you can confirm the security properties by: 1. **Open the LP locker on Tonviewer.** Address: `lp_locker_address` from `GET /api/launches/`. Read the source — confirm there's no withdrawal opcode. 2. **Check the LP locker's Jetton balance.** It should match the LP supply minted by the DeDust pool at graduation. You can read DeDust's pool's LP supply via its `get_jetton_data` getter and compare. 3. **Verify the bonding curve's code hash.** Compare against the canonical hash listed in [Reference / Contracts](/reference/contracts). Mismatch = different code = don't trust. 4. **Verify the Jetton master's code hash and supply.** Confirm it's 1B total supply minus burned curve leftovers, and the admin is the factory. 5. **Read `get_factory_config` on the factory.** Confirm calibration matches what the docs claim. If anything looks off, surface it on the [tonch GitHub repo](https://github.com/TonchOnTon/tonch/issues).