> 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 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 | All findings fixed | 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 were addressed before the protocol's live operation. ### 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: separation of powers KTON does not place all control in a single key. The pool defines distinct role slots, and the powers are deliberately separated so that no single role can both move funds and rewrite the rules unchecked. 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) behind a 2-day timelock | Constrained only by the timelock; no instant action | | **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 | The point of this split is that 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 gated behind a delay rather than able to act instantly. Powers that are concentrated in one address in simpler designs are spread across several here. ### Timelocks Two of the most powerful operations are protected by mandatory delays, which give users and observers time to see a sensitive change coming before it takes effect: | Action | Timelock | | --------------------------------------------------- | ---------------------------------------- | | 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, and only after the 2-day quarantine. Re-setting the sudoer restarts that clock. There is no instant, single-step path to replace the protocol's code. One safety property worth knowing: **withdrawals are never halted.** Even when the pool is otherwise paused, the withdraw path stays open so that the protocol can always refund burned KTON. The one exception is a self-protective measure: if at round finalization the pool genuinely cannot cover queued withdrawals plus its minimum storage reserve, it self-halts and pays nobody until it is topped up, rather than paying some users at the expense of others. ## 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. Because the sudoer can upgrade the code (behind the 2-day timelock), you are also trusting that future upgrades 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 Unstaking is not instant. When you burn KTON you receive a payout-NFT "bill" receipt, and your Gram is paid out when the current settlement cycle finalizes, roughly 36 hours (two TON validation rounds). The optimistic instant-withdrawal path is economically disabled on the live pool, so the real exit is the queued \~36-hour withdrawal. Plan your liquidity needs 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 and most reliable way out is the protocol's own \~36-hour queued withdrawal. ## In short KTON has been independently audited by TonBit with zero Critical or Major findings and all five issues fixed, its contracts are open source under MIT and verifiable on-chain, and its control model separates powers across distinct roles with timelocks on the most sensitive actions. 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. Next: **Protocol Architecture** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.kton.io/getting-started/06-security-and-audits.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.