New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
The 2018 BTCJP note about adding a custom token ends with an unusually useful detail: its author created two experimental tokens with the same symbol on a test network. That small observation exposes a larger problem in wallet interfaces. A name or ticker is convenient for display, but it does not uniquely identify an asset. Adding a token entry changes what the wallet presents; it is not itself a transfer, a purchase or a guarantee about the contract. This new guide builds an evidence checklist around that distinction. Its sample amounts and identifiers are hypothetical, and it does not recommend either historical token mentioned in the source.
Start with the network and contract together
For an ordinary contract-based token, an address needs a network context. An address string copied from one environment is not a complete statement about another environment. The same-looking value can refer to different code or no relevant contract at all on a different chain. Record the network identity and contract address as a pair before discussing the token's display name. A wallet label such as my test network is not sufficient evidence by itself, because labels can be entered locally and changed without altering the underlying network being queried.
The archived BTCJP experiment illustrates this at the interface level. The author names a historical test network and supplies two separate contract addresses for similarly named test tokens. The lesson is not that those old addresses should be imported into a present wallet. It is that the complete identification record matters. In a new laboratory notebook, retain the intended environment, the contract being inspected and the method used to establish each. This gives another reader enough information to distinguish two experiments even when both use the same friendly ticker.
Treat metadata as a description, not an identity certificate
ERC-20 specifies a standard token interface and includes optional metadata methods such as name, symbol and decimals. Those fields help software present values to people, but they do not reserve a globally unique brand. A contract can expose a familiar symbol without being the contract a reader intended to inspect. The practical implication is simple: search results and display labels are leads to investigate, not a replacement for the network-and-contract identification step. A polished icon can make an entry recognisable without establishing its origin or any associated promise.
Imagine two hypothetical classroom projects both called LAB. One is a student's demonstration contract; the other is a separate exercise built a week later. A wallet might show both as LAB, perhaps with similar default icons. The correct record distinguishes them by their environments and addresses. It should also identify where the display metadata came from: the contract, a token list or a local setting. These sources can disagree. Making that disagreement visible is more useful than assuming the most attractive label has settled the question of which asset the user is viewing.
Understand the number before interpreting the balance
Token interfaces commonly work with integer amounts, while the wallet formats those amounts using a decimal scale. In a hypothetical example, a raw amount of 123450 with a scale of three decimal places displays as 123.45 units. With a scale of two, the same raw integer would display as 1234.50. The arithmetic does not change the underlying stored amount. It changes the human presentation. This is why an unexpectedly large or small display should prompt a check of the amount and scale rather than an immediate conclusion about a transfer or reward.
Keep raw and formatted values together in a laboratory record. If a wallet lets a user enter a scale manually, record that setting too. An interface can be internally consistent while showing a value that does not match the intended contract's metadata. The notebook should explain which scale was used and why. This approach is especially useful when comparing screenshots across different software versions. A changed display does not necessarily establish a changed holding; it may reflect a changed formatting rule, data source or local token configuration.
Distinguish importing an entry from changing a holding
A display operation and a state-changing operation should be described separately. Adding an entry can tell the wallet which contract to query and how to label a result. It does not, merely by being added, create an on-chain transfer to the account. Conversely, removing a display entry is not the same action as transferring away the underlying token. A useful interface explanation names the action that occurred instead of using the broad phrase got the token for both a visual change and a network event.
For a hypothetical test, observe an account through an independent read path before and after adding a display entry. Record whether any transaction was created and whether the queried contract state changed. The expected difference is in the interface's list, not a newly created payment event. This exercise teaches an important debugging habit: compare the layer that changed with the layer being claimed to have changed. It avoids interpreting every wallet refresh, hidden entry or newly discovered contract as evidence that value has just moved on the network.
Keep permissions separate from visibility
Seeing a token, connecting an application and approving a token allowance are different operations. The ERC-20 interface includes allowance-related functions, but a display entry does not explain what permissions an application may request later. A laboratory walkthrough should identify the boundary at which a read becomes a request for authority. An application might present the actions in one flow, so the reader needs to inspect what each step actually asks the wallet to do rather than assume that every step is another harmless update to a token list.
A clear test record separates read-only observations from signed transactions or other authorisations. It names the account, network, relevant contract and intended action without publishing signing secrets. If a permission request appears while the stated task is only to inspect a balance, the discrepancy deserves explanation before the test continues. This is an evidence discipline rather than a claim that every unfamiliar request has one cause. The objective is to keep the operation being authorised aligned with the operation the experiment was meant to examine.
Use an identification record that survives the screenshot
A screenshot preserves an interface, but a durable research note needs more context. Record the environment, contract, observation time, raw amount, display scale and the source of the metadata. Explain whether the result came from a wallet, a node query or an explorer, and identify any mismatch between those views. A later reader can then investigate a changed display without relying entirely on the original author remembering which similarly named entry was selected. The record becomes reproducible rather than merely recognisable.
The BTCJP custom-token note is therefore more than a sequence of old menu labels. Its two similarly named experimental tokens provide a compact lesson in asset identification. Begin with network and contract, treat metadata as description, check the decimal scale and distinguish visibility from state changes and permissions. These distinctions remain useful even as wallet menus evolve. They explain why adding a token can make an existing holding visible while proving very little, on its own, about the token's origin, value or the external claims someone attaches to its name.
Technical references
From the recovered archive
- ETHEREUM: Add custom token on Metamask · captured 22 April 2021