BTT vs BTTOLD: 5 Important Record Checks

BTTOLD and the newer BTT are different token records on TRON. The legacy TRC10 asset uses token ID 1002000; the newer TRC20 asset uses a full contract address. A familiar BitTorrent name is not enough to reconcile an old balance with a newer token amount.

This guide is for readers comparing records from different periods. We checked both public Mainnet token pages and two anonymous node metadata responses on 1 November 2026, then tested an invented amount example locally. We did not swap tokens, connect a wallet, inspect a private exchange account or verify that any migration service is currently available.

Which BTT record are you reading?

The BitTorrent Team’s redenomination plan is dated 6 December 2021 in its body; its support-page update is 2 January 2025. It identifies BTTOLD as TRC10 ID 1002000 and the newer TRON BTT as TRC20 contract TAFjULxiVgT4qWk6UZwjqwZXTSaGaqnVp4. The historical plan uses 1 old unit to 1,000 new units.

The official naming FAQ from 27 December 2021 also explains the old/new names and ratio. These are historical references, not announcements of a new event today. An old article’s statement about a service does not establish its present operation, eligibility or support policy.

BTT and BTTOLD: two identifier types

Open the legacy token-ID page and the newer token-contract page separately. The table records what those pages displayed in our session. We did not use their prices, holder counts or supply values to estimate anyone’s holdings or investment outcome.

For the general difference between a numeric token ID and a contract, see the TRC10 and TRC20 identifier comparison. Here the additional task is matching two specific BitTorrent-era records while preserving different precision scales.

Independent read-only checks of the two precision fields

We also made two anonymous Mainnet node queries on 1 November 2026. The GetAssetIssueById reference describes a token-ID lookup. Our request to https://api.trongrid.io/wallet/getassetissuebyid with {"value":"1002000"} returned HTTP 200, the requested ID and precision: 6.

For BTT, we used https://api.trongrid.io/wallet/triggerconstantcontract with the checked contract as both owner_address and contract_address, function_selector: "decimals()", an empty parameter string and visible: true. The successful response contained one 32-byte constant_result word ending in hexadecimal 12. Interpreted as an unsigned ABI integer, that word equals decimal 18, agreeing with the page.

The constant-call reference explains that this is simulation without broadcasting. We used only the no-input metadata read, not a swap or a state-changing operation. Supplying a public address in the query does not imply that we control it. We obtained no private key and signed nothing.

Keep HTTP success separate from application success. Our retained responses had the expected fields and no Error entry. An empty result, an error object or a missing precision field would not justify a default of six or eighteen. This recheck establishes the precision used in our arithmetic; it does not audit the contract, establish a conversion service or certify an asset price.

Five steps for comparing BTT and BTTOLD records

1. Preserve the two originals. Keep the date and source of each record. Do not rename an old row or replace its identifier to make it resemble a current display.
2. Classify the network and asset. Use the full token ID or contract together with its network. A symbol on an exchange statement needs that service’s own asset and network context before it can be matched.
3. Label the number’s representation. Write raw integer, formatted token quantity or value estimate beside every number. A formatted amount must not be divided by the precision a second time.
4. Apply only a stated comparison model. If illustrating the historical ratio, first express the old amount in old token units. Then calculate the hypothetical new-unit amount. Keep this separate from evidence that an actual conversion occurred.
5. Write a limited result. Distinguish identified records, an arithmetic correspondence and a completed service operation. Missing account history or a service’s current policy remains unresolved.

Success is a note that another reader can follow. It may conclude that both records were identified but that there is no evidence connecting them through a completed conversion. That is a useful answer; an assumed receipt would make the comparison less reliable.

Decimals and redenomination solve different problems

Decimals converts a raw integer into units of one particular token. Redenomination compares units under a separately stated old/new relationship. These operations have different inputs and meanings. Replacing one exponent with another is not a substitute for applying the historical ratio.

For a synthetic legacy raw integer of 12500000, the observed six-decimal scale gives 12.5 BTTOLD units. Under the historical 1,000-to-one new-unit model, the corresponding hypothetical quantity is 12500 BTT units. An eighteen-decimal BTT representation of that quantity would be 12500000000000000000000 raw units.

These invented values were checked locally with exact decimal arithmetic. They are not an account balance, a transfer or a quote. No chain transaction was created. The calculation establishes only the relationship among its stated inputs.

The last row is deliberately wrong for the stated legacy input. A tiny result can be produced simply by borrowing the BTT precision. That result is not evidence of a loss, a deduction or an uncredited conversion. Recheck the input’s representation before interpreting its magnitude.

The raw-integer and token-decimal worksheet covers the general formatting method. Its USDT example uses that asset’s scale; it must not be copied automatically into either BitTorrent record.

Why the two raw integers can differ by much more than 1,000

In the invented paired example, the new raw integer is 10^15 times the old raw integer. That factor combines two separate changes: the historical token-unit ratio of 10^3 and the precision-scale difference of 10^(18 − 6), or 10^12. Multiplying the factors gives 10^15. It would be misleading to describe that raw-integer factor as the token redenomination ratio.

This is why the worksheet first converts the legacy integer into a human-readable quantity. The intermediate 12.5 BTTOLD units make the next operation explicit. The corresponding 12,500 BTT units can then be encoded at the newer precision if an integer comparison is actually needed. The extra twelve decimal places are a representation change; they do not independently create spendable token units.

