TON smart contract security best practices

This comprehensive guide covers the most critical security vulnerabilities found in TON smart contracts, based on real-world audits and security research. Understanding these pitfalls is essential for developing secure smart contracts on TON Blockchain.

Critical

Many of these vulnerabilities can lead to complete loss of funds. Always conduct thorough security audits before deploying contracts to mainnet.

Critical

Missing impure modifier

Severity: 🔴 Critical

The absence of the impure modifier allows the compiler to skip function calls if the return value is unused, potentially bypassing critical security checks.

Vulnerable code:

() authorize(sender) inline {
    throw_unless(187, equal_slice_bits(sender, addr1) | equal_slice_bits(sender, addr2));
}

Secure implementation:

() authorize(sender) impure inline {
    throw_unless(187, equal_slice_bits(sender, addr1) | equal_slice_bits(sender, addr2));
}

Best practice

Always add the impure modifier to functions that perform state changes or critical validations.

Incorrect use of modifying/non-modifying methods

Severity: 🔴 Critical

Using . instead of ~ for modifying methods means the original data structure remains unchanged, leading to logic errors.

Vulnerable code:

(_, slice old_balance_slice, int found?) = accounts.udict_delete_get?(256, sender);

Secure implementation:

(_, int found?) = accounts~udict_delete_get?(256, sender);
if(found?) {
    ;; accounts dictionary has been modified
}

Key difference

Non-modifying (.): Returns modified copy, original unchanged
Modifying (~): Modifies the original variable in place

Signed/unsigned integer vulnerabilities

Severity: 🔴 Critical

Improper handling of signed integers can allow attackers to exploit overflow/underflow conditions.

Vulnerable code:

(cell,()) transfer_voting_power(cell votes, slice from, slice to, int amount) impure {
    int from_votes = get_voting_power(votes, from);
    int to_votes = get_voting_power(votes, to);
    
    from_votes -= amount;  // Can become negative!
    to_votes += amount;
    
    votes~set_voting_power(from, from_votes);
    votes~set_voting_power(to, to_votes);
    return (votes,());
}

Secure implementation:

(cell,()) transfer_voting_power(cell votes, slice from, slice to, int amount) impure {
    int from_votes = get_voting_power(votes, from);
    int to_votes = get_voting_power(votes, to);
    
    throw_unless(998, from_votes >= amount);  // Validate sufficient balance
    
    from_votes -= amount;
    to_votes += amount;
    
    votes~set_voting_power(from, from_votes);
    votes~set_voting_power(to, to_votes);
    return (votes,());
}

Insecure random number generation

Severity: 🔴 Critical

Using predictable sources like logical time for randomness allows attackers to predict and exploit outcomes.

Vulnerable code:

int seed = cur_lt();  // Predictable!
int seed_size = min(in_msg_body.slice_bits(), 128);
if(in_msg_body.slice_bits() > 0) {
    seed += in_msg_body~load_uint(seed_size);
}
set_seed(seed);

if(rand(10000) == 7777) {
    ;; Attacker can predict this
}

warning

Never rely on on-chain randomness for critical operations. Validators can influence or predict random values. Consider using commit-reveal schemes or external oracles for true randomness.

Missing bounced message handling

Severity: 🔴 Critical

Failing to handle bounced messages can lead to inconsistent state and fund loss.

Secure implementation:

() recv_internal(int msg_value, cell in_msg_full, slice in_msg_body) impure {
    slice in_msg_full_slice = in_msg_full.begin_parse();
    int msg_flags = in_msg_full_slice~load_msg_flags();
    
    if (msg_flags & 1) {  // Check bounced flag
        on_bounce(in_msg_body);
        return ();
    }
    
    ;; Normal message processing
}

() on_bounce(slice in_msg_body) impure {
    in_msg_body~skip_bits(32);  // Skip 0xFFFFFFFF
    int op = in_msg_body~load_op();
    
    ;; Handle specific bounced operations
    if (op == op::transfer) {
        ;; Restore user balance
    }
}

Sending private data on-chain

Severity: 🔴 Critical

All data stored on blockchain is public and permanent, including transaction history.

Vulnerable approach:

;; DON'T: Storing password hash or private data
cell private_data = begin_cell()
    .store_slice("secret_password_hash")
    .store_uint(user_private_key, 256)
    .end_cell();

warning

Everything on blockchain is public. Transaction history, contract storage, and message contents are permanently visible to everyone.

Account destruction race conditions

Severity: 🔴 Critical

Destroying accounts without proper checks can lead to fund loss in race conditions.

Vulnerable code:

