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.
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
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:
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:
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:
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
Last updated