Skip to content

fix: default bare 64-hex account hashes to Basechain (0:) in detect_address - #90

Open
rylaix wants to merge 1 commit into
toncenter:mainfrom
rylaix:patch-1
Open

fix: default bare 64-hex account hashes to Basechain (0:) in detect_address#90
rylaix wants to merge 1 commit into
toncenter:mainfrom
rylaix:patch-1

Conversation

@rylaix

@rylaix rylaix commented Aug 14, 2026

Copy link
Copy Markdown

Summary

Fixes an issue where detect_address unconditionally defaults bare 64-character hexadecimal account hashes to Masterchain (-1:) instead of Basechain (0:).

Problem

When a caller supplies a 64-character raw hex string (256-bit account ID) without a workchain prefix, detect_address prepended "-1:". Since the vast majority of user accounts, Jettons, and smart contracts reside on Basechain (0:), this caused downstream API callers and SDK consumers to resolve data from Masterchain for an intended Basechain account without any warning.

Solution

  • Updated detect_address in pytonlib/utils/address.py to default bare hexadecimal hashes to "0:".
  • Preserves explicit "-1:<hash>" and "0:<hash>" address formats.
  • Preserves all friendly address resolution paths.

Reproduction / Test

from pytonlib.utils.address import detect_address

def test_bare_256_bit_hash_defaults_to_basechain():
    account_id = "0123456789abcdef" * 4
    resolved = detect_address(account_id)
    assert resolved["raw_form"] == "0:" + account_id

When a bare 64-character hexadecimal account hash is passed to `detect_address`, it unconditionally prepended `-1:` (Masterchain) instead of the standard `0:` (Basechain) where the majority of accounts and contracts reside.

This PR changes the default for bare 64-hex hashes to `0:`, while preserving explicit `-1:<hash>` and `0:<hash>` behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant