Skip to main content
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.

​
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/<curve_address>. 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. 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.