() recv_internal(msg_value, in_msg_full, in_msg_body) {
    if (in_msg_body.slice_empty?()) {
        return ();  ;; Dangerous: empty message handling
    }
    
    ;; Process and destroy account
    send_raw_message(msg, 128 + 32);  ;; Destroys account
}

Secure approach:

() recv_internal(msg_value, in_msg_full, in_msg_body) {
    ;; Proper validation before any destruction
    throw_unless(error::unauthorized, authorized_sender?(sender));
    
    ;; Ensure no pending operations
    throw_unless(error::pending_operations, safe_to_destroy?());
    
    ;; Then proceed with destruction if really needed
}

Missing replay protection

Severity: 🔴 Critical

External messages without replay protection can be re-executed multiple times.

Secure implementation:

() recv_external(slice in_msg) impure {
    slice ds = get_data().begin_parse();
    int stored_seqno = ds~load_uint(32);
    int msg_seqno = in_msg~load_uint(32);
    
    throw_unless(33, msg_seqno == stored_seqno);  ;; Prevent replay
    
    accept_message();
    
    ;; Update sequence number
    set_data(begin_cell().store_uint(stored_seqno + 1, 32)...);
}

Improper message bounce handling

Severity: 🔴 Critical

Using non-bounceable messages when bounceable is needed can cause fund loss.

Vulnerable code:

var msg = begin_cell()
    .store_uint(0x10, 6)  ;; Non-bounceable
    .store_slice(to_address)
    .store_coins(amount)
    .end_cell();

Secure implementation:

var msg = begin_cell()
    .store_uint(0x18, 6)  ;; Bounceable message
    .store_slice(to_address)
    .store_coins(amount)
    .store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1)
    .store_uint(op::excesses(), 32)
    .end_cell();

Executing third-party code

Severity: 🔴 Critical

Executing untrusted code can compromise contract security.

Prevention:

;; Validate all external code before execution
throw_unless(error::untrusted_code, verify_code_signature(code));
throw_unless(error::invalid_code, validate_code_safety(code));

Medium

Race conditions in message flows

Severity: 🟡 Medium

Message cascades can span multiple blocks, allowing attackers to initiate parallel flows.

Best practice:

() handle_transfer(slice sender, int amount) impure {
    int current_balance = get_balance(sender);
    throw_unless(error::insufficient_funds, current_balance >= amount);
    
    ;; Don't assume balance will remain the same in subsequent messages
}

Improper gas management

Severity: 🟡 Medium

Failing to return excess gas or miscalculating gas requirements.

Secure gas handling:

int ton_balance_before_msg = my_ton_balance - msg_value;
int storage_fee = const::min_tons_for_storage - min(ton_balance_before_msg, const::min_tons_for_storage);
msg_value -= storage_fee + const::gas_consumption;

if (msg_value > 0) {
    var msg = begin_cell()
        .store_uint(0x18, 6)  // Bounceable message
        .store_slice(response_address)
        .store_coins(msg_value)
        .store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1)
        .store_uint(op::excesses(), 32)
        .store_uint(query_id, 64)
        .end_cell();
    send_raw_message(msg, 1);
}

Fake jetton token validation

Severity: 🟡 Medium

Accepting transfers without validating the sender's jetton wallet address.

Secure validation:

() handle_jetton_transfer(slice sender_address, int jetton_amount, slice from_user) impure {
    ;; Calculate expected jetton wallet address
    slice expected_wallet = calculate_jetton_wallet_address(from_user, jetton_master_address);
    
    throw_unless(error::invalid_jetton_wallet, equal_slice_bits(sender_address, expected_wallet));
    
    ;; Process valid transfer
}

Missing function return value checks

Severity: 🟡 Medium

Ignoring function return values can lead to logic errors and unexpected behavior.

Vulnerable code:

dictinfos~udict_delete?(32, index);  ;; Ignoring success flag

Secure implementation:

int success = dictinfos~udict_delete?(32, index);
throw_unless(error::fail_to_delete_dict, success);

Name collision vulnerabilities

Severity: 🟡 Medium

Function or variable names can collide with built-in functions or reserved keywords.

Best practice:

;; Use descriptive, unique names
int user_balance = 0;  ;; Instead of just 'balance'
() validate_user_signature()  ;; Instead of just 'validate()'

Incorrect data type handling

Severity: 🟡 Medium

Reading or writing incorrect data types can corrupt contract state.

Vulnerable code:

;; Writing uint but reading int
storage~store_uint(value, 32);
int read_value = storage~load_int(32);  ;; Type mismatch

Secure implementation:

;; Consistent type usage
storage~store_uint(value, 32);
int read_value = storage~load_uint(32);

Contract code updates

Severity: 🟡 Medium

