> For the complete documentation index, see [llms.txt](https://docs.kton.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kton.io/getting-started/06-security-and-audits.md). # Security and Audits KTON security: the TonBit audit and which version each pool runs, the 3-of-4 multisig roles, pauses and the risks of staking. Security is the foundation of any staking protocol, because you are trusting code to hold your Gram while it earns yield. This chapter explains how KTON has been independently reviewed, how its on-chain control model limits what any single party can do, and what risks remain that you should understand before you stake. ## Independent audit: TonBit (BitsLab) KTON V2 was audited by TonBit, the smart-contract audit arm of BitsLab and a recognized security assurance provider in the TON ecosystem. The audit covered the full contract suite that powers the protocol: the pool, the jetton minter and wallet, the validator controller, and the payout-NFT distribution contracts. | Audit detail | Value | | ---------------- | ---------------------------------------------------------- | | Auditor | TonBit (BitsLab) | | Report date | 26 May 2025 | | Review window | 3 April 2025 to 26 May 2025 | | Files in scope | 27 | | Total findings | 5 | | Critical / Major | 0 | | Medium | 3 | | Informational | 2 | | Status | Fixed in the audited source; see below for what runs where | There were zero Critical and zero Major findings. The five issues that were identified break down into three Medium-severity findings and two Informational findings, and all five are fixed in the audited source. **What runs where.** The audit started from the code the public KTON pool runs: its first commit, `10786c7`, has the same contract code as the public pool's `49db7f8` (only a schema comment file differs). The five fixes went into later commits, in `pool.func` and `controller.func`. There are two final reports dated 26 May 2025: * one for the fixed public version (the `v2` branch, `8c38579`), which neither pool runs; * one for the private pool's code (`1d919bd`, the fixed version plus one change: withdrawals are always paid to the wallet that burned the KTON). The private pool's deployed files match that report's file list byte for byte. The public pool, deployed on 21 March 2025, has not been upgraded since, so it runs the code the audit started from, without the five fixes. Each pool's `get_code_version` getter returns the commit it was built from: `49db7f8…` for the public pool and `1d919bd…` for the private pool (read on 23 October 2026). ### Findings summary | ID | Severity | Title | Status | | ----- | ------------- | ----------------------- | ------ | | CON-1 | Medium | Missing Fee Check | Fixed | | POO-1 | Medium | Incorrect Rounding | Fixed | | POO-2 | Medium | Incorrect Range Setting | Fixed | | CON-2 | Informational | Incorrect Comment | Fixed | | POO-3 | Informational | Incomplete Time Check | Fixed | The `CON-` prefix denotes findings in the controller contract (`controller.func`), the component that borrows pooled Gram and stakes it with the TON Elector. The `POO-` prefix denotes findings in the pool contract (`pool.func`), which custodies Gram, mints and burns KTON, and runs round accounting. In plain terms: * **CON-1 (Missing Fee Check)** and **POO-2 (Incorrect Range Setting)** hardened input validation around fee and parameter bounds, so values supplied to the contracts are checked against their valid ranges. * **POO-1 (Incorrect Rounding)** corrected a rounding behavior in the pool's arithmetic. Because KTON's exchange rate is computed as `total_balance / supply`, rounding correctness directly affects the fairness of mints, redemptions, and round-profit accounting. * **CON-2 (Incorrect Comment)** and **POO-3 (Incomplete Time Check)** were Informational. CON-2 was a documentation fix in the source. POO-3 tightened a time-window check in round logic. None of these findings represented a loss-of-funds vulnerability in the deployed code, and every one was resolved. The full report is published by TonBit and linked from the KTON site. ## Open source and verifiability KTON's contracts are open source under the MIT license. Anyone can read the FunC source, compile it, and compare the resulting bytecode against what is deployed on-chain. This matters because the audit is a point-in-time review of specific source files; open-sourcing the code lets the wider community continue to inspect it independently and verify that the live contracts match the reviewed source. Verifiable anchors you can check yourself: | Item | Address | | ------------------ | -------------------------------------------------- | | Public KTON pool | `EQA9HwEZD_tONfVz6lJS0PVKR5viEiEGyj9AuQewGQVnXPg0` | | KTON jetton master | `EQBuIhXNNkWf9AW9miNGNTSO_uFZ23ejfIWrieXge5f733mw` | The KTON jetton master is a standard TEP-74 DAO-jetton with 9 decimals, and its admin is the public pool itself. You can confirm the pool state, the exchange rate, supply, fee parameters, and halt status directly from the chain using the pool's `get_pool_full_data_raw` getter, rather than relying on any number quoted in marketing copy. ## Trust model: roles KTON does not place control in a single key: every admin role (governor, interest manager, halter, approver) is held by the same 3-of-4 multisig, so any action needs three of its four signers. The superuser role (sudoer) has been switched off since 2026-10-23. The pool defines distinct role slots, each with its own powers. The most user-relevant roles are: | Role | What it can do | What it cannot do | | -------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Governor** | Set the sudoer, unhalt the pool, manage governance migration, set roles, set deposit settings, set the governance fee | Cannot act as superuser, cannot set the interest rate | | **Sudoer** | Superuser actions (send arbitrary messages, upgrade contract code) | Switched off since 2026-10-23: the slot is empty, so every superuser call fails. Turning it back on is a governor transaction anyone can see on chain, and the new sudoer must then wait 2 days before it can act | | **Interest manager** | Set the interest rate and operational loan parameters | Cannot move funds or upgrade code | | **Halter** | Emergency stop: halt the pool or partially halt deposits / optimistic mode | Cannot unhalt (only the governor can) | | **Treasury** | Passive fee sink that receives governance fees | Has no authority over the protocol | In the contract, the role that can pause the protocol (halter) is not the role that can restart it (governor), and the role that can upgrade the code (sudoer) is a separate slot, empty since 2026-10-23. The other slots are held by the same 3-of-4 multisig, so the split is in the contract, not between different people. ### Delays in the contract The contract has two waiting periods. Both count from the moment a role is set, not from the moment it acts: | Action | Delay in the contract | | --------------------------------------------------- | ---------------------------------------- | | Sudoer (superuser) actions, including code upgrades | 2 days (`SUDOER_QUARANTINE = 172,800 s`) | | Governor migration (prepare then execute) | 1 day (`GOVERNOR_QUARANTINE = 86,400 s`) | Upgrades to the contract code can only be performed by the sudoer. The 2-day quarantine applies to a newly set sudoer; re-setting the sudoer restarts it. Since 2026-10-23 the sudoer slot is empty, so nobody can upgrade the code or send superuser messages. An upgrade now takes two public steps: the governor sets a sudoer, then 2 days must pass before that sudoer can act, and anyone reading the pool's getter sees the first step. Fees, the interest rate, pausing and the other governor and halter actions still take effect as soon as the multisig executes them. No upgrade has ever been sent to the public pool. Pauses happen. If at round finalization the pool cannot cover queued withdrawals plus its minimum storage reserve, it halts itself and pays nobody until it is topped up, rather than paying some users at the expense of others. This happened twice in 2025, and deposits and withdrawals were refused while the pool was paused. ## Risk disclosures No staking protocol is risk-free. The following risks apply to KTON and to liquid staking on TON generally. Read them before you stake. ### Smart-contract risk KTON runs entirely in on-chain contracts. An audit substantially reduces the likelihood of undiscovered flaws, but it cannot prove the absence of all bugs, and it covers a specific version of the source at a specific time. The code can still be upgraded (the governor, a 3-of-4 multisig, can set a sudoer, which can act 2 days later), so you are also trusting that any future upgrade will be made responsibly. Only stake what you can afford to have at risk. ### Validator and slashing risk The pool lends Gram to validator-controllers that stake it with the TON Elector. Validator yield is not guaranteed. A validator that performs poorly, goes offline, or is penalized can earn less than expected, and negative round results are socialized across all KTON holders, which lowers the exchange rate for everyone in that round. Your KTON balance never changes, but the amount of Gram it redeems for can fall as well as rise. ### Variable yield KTON's yield is not a fixed or guaranteed rate. It comes solely from validator-loan interest realized each round, net of the 16% governance fee and the per-round finalize fee. The APY you see is computed live from recent on-chain performance (the app annualizes over the protocol's round cadence) and it changes as validator performance changes. Do not treat any displayed APY as a promise. ### Withdrawal timing The app offers two exits. **Withdraw now** pays within seconds for a 0.2% fee, but only up to the Gram the pool keeps unlent, which is a small part of the pool. The queued withdrawal gives you a payout-NFT "bill" receipt, and your Gram is paid out when the current settlement cycle finalizes, up to roughly 36 hours (two TON validation rounds). Plan larger exits around that window. (See the staking and unstaking chapters for the full flow, including the rule that you must never transfer or sell the receipt NFT.) ### Secondary-market liquidity KTON is a transferable jetton, so in principle it can be swapped on a DEX. In practice the secondary market for KTON against Gram is thin, with low liquidity, so an emergency swap can incur significant slippage and is not a recommended exit. The intended way out is the protocol itself: Withdraw now for amounts the pool can cover, otherwise the \~36-hour queued withdrawal. ## In short KTON's contracts were independently audited by TonBit with zero Critical or Major findings (the public pool runs the reviewed code without the five later fixes), they are open source under MIT and verifiable on-chain, and every admin role is a 3-of-4 multisig. None of that removes the inherent risks of staking, smart-contract risk, validator and slashing risk, variable yield, withdrawal timing, and limited secondary liquidity, so stake with those clearly in mind. ## Related guides on kton.io * [Is liquid staking safe?](https://kton.io/learn/is-liquid-staking-safe) Next: **Protocol Architecture**