For a reverse arithmetic check, divide the hypothetical 12,500 BTT units by 1,000 to return to 12.5 BTTOLD units. This checks the internal consistency of the example. It does not establish that a reverse conversion service exists or that a real user can exchange in either direction. The historical relationship and a currently executable operation are separate claims.

Optional local BTT arithmetic check

If your input is explicitly the legacy raw integer, the Python function below reproduces the worksheet without any network access. Its six and eighteen exponents apply only to the two checked records, and 1,000 is the historical comparison assumption. Do not use this function for a formatted balance, an unidentified export or a different asset.

from decimal import Decimal, localcontext
import re

def old_raw_to_expected_new(raw):
    if type(raw) is not str or not re.fullmatch(r'[0-9]+', raw):
        raise ValueError('Use an unsigned raw integer string')
    with localcontext() as ctx:
        ctx.prec = max(80, len(raw) + 25)
        old_units = Decimal(raw) / Decimal(10) ** 6
        new_units = old_units * 1000
        new_raw = new_units * Decimal(10) ** 18
        return tuple(format(v, 'f') for v in (old_units, new_units, new_raw))

Calling old_raw_to_expected_new("12500000") returns the three decimal strings 12.5, 12500.0 and 12500000000000000000000.0. The trailing decimal zero does not change the number. We also checked the raw zero input and six rejected inputs: a decimal-point string, a negative string, a comma-formatted string, an integer object, a Boolean and a missing value. All eight assertions passed locally.

Those rejections are intentional. A value copied from a display such as “12,500,000” needs its representation checked before processing. The function refuses it rather than silently deleting punctuation. An integer object is also rejected so the caller must deliberately preserve the source as a raw string. This does not authenticate that source; a syntactically valid string can still belong to the wrong token.

Keep this calculation beside the two original records. Its output is an expected quantity under a historical assumption, not evidence of a live conversion. No wallet library, transaction endpoint or service credentials are used. Readers who only need the identification comparison can use the table and copyable note without running code.

A two-record evidence sheet

Use two columns in a note, one for each source. Keep the observed values intact even when they disagree. A third column can hold the reason for the disagreement or the specific evidence still needed.

Record A date / source URL:
Record A network / standard / complete identifier:
Record A amount / raw or formatted / decimals:
Record B date / source URL:
Record B network / standard / complete identifier:
Record B amount / raw or formatted / decimals:
Comparison assumption and its dated source:
Evidence of an actual conversion, if available:
Conclusion / unresolved condition:

For example, an invented exchange export might say only “BTT 12.5.” Without the export date, asset definition, network and representation, it does not contain enough information to choose either side of our calculation. Write “asset context missing” rather than assigning the BTT contract from a search result.

A second invented case might contain the legacy numeric ID and an already formatted amount. That supports an old-record identification. It does not establish a new-token receipt. The expected arithmetic amount and a documented service credit belong on separate lines.

Record mismatches need different conclusions

The labels differ but the complete contract matches. Preserve both labels and consult the service’s own dated asset description. A naming difference needs interpretation; it is not automatically a different asset. Our test did not establish current exchange naming or support.

The network differs. Keep the records separate. This worksheet checked the two TRON Mainnet pages, not a bridge or native balance on BitTorrent Chain. A common project name cannot remove the network boundary.

The source is still loading. Treat the missing field as unavailable. Do not fill an empty decimal field with six or eighteen merely because this dated example displayed those values.

A page links an issuer address. Keep it in an issuer field. The issuer account, token ID, token contract and intended recipient have different roles. A legitimate token identifier is not a personal receiving instruction.

A website asks for a wallet signature. The public identification and local arithmetic in this guide need none. This article does not test or endorse a swap interface. A present-day operational decision needs separate, current service evidence.

What the amount comparison cannot prove

A numerical correspondence does not show that a swap happened, that an exchange accepted a deposit, or that a bridge delivered an asset. Those are operation-specific questions requiring their own records. Nor does multiplying units imply that purchasing power or a market price remained unchanged at two real observation times.

The SUN and SUNOLD contract comparison is a separate legacy-token case. Its identifiers and conversion assumptions must stay with that asset. A useful method can transfer between reading tasks; the token addresses, ratios and current operational facts cannot.

Frequently asked questions

Is BTTOLD the same token record as newer BTT on TRON?

No. The checked legacy page uses a TRC10 token ID, while the newer TRON page uses a TRC20 contract. Preserve both complete identifiers.

Is the 1,000 ratio a decimal setting?

No. It is the historical old/new unit relationship in the project references. Decimals separately converts a particular token’s raw integer into token units.

Does multiplying an old amount prove a conversion completed?

No. It produces an expected amount under the stated model. A completed operation needs its own transaction or service evidence.

Can the symbol alone identify an old statement?

Not reliably. Keep the statement’s date, network, token definition and number representation before choosing a record.

Was a current BTT swap service tested here?

No. Testing covered public token-page fields, two anonymous metadata queries and local invented arithmetic, with no wallet connection or financial operation.

Independent Tronscan News review with AI-assisted drafting and source checks on 1 November 2026. The two original illustrations and exact-arithmetic worksheet were created for this article. Historical references are dated explicitly. No current swap availability, private balance, valuation, bridge outcome or service eligibility is claimed. Find more reading guides through the Tronscan News homepage and corrections through About & Standards.