Contracts can be updated if not properly protected, changing their behavior unexpectedly.

Secure implementation:

() update_code(cell new_code) impure {
    throw_unless(error::unauthorized, authorized_admin?(sender()));
    throw_unless(error::invalid_code, validate_code?(new_code));
    
    set_code(new_code);
}

TON address representation issues

Severity: 🟡 Medium

TON addresses have multiple representations that must be handled correctly.

Address formats:

;; Raw: 0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
;; Bounceable: EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
;; Non-bounceable: UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

;; Always validate workchain
force_chain(to_address);

Carry-value pattern violations

Severity: 🟡 Medium

Not following carry-value pattern can lead to inconsistent state across contracts.

Correct pattern:

;; Sender contract subtracts and sends
sender_balance -= amount;
send_transfer_message(destination, amount);

;; Receiver contract receives and adds
receiver_balance += received_amount;

Transaction phases misunderstanding

Severity: 🟡 Medium

Not understanding TON's 5-phase transaction model can lead to unexpected behavior.

Transaction phases

Storage phase: Account state loading
Credit phase: Value crediting
Compute phase: Contract execution
Action phase: Message sending
Bounce phase: Error handling

Cross-contract data access

Severity: 🟡 Medium

Attempting to directly access other contract data instead of using message-based communication.

Correct approach:

;; Don't try to read other contract's data directly
;; Use message-based communication instead
send_get_data_request(target_contract, query_id);

Predefined method IDs

Severity: 🟡 Medium

Not properly understanding predefined method IDs can cause conflicts.

Reserved method IDs:

() recv_internal(int msg_value, cell in_msg_cell, slice in_msg) impure {  ;; method_id = 0
}

() recv_external(slice in_msg) impure {  ;; method_id = -1
}

Security checklist

Before deploying your smart contract, ensure you've addressed:

Critical security checks

Important considerations

Testing and auditing

Security first

Use Blueprint testing framework for comprehensive testing
Conduct formal security audits before mainnet deployment
Test edge cases and failure scenarios
Verify bounced message handling

References

Was this article useful?

Critical​

Missing impure modifier​

Vulnerable code:​

Secure implementation:​

Incorrect use of modifying/non-modifying methods​

Vulnerable code:​

Secure implementation:​

Signed/unsigned integer vulnerabilities​

Vulnerable code:​

Secure implementation:​

Insecure random number generation​

Vulnerable code:​

Missing bounced message handling​

Secure implementation:​

Sending private data on-chain​

Vulnerable approach:​

Account destruction race conditions​

Vulnerable code:​

Secure approach:​

Missing replay protection​

Secure implementation:​

Improper message bounce handling​

Vulnerable code:​

Secure implementation:​

Executing third-party code​

Prevention:​

Medium​

Race conditions in message flows​

Best practice:​

Improper gas management​

Secure gas handling:​

Fake jetton token validation​

Secure validation:​

Missing function return value checks​

Vulnerable code:​

Secure implementation:​

Name collision vulnerabilities​

Best practice:​

Incorrect data type handling​

Vulnerable code:​

Secure implementation:​

Contract code updates​

Secure implementation:​

TON address representation issues​

Address formats:​

Carry-value pattern violations​

Correct pattern:​

Transaction phases misunderstanding​

Cross-contract data access​

Correct approach:​

Predefined method IDs​

Reserved method IDs:​

Security checklist​

Critical security checks​

Important considerations​

Testing and auditing​

See also​

References​

Critical

Missing impure modifier

Vulnerable code:

Secure implementation:

Incorrect use of modifying/non-modifying methods

Vulnerable code:

Secure implementation:

Signed/unsigned integer vulnerabilities

Vulnerable code:

Secure implementation:

Insecure random number generation

Vulnerable code:

Missing bounced message handling

Secure implementation:

Sending private data on-chain

Vulnerable approach:

Account destruction race conditions

Vulnerable code:

Secure approach:

Missing replay protection

Secure implementation:

Improper message bounce handling

Vulnerable code:

Secure implementation:

Executing third-party code

Prevention:

Medium

Race conditions in message flows

Best practice:

Improper gas management

Secure gas handling:

Fake jetton token validation

Secure validation:

Missing function return value checks

Vulnerable code:

Secure implementation:

Name collision vulnerabilities

Best practice:

Incorrect data type handling

Vulnerable code:

Secure implementation:

Contract code updates

Secure implementation:

TON address representation issues

Address formats:

Carry-value pattern violations

Correct pattern:

Transaction phases misunderstanding

Cross-contract data access

Correct approach:

Predefined method IDs

Reserved method IDs:

Security checklist

Critical security checks

Important considerations

Testing and auditing

See also

References