MSTR Cat

Crypto Law/Level VI · Market conduct/6.3 The honest launch/Lesson 3

On-chain transparency: show people where to look

Why public blockchain data only becomes disclosure when a launch tells people which addresses, contracts and code to check, and what that data can and cannot prove.

Education, not legal, tax or investment advice. Crypto law differs between countries and states and changes often. Check the current rules where you live with a qualified lawyer or tax adviser before you act.

The lean path

The cheapest, lowest-tax, simplest and most private route the law allows, best first. Each step names the rule it rests on and the condition that keeps it lawful.

  1. Free and most effective: publish the token’s contract or mint address in one stable official place and repeat it identically everywhere, since EIP-20 makes names optional and copies are easy. Catch: explain any address change publicly.
  2. Verify source code free on Etherscan, or with solana-verify for Solana programs. Catch: verification proves only that the published code is the deployed code, not that it is safe, and upgradeable code can be replaced later.
  3. Publish a map labelling the pool, locks, vesting contracts, treasury and team wallets by role rather than personal name, which is lawful privacy from the public. Catch: published wallets are permanent, linked transfers are traceable, and tax reporting continues.
  4. Prove each claim with a transaction hash, for a lock, revoked authority or vesting deployment; the SEC’s 2026 interpretation encourages disclosing promised work when completed, and sharing a hash costs nothing. Catch: keep the map updated as addresses change.

MaterialsA block explorer for the token’s chain, opened on the token contract or mintThe project’s list of official addresses, if it publishes oneThe EIP-20 token standard and Solana’s verified-builds documentationLesson 6.3.1, on what honest disclosure requires

Wonder

  1. If everything is on the chain anyway, why does a launch need to publish anything?
  2. How can a buyer tell the real token from a copy with the same name?
  3. Does verified source code mean the contract is safe?

Explore

  1. Every transfer on a public blockchain is visible, but raw visibility is not disclosure. A buyer facing thousands of addresses cannot tell which belong to the team, which is the pool, which is a lock contract and which is an exchange. Transparency starts when the creator publishes the map: the token contract or mint address, pool addresses, lock contracts, treasury and team wallets, vesting contracts and any program or proxy addresses. The SEC’s proposed Regulation Crypto Assets would require issuers using its exemptions to describe ‘methods to verify’ the token’s transaction history (proposed Rule 103(b)(7)), a proposal that treats exactly this map as part of disclosure.
  2. The address, not the name, is the token’s identity. The ERC-20 standard (EIP-20, created in November 2015) makes name(), symbol() and decimals() optional, and nothing stops anyone deploying a second token with the same name and ticker. Copycat tokens and fake ‘official’ accounts exploit this (lesson 4.2.4). Publishing the contract address in one stable official place, and repeating it the same way everywhere, is the simplest protection a launch can give. A buyer who checks the address rather than the ticker avoids the commonest trap; a creator who changes addresses without explanation teaches buyers to stop checking.
  3. Code can be made checkable too. Etherscan’s documentation explains that verifying a contract publishes its source code on the explorer, where anyone can confirm it matches the bytecode deployed on-chain. Solana’s verified builds do the same by comparing hashes of the deployed program with a reproducible build of the public repository, using the solana-verify tool. Verification proves only that the published code is the deployed code. It says nothing about whether the code is safe or fair, and an upgradeable program or proxy can be replaced later (lesson 6.3.2). Proposed Rule 103(b)(6) would ask issuers to give the address where source code is available, if they have published it.
  4. Supply and holdings are the next things people read. EIP-20 requires every token to report totalSupply(), and Solana’s token tools report a mint’s total supply. Holder lists are easy to misread: the largest ‘holders’ are often the pool, a lock contract, a vesting contract or an exchange. Labelling those addresses publicly, and explaining which balances are insiders’ (lesson 6.3.4), turns a frightening chart into an accurate one. Tokens that reach an address but are not burned in the technical sense still count in total supply, which is one reason burn claims need care (lesson 6.3.5).
  5. In the US, publishing data does not replace accurate statements; the claims an issuer makes are what securities, commodities and consumer-protection law test (lessons 5.1.7 and 6.3.1). But on-chain evidence is how a creator shows that statements are true. The SEC’s 2026 interpretation (Release No. 33-11412) encourages issuers that promise work to disclose publicly when it is completed, and a transaction hash for a lock, a revoked authority or a vesting deployment is the most direct proof. In the EU, MiCA Article 6(1)(h) requires a white paper to include information on the underlying technology.
  6. Transparency has costs worth naming. A published wallet links a person or business to every past and future transaction from it, and large wallets can attract copy-trading and unwanted attention. A launch can label addresses by role rather than by personal name, but whatever it publishes is permanent, and transfers between labelled and unlabelled wallets can usually be traced. A practical check: open the explorer, start from the published contract address, and try to identify the pool, each lock, each insider wallet and any upgrade authority using only the launch’s own map; anything that cannot be found from the map is a gap in its disclosure.

Key facts

  • The EIP-20 token standard, created on 19 November 2015, makes name(), symbol() and decimals() optional but requires totalSupply().
  • Etherscan contract verification publishes source code and lets anyone confirm that it matches the bytecode deployed on-chain.
  • Solana verified builds compare hashes of the deployed program with a reproducible build of the public source repository.
  • Proposed Rule 103(b)(7) of Regulation Crypto Assets would require issuers to describe methods to verify the token’s transaction history.
  • Proposed Rule 103(b)(6) would require issuers to give the website address of the source code, to the extent they have made it publicly available.
  • MiCA Article 6(1)(h) requires a crypto-asset white paper to contain information on the underlying technology.

Exercise nine, six, three, one

9CollectList up to 9 addresses or pieces of code a buyer would need to check a token you know or are planning (some lists are shorter), such as the token contract, the pool, a lock, a vesting contract or an upgrade authority.
6ClusterSort them into 6 categories: token identity, liquidity, insider holdings, locks and vesting, code and upgrade control, and items with no public address yet.
3DistillReduce the 6 categories to 3 groups: items already published and labelled, items visible on-chain but not explained, and items a buyer cannot find at all.
1CrystallizeWrite 1 sentence describing the single address or proof whose publication would most improve what a buyer can verify about this token.

Fact check

Dates, figures and claims checked against the published sources listed below.

Open in the interactive academy →

PT ES ZH JA KO RU DE FR MS