Whitepaper

Contents

• 1. What Shiba Classic is
  • 1.1 What is true and checkable today
  • 1.2 What is running
  • 1.3 What does not exist yet
  • 1.4 What comes next
  • 1.5 Who runs it, and on what authority
  • 1.6 How to read this document
  • 1.7 The shortest possible check
• 2. Where This Came From
  • 2.1 The launch, minute by minute
  • 2.2 The guarantees came from the launch, not from the takeover
  • 2.3 Then it was left behind
  • 2.4 What a takeover can change — and what it cannot
  • 2.5 What this chapter does not document
  • 2.6 Verify the timeline yourself
• 3. The Token, Verifiable
  • 3.1 The contract
  • 3.2 Ownership has been renounced
  • 3.3 What renouncing does not cover
  • 3.4 There is no transfer tax
  • 3.5 Liquidity is burned
  • 3.6 Supply, burned and circulating
  • 3.7 Who holds SHIBC — and why that is not in conflict with §3.2
  • 3.8 The networks, and how they reach consensus
  • 3.9 Verify all of it yourself
• 4. What runs today
  • 4.1 The short answer
  • 4.2 The games
  • 4.3 The site
  • 4.4 Telegram
  • 4.5 The cross-chain work — and which networks it is actually on
  • 4.6 What is not measured — and that is a finding, not a gap in this chapter
  • 4.7 What is being done about it
  • 4.8 What the token is used for
  • 4.9 What would change this chapter
  • 4.10 Verify this yourself
• 5. How value returns to the project
  • 5.1 The starting position, measured
  • 5.2 Why there is nothing to distribute — and why that is structural
  • 5.3 The intended mechanism
  • 5.4 What the shares would be for
  • 5.5 Custodian, yes. Override, no.
  • 5.6 The one revenue experiment that has run
  • 5.7 The candidate sources, rated
  • 5.8 What has to be true for this to work
  • 5.9 What would change this chapter
  • 5.10 Verify this yourself
• 6. Governance
  • 6.1 What exists
  • 6.2 Where voting power comes from
  • 6.3 The one vote that has taken place
  • 6.4 What that vote does and does not prove
  • 6.5 The decision was never carried out
  • 6.6 Custodian, yes. Override, no.
  • 6.7 How decisions are actually made today
  • 6.8 What has to be true for this to work
  • 6.9 Verify this yourself
• 7. What is planned
  • 7.1 Why there are no dates in this chapter
  • 7.2 The order
  • 7.3 Step 1 and 2 — the cheap things that are not done
  • 7.4 Step 3 — distributing access
  • 7.5 Step 4 — governance that is used
  • 7.6 Step 5 — the bridge on mainnet, and exactly what stands in the way
  • 7.7 Step 6 — the products that would sit on top
  • 7.8 What is planned outside the bridge
  • 7.9 What is explicitly not planned
  • 7.10 How to hold this chapter to account
• 8. Risks and Limits
  • 8.1 One person maintains this project
  • 8.2 Holdings are concentrated
  • 8.3 One residual privilege the renounce did not cover
  • 8.4 Liquidity is burned — and it is thin
  • 8.5 Trading venues are limited, and one of them is exposed to EU regulation
  • 8.6 Most of the value-flow design does not exist yet
  • 8.7 The audit, and what it does and does not cover
  • 8.8 What holding SHIBC does not give you
  • 8.9 How these are being dealt with
  • 8.10 Conflicts of interest
  • 8.11 Status of this document
• 9. Addresses and Evidence
  • 9.1 How to read this register
  • 9.2 Contract addresses on Ethereum mainnet
  • 9.3 The transactions the claims rest on
  • 9.4 The burn address is not where the burning is decided
  • 9.5 Governance addresses, and their measured state
  • 9.6 Official channels
  • 9.7 Third-party sources
  • 9.8 Verifying rather than trusting
  • 9.9 What this register does not contain
  • 9.10 Version and change history

1. What Shiba Classic is

Evidence rating: this chapter has none of its own. It is a summary, and every claim in it carries the rating of the chapter it comes from — ✅, 🟡 or 🔴, marked where it appears. Nothing is stated here that is not stated with its evidence somewhere below.

Shiba Classic ($SHIBC) is an ERC-20 token on Ethereum whose contract nobody controls, kept going by people who did not launch it. The original team left; the community picked the project up and has maintained it since — today through one active maintainer (§1.5). That is the whole of it in one sentence, and the rest of this document is the evidence for each part of it.

It was written under one rule: every number and every mechanism carries a source, or it is removed. Where something does not exist, this document says so and marks it red.

This is version 1.0, its text finalised on 31 August 2026. Every change made to it from here on is recorded in §9.10, with what changed and when.

1.1 What is true and checkable today

Those six are the load-bearing facts, and every one of them can be verified against the chain in under a minute without trusting this document. §3.9 gives the commands.

⚠️ The most important word in that table is "today". Three of those six are permanent — renounced ownership, burned LP, burned supply cannot be undone. The others are current state.

1.2 What is running

Two browser games, playable without a wallet or an account. A website in six languages, driven by a content system. A Telegram channel of a few hundred people, and a Mini App entry point into the games.

That is the complete list. Chapter 4 measures each item — file sizes, HTTP responses, the date the games were last built — and states the two things a reader would otherwise have to discover: that the games have not been updated since March 2025, and that the project collects no usage data at all, so it does not know how much any of it is used. 🟡

1.3 What does not exist yet

This is the section the previous document did not have, and it is the reason this one can be trusted where it makes positive claims.

• There is no treasury. The DAO's address holds nothing and has never received anything from the project. 🔴 §5.1
• There is no mechanism that routes value back. The design is described in Chapter 5 and is entirely in the future tense. The first revenue source is now named — game-currency purchases in a partner game — but it is not in operation: measured in August 2026, the programs that would carry it are on a test network and not on mainnet. 🔴 §5.3
• The bridge to Solana is not on mainnet. It works on test networks. Two things have to be true before it moves: an encoding correction that is currently half applied, and control over the escrow shared rather than held by one person. 🔴 §7.6
• The marketplace, the wallet application and the NFT platform are not deployed. 🔴 §7.7
• Governance exists but is not in use. One proposal has ever been opened, in December 2024, and the voting token's supply has been zero since January 2025 — so at this moment nobody holds a vote. 🔴 §6.3

None of that is presented as nearly done. Chapter 7 gives an order rather than dates, and names for each item the condition that has to be met first — because a project maintained by one person cannot forecast delivery honestly, and a broken date costs more than a kept one earns.

1.4 What comes next

The order is set even though the dates are not. Chapter 7 lists six steps and, for each one, the condition that has to be met before it can happen.

Four of them are gated on nothing outside the project: making what already exists countable, a treasury that can receive, distributing keys and access, and governance that is actually used. The largest step — the bridge on mainnet — waits on two named conditions rather than on inactivity (§7.6), and neither of them costs money either.

Everything in the order is cheap and undone. That distinction is the honest shape of this roadmap, and §7.2 carries the full order with what each item waits on. §7.10 states how to hold the chapter to account.

1.5 Who runs it, and on what authority

Nobody owns Shiba Classic, because there are no owners to have. Ownership of the contract was given up on launch day and is not recoverable by anyone — not by the original developer, not by the people running it now, not by a vote. What remains is an executing role: someone who builds, publishes and keeps the lights on on behalf of the community, not above it.

Today that role is filled by one person, who works unpaid and pays for the servers personally. That is stated plainly because it is simultaneously the project's largest risk and the reason to take its claims at face value:

• As a signal it is the opposite of the usual problem. There is no allocation to disclose, no vesting to believe and no insider position that was handed to anyone, because none was ever created (§5.2).
• As a risk it is real and measured — §8.1 lists every credential that sits with one individual and what happens to the project if that person stops.

What is being done about it is the first item in the plan that needs nobody's permission: distributing keys and access so that the project survives any one person leaving, then building a group from the community that can decide and act (§7.4, §8.9).

⚠️ One distinction that recurs and matters: a multi-signature wallet is the right answer to who holds the keys and the wrong answer to who may change the rules. Custodian, yes. Override, no. The shares of any future distribution are meant to be set by vote, not by a signature — §5.5.

1.6 How to read this document

Every chapter carries an evidence rating in its heading — ✅ exists, 🟡 partly exists, 🔴 does not exist yet. That marking is the point of the rewrite, not decoration: the failure of the previous version was that a reader could not tell a product from a plan.

Why there was a previous version to fail. This paper replaces one that described a different project — an ecosystem of products that mostly did not exist, including a revenue figure for a product that never operated. Rather than edit that text, it was rewritten from scratch under the rule at the top of this chapter. That history is stated here rather than hidden, because it is the reason the evidence ratings exist at all.

Each fact lives in exactly one place. This summary points; it does not restate. Where an exact figure changes over time — the burned share, the pool depth, the holder table — the number lives in its own chapter with the date it was measured, and this chapter deliberately says "around" and sends you there. Two copies of the same number are two chances to be wrong, and divergent figures between a project's own documents are themselves a warning sign.

Where something is unknown, it is written as unknown. The identities behind the largest addresses, for instance, are not known to this project, and §8.2 says so instead of guessing.

⚠️ This is a project description. It is not investment advice, not legal advice, and it has not been reviewed or approved by any authority (§8.11). It says what exists, what does not, and how to check both. It does not recommend anything.

1.7 The shortest possible check

If you read nothing else, run these two. The first asks the contract who owns it — the answer is the zero address, which means nobody:

curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0x8da5cb5b"},"latest"]}'

The second asks the same chain what this project's treasury holds — the answer is nothing, and that is §1.3 rather than an error:

curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0x1862820429B8E8F0F4166a548c2C5C443f665498","latest"]}'

Those two answers are this project in miniature: almost everything built on top is still ahead — and the foundation it would be built on is already permanent and cannot be taken away by anyone, including the people running it. Both halves are in this document, and neither one is hidden behind the other.

Chapter 9 is the register: the addresses, the transactions the claims rest on, and the project's official channels — with a note on what it deliberately does not contain.

Chapter 1 of the Shiba Classic whitepaper (rewrite, issue #118). Written last, because a summary of chapters that do not exist yet is how the previous version went wrong. Every figure referenced here is measured and dated in the chapter it belongs to.

2. Where This Came From

Evidence rating: ✅ the on-chain history is fully documented — the human history is not. Everything in §2.1 is reconstructed from Ethereum transactions and can be re-checked block by block. §2.4 marks explicitly what cannot be evidenced that way.

Shiba Classic is a community takeover: launched by someone else, left behind, and continued by people who were not there at the start. That sentence is easy to write and easy to doubt, so this chapter shows the part of it that is on the chain.

2.1 The launch, minute by minute

Everything below happened on 13 November 2024, within sixteen minutes, all from the deploying address 0x1314e07ec05cf76D7ed88426fc433d710462c62f.

Transaction hashes for every row are in Chapter 9, §9.3.

Four things follow from this table, and each one matters more than the narrative around it.

Forty per cent of the supply was burned before trading opened. That is the origin of the figure in §3.6, and it happened eight minutes into the contract's existence — not as a later community campaign. Chapter 9 §9.4 shows the burned balance decomposing exactly into this one transaction plus what has been burned since.

The sequence is the conservative one. Fees were set to zero before ownership was given up, not after. Had it been the other way round, the fees would have been frozen at whatever they happened to be. They were frozen at zero deliberately.

The window in which anyone could change anything was about sixteen minutes. From the first block to the renounce: 79 blocks. There was never a prolonged period during which an owner sat on the ability to raise fees or halt trading.

The last row is the proof for §3.3. removeSellLimit executed after owner() was already the null address — which is only possible because it checks against deployerWallet rather than the owner. This is not an inference from reading the source; it is a successful transaction on the chain.

2.2 The guarantees came from the launch, not from the takeover

This is where accounts of community takeovers usually blur, so it is stated plainly here:

The renounced ownership, the burned liquidity and the 40 % supply burn were not achievements of the community. All three were done by the original deployer on launch day, within sixteen minutes, before any takeover existed. The community inherited them; it did not create them.

That is not a diminishment — it is the reason a takeover was possible at all. A project whose owner keys still work can be abandoned and looted afterwards. This one could only be abandoned. The guarantees in Chapter 3 are real regardless of who put them there, and claiming credit for them would be the kind of sentence this rewrite exists to remove.

2.3 Then it was left behind

The deploying address stayed active for a while after launch, and its last recorded activity is 24 February 2025 (23 transactions in total). Between those dates it did two things worth naming, both of which are in §3.3:

• 13 November 2024, 18:50 — removeSellLimit.
• 6 January 2025, 16:33 — clearStuckEth, withdrawing 0.7944 ETH from the token contract to the deployer address. Successful.

Neither was a breach of anything: both are functions the contract grants that address, and the ETH in question had accumulated inside the contract from the original fee mechanism. They are listed because a document that describes those functions as "residual privileges" and does not mention that one of them was actually exercised would be leaving out the interesting half.

What is not on the chain is why the original team stopped, or when exactly the project was considered abandoned. Those are human events, and this document does not invent dates for them.

2.4 What a takeover can change — and what it cannot

A community takeover has a narrow set of levers, and being clear about them is more useful than enthusiasm:

So a takeover is not a relaunch. Nothing about the token itself was altered, and nothing about it can be altered. What changed is that somebody is looking after the surrounding project again.

Who that is, and at what cost, is set out in Chapter 8 §8.1 rather than here — because it belongs next to the risk it creates, not next to the part that sounds good.

2.5 What this chapter does not document

Deliberately absent, because none of it can be evidenced from the chain and the earlier version of this document asserted several such things as fact:

• A date for the takeover. No transaction marks it.
• The size of the community, then or now. Holder counts are not people counts, and follower counts are not either.
• Claims about volume and liquidity around the takeover. The previous document stated that "trading volume decreased by 60 %" and "liquidity increased by 40 % within the first month of the CTO". Those sentences were most likely describing something real — the market did recover for a period after the takeover — but no source for either number exists, so they are not reproduced here. ⚠️ One of them is also wrong in kind, not just unsourced: liquidity cannot have been restored by the community in the sense implied, because the pool's LP tokens were burned on launch day (§2.1). What can grow is the pool's reserves, which anyone can add to; what cannot happen is the community "restoring" a liquidity lock that already existed. And in any case the claim has since been overtaken. Market capitalisation is lower today than it was around the takeover (Chapter 8 §8.4 carries the current figure with its date). A document that anchors itself to a favourable market moment ages badly by design — which is the second reason these numbers are gone rather than updated.
• A multi-signature wallet. The previous document described one as implemented. No such arrangement is documented here, and the treasury design in Chapter 5 deliberately goes the other way — a distribution contract that no multisig can override.

2.6 Verify the timeline yourself

Every row in §2.1 is a transaction. The two that carry the weight:

# Liquidity burn — LP tokens to 0x…dEaD
https://etherscan.io/tx/0x64e74fd2dee3651f7e4576fc83a5e84eaa79f153cabcb234e2f81716320cfee6

# renounceOwnership
https://etherscan.io/tx/0x4a79e8e93d492fa8988ce26ad484d29cbc97561fe0424582cf5c755134ee6978

Or read the ownership history straight from the logs — two events, creation and renounce:

curl -s "https://eth.blockscout.com/api?module=logs&action=getLogs\
&fromBlock=21180459&toBlock=21230459\
&address=0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8\
&topic0=0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0"

Chapter 2 of the Shiba Classic whitepaper (rewrite, issue #118). Timeline reconstructed from Ethereum mainnet logs and transactions; state values re-verified 23 August 2026.

3. The Token, Verifiable

Evidence rating: ✅ exists — every figure in this chapter is on-chain and reproducible. All values measured 23 August 2026 against two independent Ethereum RPC endpoints (ethereum-rpc.publicnode.com, eth.drpc.org). Holder figures change with every trade; the commands to re-measure them yourself are at the end of the chapter.

Most questions about a memecoin are really one question: can anyone still do something to me with this contract? This chapter answers it with call results rather than assurances. Where the answer is "no", the call output says so. Where something is still possible, it is stated here rather than left for a reader to discover.

3.1 The contract

The supply is fixed. The contract has no mint function callable after deployment — the entire supply was created once, in the constructor. Nothing can add to it.

3.2 Ownership has been renounced

owner() → 0x0000000000000000000000000000000000000000

Confirmed against both RPC endpoints. Ownership sits at the null address, which nobody holds a key for. This is not a promise about future behaviour; it is a state that cannot be undone.

That matters because of what it switches off. The contract does contain levers — a reader should expect that, most do — and these are the ones guarded by onlyOwner:

The point is not that fees are currently zero. The point is that nobody can raise them again — not the maintainer, not the DAO, not a future buyer of the project. The lever exists and the handle has been removed.

3.3 What renouncing does not cover

Renouncing ownership is often presented as if it disabled everything. Here it does not, and the difference is worth stating plainly.

The contract holds a second privileged address, deployerWallet, set in the constructor to whoever deployed the contract. It is independent of owner(), so the renounce left it untouched. Three functions are guarded by it:

function removeSellLimit() external {
    require(_msgSender() == deployerWallet);
    sellLimit = false;
}

function clearStuckEth() external {
    require(_msgSender() == deployerWallet);
    require(address(this).balance > 0, "Token: no ETH to clear");
    payable(msg.sender).transfer(address(this).balance);
}

function clearStuckTokens(address tokenAddress, uint256 toKeep) external {
    require(_msgSender() == deployerWallet, "Only deployer can clear tokens");
    ...
}

Who holds it: 0x1314e07ec05cf76D7ed88426fc433d710462c62f — the address that deployed the contract, and therefore an address from before the community takeover. It is not the maintainer's address, and the project does not control it.

This is not theoretical — both have been used. The chain records it (Chapter 2, §2.1/§2.3):

Neither was a breach: both are functions the contract grants that address, and the ETH had accumulated inside the contract from the original fee mechanism. They are named here because describing a privilege while omitting that it was exercised would be the more misleading choice.

What it can reach today — measured, not estimated:

These functions operate exclusively on assets sitting in the token contract itself (address(this).balance, balanceOf(address(this))). They cannot touch a holder's balance, they cannot mint, and they cannot change fees or stop trading. With the contract holding nothing, they currently move nothing. The contract does accept ETH (receive() external payable {}), so future stray funds sent to it would be withdrawable by that address.

We state this because it is two minutes of work for any reader to find in the verified source. A whitepaper that omits it does not look cleaner — it looks unread.

ℹ️ The December 2024 Hashlock audit touched this: finding [L-01] records the then-team stating that "only the function removeSellLimit can be executed by deployerWallet". The source shows three, and the auditor's own QA items Q-01 and Q-02 address the other two. The statement in the report was narrower than the code; the list above is the complete one. See §8.7.

3.4 There is no transfer tax

BuyFee()  → 0
SellFee() → 0

Both confirmed against both endpoints. The deployed source declares initial values of 5 % each; they now stand at zero, and because SetFees is onlyOwner (§3.2), zero is where they stay.

tradingOpen() → true

Trading is open and cannot be closed, for the same reason.

3.5 Liquidity is burned

The Uniswap V2 pair for SHIBC/ETH is 0x236A92092e2aF35B54CBCB3CD5DAaAc7F1c7813b. LP tokens are the claim on the pooled liquidity: whoever holds them can withdraw it. So the question is simply who holds them.

Every LP token that exists is at an address that cannot spend it. The 1,000 wei difference is not a leftover held by someone — it is the fixed amount Uniswap V2 permanently burns to the zero address when a pool is first created, by protocol design.

Measured against both RPC endpoints, using the pair's own totalSupply() as the denominator. That distinction matters: a holder list from a block explorer can be paginated or incomplete, so "100 % of the listed holders" would prove nothing. The contract's own supply figure cannot be incomplete.

A "rug pull" in its most common form is the withdrawal of pooled liquidity. That specific action is available to nobody here.

3.6 Supply, burned and circulating

The burn figure is a live balance read from the contract, not a historical claim. It is not a single event either: 40.0000 % was burned by the deployer on launch day and 0.2318 % has been burned since, in ten batches. Chapter 9 §9.4 shows the decomposition and how to reproduce it.

3.7 Who holds SHIBC — and why that is not in conflict with §3.2

This is the part most projects leave out, and leaving it out is what makes readers assume the worst. Renounced ownership and a large holder position are two different things, and they do not contradict each other — but printed in separate chapters they read like a tension, so they are printed here together.

Ownership control (§3.2) is about what the contract permits. A holder position is about how much of the supply one address happens to own. A large holder cannot change fees, cannot mint, cannot stop trading and cannot withdraw liquidity — none of those depend on holdings. What a large holder can do is sell, and that is true of every holder of every token.

So here is the complete top ten, measured 23 August 2026. Two columns, because "3.78 %" is meaningless without saying of what: the middle column is the share of the circulating supply, the right one the share of total supply including the burned 40.23 %.

The eight "unknown" entries together hold 21.93 % of circulating supply.

The largest position is not a person. Entry 1 is the liquidity pool itself — tokens matched against ETH so the market can trade. Its transfer count runs into the tens of thousands, which is what a pool looks like.

About the eight marked "unknown": each was checked individually. None is a contract (is_contract = false for all eight), none carries a public tag, none has a name. Seven have transaction counts in the low double digits; the eighth, 0xd685…BBE6, has never sent anything — every transfer it has ever seen was incoming. Set against a pool with orders of magnitude more activity, none of these is exchange or bot activity.

What the chain does not say is who they are. Eight people or one person with eight addresses — that is not something we can determine, and we will not claim otherwise. The addresses are printed above; anyone can check them.

The maintainer's position

Entry 4 — 3.78 % of circulating supply, 2.26 % of total supply — belongs to the person who maintains this project, publicly identifiable as @LegendaryKlack on X and @KlackKlick on Telegram (§9.6).

There was no allocation, no team wallet and no vesting schedule to disclose, because Shiba Classic is a community takeover: the original team left, and everyone involved since — including the maintainer — bought their tokens on the open market like everyone else. There is nothing to unlock because nothing was ever set aside.

Naming this address is a deliberate, permanent choice. From publication onward it can be watched, and every movement will be read as a signal. So the reason for any future movement is stated here in advance rather than explained afterwards: if tokens from this address are ever sold, it will be to fund the project — an exchange listing, or the treasury described in Chapter 5 — and it will be announced as such. An announced mechanism is not the same thing as an unexplained transaction, and this paragraph exists so that the difference is on the record.

3.8 The networks, and how they reach consensus

Named here because the rest of the paper leaves it implicit, and a reader is entitled to know which machines the token depends on.

Neither is a proof-of-work chain, and neither was one while this token existed. Ethereum stopped being one in September 2022, more than two years before this contract was deployed (§2.1). Solana never was one.

Two things follow, and both matter more than the label does:

• The contract itself consumes nothing. ERC-20 code runs only when somebody sends a transaction, and the fee for that transaction is paid to the network, not to this project. There is no mining, no minting and no process that runs on its own — §3.2 and §3.6 say why there cannot be.
• This project runs no validator on either chain. It therefore has no energy consumption of its own beyond the transactions it sends, and no influence whatsoever on either network's consensus.

⚠️ What this paper will not print is a figure for energy used per transaction. Every such number is an estimate produced by somebody else, it moves with the size of the validator set, and it falls under the rule in §9.9. What can be said without an estimate is the shape: on a proof-of-stake chain the network's energy use is that of a set of ordinary servers, and it does not grow with the value being secured — which is exactly the property proof of work does not have.

3.9 Verify all of it yourself

Nothing above requires trusting this document. Each command returns the value quoted.

# Ownership renounced?  -> 0x0…0
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0x8da5cb5b"},"latest"]}'

# Buy fee / sell fee?   -> 0 / 0
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0xdd854652"},"latest"]}'
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0xcf9522fd"},"latest"]}'

# Trading open?         -> 1 (true)
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0xffb54a99"},"latest"]}'

# Amount burned?        -> balance of 0x…dEaD
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0x70a08231000000000000000000000000000000000000000000000000000000000000dEaD"},"latest"]}'

# Liquidity burned? Ask the PAIR contract, not a holder list.
#   (a) LP totalSupply    (b) LP held at 0x…dEaD    (c) LP at 0x0 = MINIMUM_LIQUIDITY
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x236A92092e2aF35B54CBCB3CD5DAaAc7F1c7813b","data":"0x18160ddd"},"latest"]}'
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x236A92092e2aF35B54CBCB3CD5DAaAc7F1c7813b","data":"0x70a08231000000000000000000000000000000000000000000000000000000000000dEaD"},"latest"]}'
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x236A92092e2aF35B54CBCB3CD5DAaAc7F1c7813b","data":"0x70a082310000000000000000000000000000000000000000000000000000000000000000"},"latest"]}'

# Current holder list   -> the table in §3.7
curl -s https://eth.blockscout.com/api/v2/tokens/0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8/holders

⚠️ Note the shape of the liquidity check: it asks the pair contract for its own supply and two balances, rather than reading a holder list and observing that one entry makes up 100 % of it. A holder list can be paginated or incomplete, in which case that 100 % would be an artefact of the list rather than a fact about the pool.

Results are hexadecimal; divide by 10¹⁸ for token amounts. Reading the source is worthwhile too — it is verified, so the code shown by any block explorer is the code that runs.

Holder figures are a snapshot taken 23 August 2026 and change with every trade. The contract-level facts — renounced ownership, zero fees, burned liquidity, fixed supply — do not change, which is precisely why they are stated separately from the table.

Chapter 3 of the Shiba Classic whitepaper (rewrite, issue #118). Contract-level values verified against two independent RPC endpoints; holder attribution per issue #1.

4. What runs today

Evidence rating: 🟡 partly exists. Everything in this chapter was measured on 24 August 2026 against the live systems themselves — HTTP status codes on the public site, file sizes in the asset bucket, contract bytecode on Ethereum and Solana. Nothing here is taken from the project's own marketing pages, and nothing that could not be reached from outside is described as running.

The predecessor of this chapter listed an ecosystem of products under a single umbrella name. Most of those products did not exist, which is the reason this document is being rewritten (§1, issue #118). So this chapter takes the opposite approach: it starts from what a stranger can open in a browser right now, and works outwards to the things that exist only as code.

The list is shorter than the old one. It is also true, and every line of it can be checked in under a minute — §4.10 says how.

4.1 The short answer

Two things follow from that table, and both are said here rather than left to be inferred.

What is live is small but real. Two Unity WebGL builds — one of about 60 MB, one of about 23 MB — are served from public storage and open without a login, a content-managed site answers in six languages, and a Telegram Mini App entry point responds. That is working software, not a mock-up.

What is not live is not hidden. The cross-chain work has a measurable deployment — on test networks, with a test copy of the token. That distinction is the whole content of §4.5, and it is the kind of thing a reader would otherwise discover on their own and reasonably treat as a concealment.

4.2 The games

Two browser games run today. Both are Unity WebGL builds; both are reachable without a wallet, without an account and without holding SHIBC.

All four files answer 200 from public storage, the loader script is served from the site itself, and both play routes answer 200. There is no login wall in front of either — no wallet, no account, no token balance is checked before the game loads.

⚠️ The honest date next to that: the current build files were last written on 16 March 2025. The games run; they have not been updated in seventeen months.

The same two games are what the Telegram Mini App launches — one entry point, both titles, no separate build (§4.4).

4.3 The site

The public site is not a static page. It is served by a Next.js frontend against a Directus CMS, which means the text can be corrected without a code release — relevant to a paper that promises to keep its numbers current.

The translations are real translations rather than an untranslated English page behind a language switch. All six were checked, which covers every script the site has to handle — including the right-to-left one:

ℹ️ One page in that list is a leftover: an "ecosystem" page still describes the umbrella-name construct this rewrite removes. It is being taken down together with its redirects rather than silently deleted, because six language versions of a URL that returns 404 is a worse outcome than one outdated page. Tracked as issue #138.

4.4 Telegram

This is where the project's community actually is, and it is the honest answer to "where does discussion happen": not on a forum, not in the DAO interface, but in a Telegram channel with a few hundred people in it.

⚠️ What could not be confirmed: the Mini App is designed to be opened through a Telegram bot link (t.me/<bot>/<name>), and no such link appears anywhere in the project's code or on the website. The launcher route works when opened directly; whether a bot is configured to point at it is not something this document can verify from the outside, so it is not claimed.

4.5 The cross-chain work — and which networks it is actually on

This is the part most likely to be misread, so it is stated with the measurements attached.

What exists as code, in this project's repository:

• shibc-oft — a Solana on-chain program implementing LayerZero's Omnichain Fungible Token standard. Built for this project.
• An EVM-side adapter that locks SHIBC and forwards messages to the LayerZero endpoint, plus the accompanying SDK.
• Two reference web applications — a wallet/swap interface with a bridge route inside it, and an NFT marketplace.

What is deployed, measured directly against both chains today:

And the detail that decides how to read all of it: both test adapters are attached to a Sepolia copy of the token, not to the real one. Calling token() on either returns 0x8DF2d725cAeD5994459d2b75739f37ebd4886bA6, which on Sepolia reports the name "Shiba Classic", the symbol "SHIBC" and the same nominal supply as the real contract — but it is a separate test deployment. The SHIBC that exists on Ethereum mainnet (§3.1) has no bridge adapter of any kind.

In plain terms: nobody can bridge SHIBC today, and this paper does not claim otherwise.

What can be shown is that the test deployment has been used, not merely deployed. The first adapter holds 600 test-SHIBC locked, and the Solana mint has a non-zero supply — tokens went in on one side and were minted on the other. This paper does not attempt to reconcile the two figures into a count of completed transfers; it states what each side reports.

So the accurate summary is: the machinery has been exercised on test networks, and never deployed to a real one.

⚠️ Why it has not happened is a deliberate condition, not an oversight. A component that would hold locked tokens does not go live until control over it is shared rather than held by one person — the multi-signature arrangement described in §7.4. That is the condition, and it has not been met. Chapter 7 carries this as a plan with that condition attached; Chapter 8 carries the risk that the condition stays unmet.

ℹ️ One naming correction belongs here, because the project's own materials have used four product names — Bridge, Marketplace, Vault, Games — and that count is one too high. "Vault" and "Bridge" are not two products: the bridge is a route inside the wallet application, and the image name that suggests otherwise is a historical artefact. This paper names three: Games, Marketplace, and the wallet application that contains the bridge.

4.6 What is not measured — and that is a finding, not a gap in this chapter

A reader will want usage numbers: how many people play, how many visit. This document cannot supply them, and the reason is worth printing.

The project collects no usage data of its own. That is a deliberate outcome in one respect — no visitor tracking of its own, no account required to play — and an unmanaged one in another: the project genuinely does not know how many people use it.

⚠️ One qualification, because a reader with the browser's developer tools open will find it in ten seconds: every page still loads the Google AdSense script (pagead2.googlesyndication.com, publisher ca-pub-9470797162292710) and carries the matching publisher meta tag. So it would be wrong to say that nothing about visitors reaches anyone — Google receives a request on every page view. What it does not do is give this project a usage figure it could publish.

But no advertisement is shown. Measured across three pages: the loader script appears once, the ad slot that would display an advertisement appears zero times. Advertising on this site is switched off, and §5.6 explains why — it is the one genuinely instructive story this project has about earning money, and it is not the story anyone would guess from finding the script.

That script is the only third-party script the pages load; the only other external asset is a set of country flags served from a GitHub Pages host. That a switched-off ad network still loads its script on every request is a defect rather than a design, and is tracked for removal (issue #287).

⚠️ The zero in the first row means something narrower than it looks, and reading it as "nobody plays" would be wrong. The score table is empty because the submission path has never fired: the Mini App listens for a score event and the server-side chain behind it — Telegram sign-in verification, then the write to the database — is built, but neither Unity build emits the event at the end of a run. Measured: the listener is in the web code, and the string it listens for appears zero times in either game's loader or framework file. The chain is finished at every link but the first. Adding it is a change inside the game project, tracked as issue #33; the leaderboard that depends on it is #34.

So the correct statement is: the games are played or not played, and nobody has measured which. The first honest number this project can publish about its own usage will come after #33, and it will start at zero on the day it starts counting.

4.7 What is being done about it

In the order it can actually happen, which is not the order of ambition:

1. Make the score path fire. One event call in each Unity build, then a rebuild. Everything downstream of it already exists and is deployed. This is the smallest change in the list and the one that turns "we have games" into "we can show that they are used".
2. Remove the last umbrella-name page and redirect its six URLs. Small, overdue, and it stops the site contradicting this document (#138).
3. Publish this paper on the site itself, in the CMS rather than as a PDF, so that the numbers in it have exactly one place to be corrected (#117).
4. Bring the bridge to mainnet only behind shared control — the multi-signature arrangement described in §7.4. Not before, and this paper commits to describing it as a test deployment until the day that is met.

The expensive parts of one and three are behind, not ahead. The games are built, the score API is deployed, the CMS is running and the renderer that this paper needs was completed while it was being written. What remains on those two lines is small work that has not been prioritised, and saying so is more useful than a schedule.

Item four is different in kind, and is not treated as imminent. It belongs to Chapter 7 with its conditions, not to a roadmap with a date on it.

4.8 What the token is used for

The word "utility" appears nowhere else in this document, because most of what it usually stands for does not exist here yet. The question behind it is fair, though, and a reader should not have to assemble the answer out of three chapters. So, in full:

The honest summary of that table is one line: beyond being tradable, the token does one thing today, and that thing is governance. It is real — the contracts are deployed, and voting power is something a holder creates and undoes rather than receives (§6.2) — and it is used by almost nobody (§6.3).

⚠️ The two games are deliberately not on the list. Both run without a wallet, without an account and without holding SHIBC (§4.2). A reader who assumed the games are where the token is used would be assuming something this project has never claimed; building that link is one of the things Chapter 7 is for.

Why the section is this thin. A heading called "utility" that listed planned products as though they were uses would be the easiest place in this whole document to mislead somebody. The table above marks what is deployed and what is not, and the red rows are the work — not the argument.

4.9 What would change this chapter

Stated as observable events, so a reader can check whether this chapter has gone stale rather than trusting that it has not:

• A build file in the games bucket with a newer date than 16 March 2025 — the games are being worked on again.
• A non-zero score count — the submission path fires; §4.6 becomes a real number.
• Bytecode at a mainnet address holding SHIBC — the bridge left the test networks. Until then, any claim that SHIBC bridges to Solana is false regardless of who makes it.
• A published page count above twelve, or a language count above six — the site grew.

4.10 Verify this yourself

None of this requires trusting the document. The games are the easiest: open https://shibaclassic.io/en/gaming/play/doge-dash/ and play. For the file-level check, the build artefacts are public objects and answer to a plain request:

curl -sI "https://storage.googleapis.com/shiba-classic-prod-game-files/doge-dash/doge-dash.wasm.gz" \
  | grep -Ei 'content-length|last-modified'

The site's language coverage takes one loop — all six must answer 200:

for l in en de fr vi cn ar; do
  printf "%s %s\n" "$l" "$(curl -s -o /dev/null -w '%{http_code}' "https://shibaclassic.io/$l/about-us/")"
done

The claim that matters most in this chapter is the negative one — that the bridge is not on mainnet. It is a single call per address, and an empty result (0x) means there is no contract there at all:

curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x001759f461955Ad9fAf308183B56750F15B9702c","latest"]}'

The same address on Sepolia returns several kilobytes of bytecode — that is the difference between a test deployment and a live one:

curl -s -X POST https://ethereum-sepolia-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x001759f461955Ad9fAf308183B56750F15B9702c","latest"]}'

And to see which token that test adapter is attached to, call token() on it (selector 0xfc0c546a). The answer is the Sepolia copy, not the token this paper is about:

curl -s -X POST https://ethereum-sepolia-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x001759f461955Ad9fAf308183B56750F15B9702c","data":"0xfc0c546a"},"latest"]}'

The Solana side works the same way. getAccountInfo against devnet returns an account for the OFT program; the identical request against mainnet returns null:

curl -s -X POST https://api.devnet.solana.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAccountInfo","params":["dK89gv955wKxC5PxxpFUFbHikhB2fS7GuksVjdQH8cR",{"encoding":"base64"}]}'

And the claim that the test deployment has actually been used is two calls — the tokens locked in the adapter, and the supply minted on the far side:

# 600 test-SHIBC locked in the Sepolia adapter (balanceOf, selector 0x70a08231)
curl -s -X POST https://ethereum-sepolia-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x8DF2d725cAeD5994459d2b75739f37ebd4886bA6","data":"0x70a08231000000000000000000000000001759f461955Ad9fAf308183B56750F15B9702c"},"latest"]}'

# non-zero supply on the Solana devnet mint
curl -s -X POST https://api.devnet.solana.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getTokenSupply","params":["wQQod1rKHfEDYaNDHgrR2Q7A85rPFfR94r2YBKz3iXA"]}'

Chapter 4 of the Shiba Classic whitepaper (rewrite, issue #118). All figures measured on 24 August 2026: HTTP status codes against the live site, object metadata from public storage, contract bytecode from Ethereum mainnet and the Sepolia testnet, account state from Solana mainnet and devnet, and row counts from the project's own content database.

5. How value returns to the project

Evidence rating: 🔴 target picture — the mechanism in this chapter does not exist. Nothing described in §5.3 is deployed, funded or in operation. What is measured, on 24 August 2026, is the starting position: the treasury is empty, there is no distribution contract, and no revenue stream is running. Those measurements are marked where they appear; everything else is stated in the future tense on purpose.

This is the chapter where the previous version of this document claimed a product had generated half a million dollars in its first quarter. That product never operated. Finding that sentence is what set the rule this rewrite follows — every number carries a source or it is removed — and this chapter is where the rule costs the most, because it is the chapter with the least to report.

So it reports the design instead, and says plainly which parts of it are built. A described mechanism with an honest label is worth more than an invented figure, and a reader can hold this version to account: §5.9 lists the events that would prove it moving.

5.1 The starting position, measured

That single incoming transfer is address spam of the kind every visible contract receives. It is listed because "the treasury has one incoming transfer" is what a block explorer will show, and a reader deserves to know it is not a funding event.

ℹ️ The last row is the one line in this chapter that cannot be proven by a request to a public endpoint — an absence of income is not a thing an explorer displays. It is stated on the maintainer's word, and the reason it is credible is the row above it: there is nowhere for income to have gone.

And the other half of the starting position, which belongs on the same page rather than three chapters away: the person maintaining this project is unpaid, and pays for the servers and the domain personally (§8.1). So the honest description of today's value flow is not "value flows slowly" — it is that value currently flows into the project from one individual, and nothing flows back out to anyone.

5.2 Why there is nothing to distribute — and why that is structural

This is not a project that spent a treasury and ran out. It never had one.

Shiba Classic is a community takeover (Chapter 2). There was no allocation, no team supply, no reserve and no fundraise — nothing was set aside for anyone at launch, and the people running the project today hold what they bought like everyone else (§3.7). A project that pre-mines 15 % for a treasury starts with a war chest; this one started with nothing and cannot retroactively create one, because the supply is fixed and the contract's ownership is renounced (§3.2).

That is a real disadvantage, and it is worth stating as one: every comparable project with a treasury can pay for audits, listings and contributors from day one. This one cannot, and that is why §5.1 reads the way it does.

It is also the reason the numbers in this document can be trusted in a way a pre-mined project's cannot. There is no allocation to disclose because there is none; there is no vesting schedule to believe because there is nothing vesting; and no granted insider position exists that could be released onto the market, because none was ever granted. The same fact produces both statements.

⚠️ That is a statement about allocation, not about concentration. Large positions do exist — §8.4 measures 21.93 % held across eight addresses this project cannot identify, and the maintainer's own holding is named in the table in §3.7. Nobody was given those positions; how each of them was acquired is not something this document can establish, and it does not claim to. The two facts are printed in the same paragraph for the same reason §3.7 prints the renounce next to the holder table: apart, they read as a contradiction.

The consequence is precise: any value that reaches this project has to be earned or given. There is no third path, and the rest of this chapter is about the first one.

5.3 The intended mechanism

The design below is the maintainer's, stated in his own framing and reproduced here without smoothing. Its own author's summary of the implementation is: "how all of this gets built is still written in the stars." That sentence is part of the honest record and is why the rating on this chapter is red.

The same design as a picture. The table above says what state each step is in; this says how the parts connect — and that the burn is the only arrow nobody has to decide on.

flowchart TD
    A["Game-currency purchases"] --> T
    B["This project's own sales"] --> T
    T["Treasury — everything arrives 1:1, nothing skimmed"] --> D["Distribution contract"]
    V["DAO vote"] -. "sets the shares" .-> D
    D --> P1["Burn"]
    D --> P2["Operations"]
    D --> P3["Rewards — set to zero"]
    D --> P4["Community"]
    P1 --> Z["Burn address — the only automatic return"]
    P4 --> Y["Products, marketing, liquidity, compensation"]

⚠️ Every box except the two on the left is a description of something that does not exist yet. The shares each pot receives, and the bands they move within, are in §5.4.

Step 1 has a name now, and it is not yet a number. The first intended source is the game currency of Threshold, a game built and operated by a partner, in which SHIBC is the currency a player uses to buy it. What makes that interesting is not the size — it is the shape: a player who wants to play has to acquire SHIBC, so the demand is a consequence of using the product rather than of believing in it.

⚠️ It is not running. The purchase would be paid in SHIBC on Solana, and SHIBC does not exist on Solana's main network — the token account that would hold it returns nothing, while the same account on the development network holds a supply. §4.5 measures the same thing from the bridge's side. Nothing can be paid where there is nothing to pay with.

ℹ️ That no revenue has reached this project is stated on the maintainer's account, in the same way as the last row of §5.1 — an absence of income is not something a block explorer displays. What is measured is the row above: the treasury is empty (§5.1), and the currency the purchase would use is not deployed. The two figures that would give the design a scale — how much is bought, and how much is collected in fees — are held by the partner and are not available here. Until they are, this is a described mechanism, not a revenue stream.

Two properties of that design are worth drawing out, because they are choices and not defaults.

"1:1" is a commitment about the entrance, not the exit. Everything that comes in goes to the treasury without a management share, a founder cut or a fee skimmed on the way. Compensation for people who work on the project is not excluded — it is one of the pots on the other side of the contract (§5.4), where it is visible and voted on rather than deducted before anyone sees the total.

Step 5 is the load-bearing one. A treasury that a key holder can redirect is a wallet with extra steps. Making the distribution rules changeable only by governance is what separates this design from "the maintainer promises to spend it well" — and it is also the step that makes step 4 mean anything.

5.4 What the shares would be for

The design now names three pots, not five. Everything that reaches the treasury is split between them by the contract:

That last one is stated here rather than left out, and it is stated next to §5.1 rather than in a separate section, because separating them misrepresents both. Printed alone, "the maintainer is unpaid" reads as a complaint. Printed alone, "there is a pot for contributor compensation" reads as self-interest. Printed together they are one thing: a project run by unpaid people has a single maintainer and a bus factor of one (§8.1), and paying contributors is the direct remedy — which is exactly why it belongs under a governance vote rather than under a signature.

Three rather than five is a deliberate reduction, and the reason is the same one that runs through this chapter: every pot fixed today is a decision the community can no longer take later. Fewer pots leave more room for the people it concerns.

A fourth pot for holder rewards is provided for and set to zero. It exists as a band with a minimum of nothing, so that a later vote can switch it on without anything being rebuilt. It is at zero on purpose: paid-out rewards attract people who leave when the payments stop, and a project with an empty treasury that pays out is spending its starting capital. Holders here are meant to benefit from products being used, not from money being handed back. The burn is the only automatic return, and it favours nobody — it acts on every holder equally.

⚠️ A burn does not increase anyone's balance, and whether a price follows from it is the market's decision, not this document's. It is described here as a mechanism and nowhere as an expected price effect.

Each share is a band, not a fixed number. Every pot has a floor and a ceiling; the DAO moves the share within them by simple majority, and moving the band itself is harder than moving the value inside it — a higher quorum and a waiting period, so that holders can see a change before it takes effect. The contract enforces three rules: the shares always sum to exactly 100 %, each share lies inside its band, and the floors must sum to less than 100 % while the ceilings sum to more. The third rule is the one that is easy to miss and the one that matters — without it, bands can be set under which the first rule has no solution.

The bands and the starting values, in full:

The starting values are what the contract is set up with, not what it is fixed at. The floors sum to 26 % and the ceilings to 170 %, which is the third rule above: there is room to move, and there is no combination inside the bands that fails to add up.

ℹ️ This is not a new invention for this project. The same ladder — a constant in the code, a limit fixed once at setup, a change that is announced and takes effect after a delay — is already used in three places in the code described in Chapter 4.

⚠️ The numbers above are starting values inside bands, not a decision taken away from anyone. What is printed here is the room the vote has, so that a holder can see before wrapping what can and cannot be changed — a band nobody has seen is not a constraint anyone can hold this project to.

What the compensation pot would pay, stated before it can be claimed.

There is a reason to write this down now rather than when it becomes relevant: a rule that the recipient sets at the moment of receiving is a rule he granted himself. So it is published in advance, and it is a share rather than a sum:

A monthly payment of 5 % of what is in the community pot at that moment, capped by an upper limit the DAO sets, claimed by the recipient rather than transferred by anyone.

Three properties follow from it being a share of the remainder. It can never overdraw — an empty pot pays nothing, so there is no dispute and no deficit. It pulls in the right direction — the payment is largest when the pot is full, so whoever is paid has an interest in filling it. And the pot is never emptied, because 5 % of a shrinking remainder is a decreasing series.

If more than one person is paid, each rate is set by the DAO separately and the sum of all rates is capped at 25 %, so that the order in which people claim cannot decide who gets how much, and so that the pot cannot be drained in a handful of months.

Nothing is paid before the handover point in §6.7. Until then only documented expenses — servers, domain, audits — are reimbursed, and there is no back-payment for time worked. That is not modesty; it removes the accusation that the handover was arranged for the money.

⚠️ Payment runs through a contract the recipient claims from, not through a transfer somebody signs. The DAO decides the amount, the contract releases it, the recipient claims it — nobody signs a transfer to themselves. Software for this exists and is in production use elsewhere; this project does not intend to build its own.

Where the treasury would hold it

The part above says what money is spent on. This says what it is held in, and that is a separate decision.

Income does not arrive only in SHIBC. Somebody paying for a software service pays in a stablecoin, because that is simple for them. What happens to it then has three answers, and the design uses all three with bands like the pots above:

⚠️ A treasury that holds only its own token is a known way to fail. Money is usually needed at the moment the token stands worst, and selling then makes it worse. The stable share is not distrust of the project; it is what keeps servers and people payable without pushing the price down.

Purchases of the project's own token, if they happen, are meant to be small, continuous and rule-based rather than large and monthly. A purchase at a predictable date is front-run, and a purchase at somebody's discretion is exactly the kind of judgement call this whole design removes. The difference is not cosmetic: at this pool's depth (§8.4), one large purchase costs several times the premium of the same amount spread out.

5.5 Custodian, yes. Override, no.

The same distinction that §6.6 makes for governance applies to the treasury, and it has to be explicit in both places, because two reasonable statements about multi-signature wallets look like a contradiction and are not:

A multisig as custodian is part of the answer. A multisig able to overrule governance is the problem it was meant to solve. Anyone assessing this project will ask "who controls the treasury" and expect a multisig; the answer is yes for custody and no for rule changes, and the two must not be collapsed into each other.

5.6 The one revenue experiment that has run

There is exactly one thing this project has tried in order to earn money, and it is more instructive than a plan would be.

The website carried Google AdSense. It was withdrawn — and not because it earned too little.

Advertising on a community-run site invites exactly the wrong kind of help. Supporters who want the project to succeed can reasonably conclude that clicking the advertisements is a way to contribute. It is not: every advertising network treats clicks that are not genuine interest as invalid traffic, and an account that accumulates them is at risk. That risk does not depend on anyone intending harm, which is what makes it a structural problem rather than a discipline problem. Withdrawing advertising was the responsible response.

⚠️ The measurable leftover: the AdSense loader script is still requested on every page and the publisher meta tag is still present, while the element that would display an advertisement appears zero times (§4.6). A switched-off ad network still calling home on every page view is a defect, not a design, and it is tracked for removal (issue #287).

The lesson is the one this whole chapter turns on. A return flow built on goodwill does not work — not because the goodwill is not real, but because a model whose revenue depends on supporters behaving in ways a platform forbids undermines itself no matter how well-intentioned everyone is. Value has to come from something a person would pay for anyway, from someone who is not already a holder. Any model in §5.7 that quietly relies on the community paying itself fails for that same reason.

If advertising returns, it returns on selected pages and to cover costs — not as a funding model.

ℹ️ Like the last row of §5.1, this section is stated on the maintainer's account rather than measured; what is measured is the leftover above.

5.7 The candidate sources, rated

⚠️ The first line carries a problem that is not technical, and the way out of it is a design decision rather than a construction. Moving revenue earned by a company into a DAO treasury is a legal and tax question before it is a smart contract: which entity contracts with customers, who receives the money, under what heading it can be passed on.

This project will not answer that question by acquiring a legal entity. It is not going to have one — the DAO is the organisation, and that is a decision rather than a gap waiting to be closed (§8.1).

The consequence is a filter on the table above, and it is worth stating plainly because it removes options:

• **A path that requires a payment from a company to this project needs a recipient that can be a party to an agreement.** This project does not intend to have one, so such paths are not the ones being pursued.
• A path where revenue arises directly at an address the project controls needs no counterparty at all — nothing is transferred between two parties, so there is nothing to contract about. Fees are of that kind.

That is the difference between designing around the constraint and hoping it resolves itself. ⚠️ It does not make the question disappear — it moves it. What replaces "how does the money get across" is "who may change where it lands", and that is §5.5 and §6.6 rather than a tax matter. An arrangement with no counterparty also has no contract to enforce, which is precisely why the control over the destination has to be structural.

ℹ️ Note what is not in the table: no mechanism that mints new tokens, no staking rewards paid from supply, no "treasury allocation". None of those are possible here — the supply is fixed and ownership is renounced (§3.2). Whatever this chapter eventually describes, it cannot be funded by inflation.

5.8 What has to be true for this to work

Conditions rather than promises, in the order they actually gate each other:

1. Something has to earn. Steps 2 through 5 distribute a number that is currently zero. A perfect distribution contract over an empty treasury changes nothing.
2. The treasury needs a published address. Donations are the one source that could work today, and there is nowhere to send them. This is the smallest item on the list and it is not done (issue #124).
3. The distribution contract has to be written. It would hold community funds, so the same standard applies to it as to the bridge in §4.5: shared control before it holds anything.
4. The DAO needs voters. "The DAO sets the shares" is a sentence about an electorate that currently has a voting-token supply of zero (§6.3). Governance participation is therefore not a separate nice-to-have — it is a precondition of step 4, and §6.7 is where the work on it is described.
5. The design has to be adopted rather than announced. Everything above is a proposal until the electorate in condition 4 exists and votes on it. §6.7 states what that takes and how it can be checked from outside.

Condition 4 is the one most easily overlooked and the one that decides whether this design is governance or decoration.

5.9 What would change this chapter

Observable events, so that progress can be checked rather than believed:

• A non-zero balance at a published treasury address — something has been earned or given, and it landed somewhere anyone can watch.
• A deployed distribution contract, with its address in Chapter 9 and its source verified.
• A governance proposal that sets shares, with actions attached rather than as a signal (§6.5) — that is the first moment step 4 is real.
• Advertising visible on the site again — the channel in §5.6 came back, and this document should then say on which pages and to what end.
• A published rule for the shares, before the first payment out of the community pot. A rule published afterwards is a rule its beneficiary wrote for himself.
• The handover point in §6.7 reached — the moment the sentence "the DAO sets the shares" stops describing an intention.

Until at least the first of those has happened, this chapter describes an intention, and it says so in its own heading rather than making a reader work it out.

5.10 Verify this yourself

The claim to check first is the one this chapter is built on — that the treasury is empty. It is a single call, and it needs no key, no account and no trust in this document:

# ETH held by the DAO
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0x1862820429B8E8F0F4166a548c2C5C443f665498","latest"]}'

0x0 means what it says. For the token side, ask the SHIBC contract what that address holds (balanceOf, selector 0x70a08231):

curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0x70a082310000000000000000000000001862820429B8E8F0F4166a548c2C5C443f665498"},"latest"]}'

And the full history of that address — every transfer it has ever received — is one request. There is one entry, and it is not from this project:

curl -s "https://eth.blockscout.com/api/v2/addresses/0x1862820429B8E8F0F4166a548c2C5C443f665498/counters"

If any of those three ever return something other than zero, this chapter is out of date — and that is the intended way to find out.

Chapter 5 of the Shiba Classic whitepaper (rewrite, issue #118). Treasury balances and transfer history measured against Ethereum mainnet on 24 August 2026. The mechanism in §5.3 is the maintainer's stated design and is not implemented; §5.6 records an operational decision taken by the project. This document is not legal or tax advice — see the reservation in §5.7.

6. Governance

Evidence rating: 🟡 partly exists — the machinery is deployed and has been used exactly once. Everything in this chapter is reconstructed from Ethereum mainnet on 23 August 2026: the DAO contract, its voting parameters, and the complete record of every proposal and every vote ever cast. There is not much of it, and what there is, is stated in full.

Most whitepapers describe governance as an intention. This one can do something better and worse at the same time: the system exists on-chain, so its use can be counted — and the count is low. Both halves are below, because a governance chapter that describes the design without the usage would be describing a road nobody has driven on.

6.1 What exists

The parameters were set when the DAO was created and are readable from the same transaction:

ℹ️ The chain stores the two percentages as 510000 and 400000. Aragon's verified source defines RATIO_BASE = 10 ** 6, so those are 51 % and 40 %; the voting mode is stored as 2, which that source's enum VotingMode { Standard, EarlyExecution, VoteReplacement } resolves to the third option. Both are read from the deployed code rather than from documentation, because the raw values in the log look like nothing on their own.

6.2 Where voting power comes from

This is the part that decides whether governance here is open or granted, so it is stated before anything else.

gSHIBC is a wrapper, not a separately issued token: underlying() returns the SHIBC contract itself (measured, §9.5). Voting power is therefore something a holder creates, by depositing SHIBC and receiving gSHIBC in return, and undoes by withdrawing.

Why a wrapper at all, rather than voting with SHIBC directly. A vote has to know what an address held at the block a proposal opened — otherwise the same tokens vote twice, bought after the proposal opens or moved to a second wallet between votes. Recording that requires the token to keep a balance history, and SHIBC keeps none: getPastVotes reverts on SHIBC and answers on gSHIBC, while both answer totalSupply() normally.

curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json'   -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8","data":"0x3a46b1a800000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001"},"latest"]}'

That returns "error": {"code": 3, "message": "execution reverted"}. Nor can the capability be added later: ownership was renounced, so nothing about the contract can be changed (§3.2). The wrapper is therefore not a design preference — it is the only way to add what a vote needs without touching a contract nobody can touch.

The whole of it, and the point is that both arrows on the left are the holder's:

flowchart LR
    W["Your wallet — SHIBC"] -- "deposit" --> G["gSHIBC — voting power"]
    G -- "withdraw" --> W
    G --> V["Vote on a proposal"]

Three consequences, and they are the reason this design was worth choosing:

• Nobody distributes voting power, and nobody can withhold it. There was no governance allocation, and there could not have been one — consistent with the fact that there was no token allocation either (§3.7).
• Voting power tracks holdings, not a list someone maintains.
• It has to be claimed. A holder who never wraps has no vote, however much SHIBC they hold. That last point is not a detail; it is most of §6.4.

6.3 The one vote that has taken place

Since the DAO was created, exactly one proposal has been opened. Here it is in full, with the times as the chain records them.

ℹ️ That withdrawal during the voting period did not affect the result and could not have. Aragon counts against a snapshot block taken when the proposal opens — block 21518435 here, readable from the proposal itself. Voting power is fixed at that moment, so selling or unwrapping afterwards changes nothing about a vote already cast. It is mentioned because a reader checking the timeline will notice it and would otherwise have to guess.

The proposal text is stored on IPFS and is still retrievable (bafkreif35fzzodvort3ccbz4ocy444tr6vcubrtb6zvtmgxgeserln7c34). It proposed forming dedicated work or focus groups in the community, arguing for productivity, use of members' expertise and clearer communication.

Result — read from the contract, not inferred from the events:

And since 11 January 2025 the voting token has had a supply of zero, which means that as of today nobody holds voting power at all — not because it was taken away, but because nobody currently has SHIBC deposited.

6.4 What that vote does and does not prove

It proves the machinery works. A proposal was created, a voting period ran, votes were cast and recorded, the token wrapper minted and burned as designed. That is more than most projects of this size can demonstrate, and it is a fact rather than a claim: every step above is a transaction.

It does not prove the community governs. Two addresses took part. Together they had wrapped 350,001,000,000 SHIBC — 0.0350 % of total supply. Judged against the token as a whole, that is a rounding error.

⚠️ And here is the mechanism detail a reader should know, because it makes a formally impressive number nearly meaningless. The 40 % minimum participation in §6.1 is measured against the voting power that exists — the wrapped supply — not against all SHIBC. When only two holders have wrapped, they are the electorate: participation was 100 % and the threshold was cleared comfortably.

So "quorum reached, unanimous approval" is true and would be a misleading thing to print on its own. The honest version is both numbers together: 100 % of the votes that existed, cast by holders of 0.0350 % of the supply. This is the same principle applied in §3.5, where the denominator was taken from the contract rather than from a list — a percentage is only as good as what it is a percentage of.

6.5 The decision was never carried out

The work/focus groups were approved and never formed. That is stated in §8.1 as a limitation, and this chapter can now say precisely what happened, because the shape of the proposal explains part of it.

The proposal carried no on-chain actions. Its actions field is empty and executed reads false (§6.3) — it was a signal, an expression of intent by those who voted, not an instruction the DAO could execute. There was never anything for the contract to perform; carrying it out was always going to be organisational work by people.

That distinction matters in both directions:

• It means "never executed" is not a case of the DAO failing to act on a decision, and no amount of better contract design would have changed the outcome.
• It also means the decision died where every voluntary commitment dies in a project with one active maintainer (§8.1) — in the gap between agreeing something is a good idea and having someone do it.

What follows from it is the same thing §8.1 arrives at from the other direction: forming groups requires people who are known and available, and that is the slowest of the steps listed there — not because it is technically hard, but because trust takes time to establish. The proposal was not wrong. It was ahead of the community it needed.

6.6 Custodian, yes. Override, no.

One distinction has to be explicit here, because two reasonable-sounding statements about multi-signature wallets appear to contradict each other and do not:

A multisig as custodian is part of the answer. A multisig able to overrule governance is the problem it was meant to solve. The difference is between who has the keys and who may change the rules. Both statements hold at the same time, and they are printed together so that neither reads later as a reversal.

Measured: who actually holds those permissions

The parameters in §6.1 are not carved into the chain — the voting plugin sits behind an upgradeable proxy, and Aragon guards both the settings and the upgrade with named permissions. So the right question is not can they change, but who may change them. That is readable from the DAO, and here is the answer:

The person maintaining this project holds no privileged role in its governance. No back door, no admin key, no ability to raise or lower a threshold. That is worth stating plainly, because for a project run by one person it is the opposite of what a reader would reasonably assume — and unlike a promise, it is a request away (§6.9).

⚠️ The same fact has a second, less comfortable side. "Only the DAO may change it" means that today nobody can change it, because the DAO has no voters (§6.3). The 40 % rule in §6.1 and its denominator problem in §6.4 are therefore not merely unfixed — they are unfixable until an electorate exists. Changing them would require a proposal decided under exactly the rule being changed.

That is not a deadlock anyone can be blamed for, and it is not permanent. It is one more reason why §6.7 puts the wrap step first: everything else in this chapter waits behind it.

6.7 How decisions are actually made today

Plainly, because the alternative is letting a reader infer it from the silence: today one person decides most things — the maintainer described in §8.1. There is no council, no elected role and no second signer.

That is not a governance model, it is the absence of one at the operational level, and it sits next to a deployed DAO that nobody currently uses. Saying so is more useful than describing the DAO as if it were carrying the project, because a reader who checks will find the same one-proposal record as above.

This has a name, and it is worth using it. One person deciding while an electorate does not yet exist is the bootstrap phase of progressive decentralisation — a documented pattern, and an honest one as long as two things hold: every decision is published, and the point at which it ends is fixed in advance and cannot be triggered by the person it concerns.

This project states that point, and it has two halves that must both be true:

As long as nobody but the maintainer holds voting power, he decides and documents every decision. The handover point is reached when both of the following hold: 1. the date has passed — the first quarter of 2027, fixed in advance and not moveable by the maintainer; and 2. a proposal has been carried by at least ten different addresses other than the maintainer's, together holding at least 5 % of the total supply, with no single one of them contributing more than a tenth of the supporting weight. From then on, decisions bind the contract and the maintainer executes them.

Why both. A date alone arrives whether or not anybody is there to take over — it would hand the project to whoever happens to hold the most at that moment. A holder threshold alone can be waited out indefinitely by doing nothing. Together, the date stops the handover being postponed and the threshold stops it being empty.

He may vote. His vote simply does not count towards the proof that a community exists — otherwise he could trigger the handover on his own.

And no address, his included, ever carries more than a tenth of the voting weight. That cap applies to every vote, not only to this one. It costs every large holder something, and it is the only reason a handover written by the largest holder is worth more than the paper it is on: without it, "the community decides" and "he decides" are the same sentence.

Every part of this is checkable on-chain: the date is a date, who opened a proposal and who carried it are recorded, and the total supply the 5 % is measured against is fixed and public (§3.1). Measuring against the total supply is deliberate — the wrapped share shrinks to whoever happens to have wrapped, so a percentage of that would prove nothing.

What is being done about it, in the order it can actually happen:

1. Lower the distance to a vote. The single largest obstacle is not apathy, it is the wrap step: a holder must deposit SHIBC to have a vote at all, and nothing in the project's channels currently explains that. Explaining it is free.
2. Bring proposals to where the community already is. Discussion happens in Telegram, and a route from discussion there to a proposal on-chain is planned rather than existing.
3. Put real decisions in front of it. Governance is used when something is at stake. The treasury and distribution design in Chapter 5 is exactly that kind of decision — the shares are meant to be set by vote — which is why the two chapters depend on each other.
4. A group of people who can decide and act, which is the fourth step in §8.1 and the same thing Proposal #0 was reaching for.

None of that is done. All of it is smaller than building the DAO was, and the DAO already exists — the expensive part is behind, not ahead.

6.8 What has to be true for this to work

Stated as conditions rather than promises, so that progress can be checked instead of believed:

• Voting power has to be held — and there is now a number for how much. While the wrapped supply is zero, no proposal can pass, however good it is. The threshold that ends the bootstrap phase in §6.7 is 5 % of the total supply, held between at least ten addresses other than the maintainer's, with no single one of them contributing more than a tenth of the supporting weight — and it applies from the first quarter of 2027, not before. Measuring it against total supply rather than against the wrapped share is deliberate: the wrapped share shrinks to whoever happens to have wrapped, and a percentage of that proves nothing — the same denominator problem §6.4 describes. It is a threshold anyone can check rather than a judgement about when the community is "ready".
• Proposals have to come from more than one address. The threshold is not what stands in the way: 200 billion is 0.02 % of total supply, and 312 addresses currently hold enough SHIBC to clear it if they wrapped (measured 23 August 2026, excluding the pool and the burn address). What is missing is not eligibility, it is use.
• Decisions have to reach the chain with actions attached, or they remain signals like Proposal #0. Signals are legitimate; they are just not self-executing, and the paper should not present them as decisions taken.
• Participation must be readable against the supply, not only against the wrapped share. This document commits to publishing both numbers, as in §6.4.

6.9 Verify this yourself

The DAO can be opened at app.aragon.org. For the underlying record, read the plugin's logs directly — every proposal and every vote in the project's history is in this one response:

curl -s "https://eth.blockscout.com/api?module=logs&action=getLogs\
&fromBlock=21510000&toBlock=latest\
&address=0x96792b409c39af45749bFb425A2Da41724721FFe"

Seven entries: four from the plugin's own creation, one ProposalCreated, two VoteCast. There is no eighth. The voting token's supply — the electorate — is one call:

curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x70abdb199A8AF9456F847B0c705539E70B9bdde7","data":"0x18160ddd"},"latest"]}'

If that returns zero, this chapter is current. If it returns something else, somebody has wrapped — and the number next to it is how much of the supply is currently able to vote.

The proposal's own record — tally, quorum, and whether it was ever executed — comes from the plugin in one call (getProposal(0), selector 0xc7f758a8):

curl -s -X POST https://eth.drpc.org -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x96792b409c39af45749bFb425A2Da41724721FFe","data":"0xc7f758a80000000000000000000000000000000000000000000000000000000000000000"},"latest"]}'

The second 32-byte word is executed. It is zero.

Chapter 6 of the Shiba Classic whitepaper (rewrite, issue #118). Governance history reconstructed from Aragon OSx contract logs on Ethereum mainnet, 23 August 2026; proposal text retrieved from IPFS.

7. What is planned

Evidence rating: 🔴 none of this exists yet — that is what makes it a plan. This chapter is deliberately separated from Chapters 4 and 5 so that nothing in it can be mistaken for something in operation. Where an item is blocked by a specific, named condition, that condition is stated with the condition's own status; those statuses were read from the project's tracker on 24 August 2026.

The document this replaces put a roadmap next to a description of products, in the same voice, with the same confidence. A reader could not tell which items existed. That is the single most damaging thing a paper like this can do, and it is why the plans live in their own chapter here, under their own heading, with a red marker at the top of it.

7.1 Why there are no dates in this chapter

This roadmap gives an order, not a schedule. No quarters, no target months, no "H1".

That is a choice, and undated roadmaps are rightly treated with suspicion — so here is the reasoning rather than the assertion.

• A project with one active maintainer (§8.1) cannot forecast delivery dates honestly. A date would be a guess dressed as a commitment, and the previous version of this document already demonstrates what happens to credibility when a paper states things it cannot support.
• A broken date costs more than a kept one earns. Nobody buys a token because a milestone landed in the quarter it was promised. Plenty of people stop trusting a project when one does not.
• The dependencies here are real, not administrative. Several items below wait on somebody else acting — a second key holder, a first voter — and that does not resolve on a calendar.

What replaces the date is the gate. Each item names what must be true before it can start, and those conditions are checkable — most of them are open tickets with a status. That is a stronger commitment than a quarter, because it can be falsified: if a gate closes and the item does not move, that is visible.

⚠️ Exactly one dated commitment exists in this document, and it is process rather than product: the reporting cadence in §7.3 — monthly and quarterly. That one is dated on purpose, because a cadence that is merely "regular" is not a cadence and cannot be broken visibly. Everything else in this chapter is ordered, not scheduled.

7.2 The order

The table says what each step waits on. The picture says the same thing as a shape, and the shape is the argument: almost everything on the left waits on nothing at all.

flowchart LR
    subgraph NG["Waits on nothing"]
        S1["1 · Make what exists countable"]
        S2["2 · A treasury that can receive"]
        S3["3 · Distribute keys and access"]
        OUT["Outside the order — white-label, merch, more games"]
    end
    S3 --> S4["4 · Governance that is used"]
    VP["Reachable voting power"] --> S4
    CC["A contract correction"] --> S5["5 · The bridge on mainnet"]
    ESC["Shared control of the escrow"] --> S5
    S5 --> S6["6 · Products that sit on top"]

Steps 1 to 4 are not gated on anything outside the project. Step 5 is gated on two open pieces of work, neither of which needs anybody's money. That is the honest shape of this roadmap: none of it is blocked by cost, and all of it is undone.

⚠️ Three planned things sit outside this order entirely, because they wait on nothing at all — a white-label version of the project's own tooling, a merchandise shop, and further games. They are described in §7.8 rather than in the table above, because a list whose whole subject is what waits on what has no row for something that waits on nothing.

7.3 Step 1 and 2 — the cheap things that are not done

These are grouped because they share a property: none of them requires money, permission, or anybody else's cooperation.

Those two belong together and are the cheapest items in this document. Neither earns anything. What they produce is voters — and without voters the handover point in §6.7 is unreachable, which makes every decision in Chapter 5 the maintainer's for as long as it stays that way.

The monthly-update row is a dated commitment on purpose. A cadence that is "regular" is not a cadence. Monthly and quarterly are checkable: if three months pass without an update, this line is a broken promise and should be read as one.

⚠️ Eight items and none of them done. That is a fair criticism of the project and it is printed here rather than left for someone else to make. The reason is the one in §8.1 — a single pair of hands prioritises, and these lost. Saying so is more useful than an explanation that sounds like an excuse. Only one of the eight depends on anybody else at all: the token-gate relies on an off-the-shelf service rather than on anyone's permission.

7.4 Step 3 — distributing access

Today one person holds every credential the project depends on: the domain, the servers, the database, the deployment system, the social accounts. §8.1 measures what that means, and it is the single risk in this document that can be reduced without earning a cent or convincing anyone.

The intended shape:

• A multi-signature arrangement as custodian, and a second, separate store for recovery credentials — deliberately not the same one that holds the infrastructure secrets.
• A threshold of two out of three, so that losing one key holder is survivable.
• Custodian, yes. Override, no — the same distinction as §5.5 and §6.6. The multisig holds keys; it does not get to change the rules the DAO sets.

⚠️ The condition on which such schemes usually fail, stated in advance: key holders have to be reachable, and if one drops out the shares must be redistributed immediately. With two of three, the first loss is survivable and the second is total. A scheme that is set up once and never revisited provides the appearance of resilience and not the substance.

ℹ️ One lever already exists and is worth naming, because it is easy to overlook: the encryption keys of the project's secret store are already split into shares by design. How many exist, what the threshold is, and where they are held decides whether that mechanism does anything. If they all sit with one person, the machinery is present and inert.

7.5 Step 4 — governance that is used

The DAO exists, has been used once, and currently has an electorate of zero (§6.3). Step 4 is not about building governance; it is about the four things §6.7 identifies, and they run in this order for a reason:

1. Explain the wrap step. The single largest obstacle to voting is not apathy — it is that holding SHIBC does not give you a vote until you deposit it, and nothing in the project's channels currently says so. Explaining it costs nothing.
2. Bring proposals to where the community already is — the Telegram channel, not a governance interface people would have to discover.
3. Put a real decision in front of it. Governance gets used when something is at stake. The distribution shares in Chapter 5 are exactly that decision, which is why steps 2 and 4 of this roadmap depend on each other.
4. A group of people who can decide and act — the same thing the one and only proposal ever passed was reaching for (§6.5), and the slowest item here, because it depends on trust rather than on work.

How a decision would be taken. The intended procedure is conviction voting: proposals accumulate support over time, and one that accumulates enough is paid out by the contract itself. No meeting date, no voting round, no board — whoever wants something supports it and waits. It has been in production use elsewhere since 2020, so it is a choice between known options rather than a design exercise.

7.6 Step 5 — the bridge on mainnet, and exactly what stands in the way

This is the largest item in the chapter and the one most likely to be misread as imminent. It is not. The machinery works on test networks and has been used there (§4.5); moving it to mainnet is gated on two conditions, and each has a status.

Both are open, and neither is waiting on anyone outside the project. That is the whole reason this bridge is not on mainnet, and publishing it is more useful than publishing a target date.

What every change passes through

The on-chain code is not simply written and deployed. Each change runs through an automated chain before it reaches a test network, and the chain is described here by what it examines rather than by how many checks it contains — a count would be out of date the week someone adds a test.

⚠️ Two of those steps do not trust the exit code of the tool they run. They read its output and fail when fewer checks ran than the step expects, because a green result from a suite that quietly stopped running is the failure mode that matters here — and this project has hit it before.

🔴 A deeper chain exists and is not yet pointed at this program. The protocol this bridge integrates with runs a considerably wider set of checks over its own programs: analysis of the compiled intermediate representation, a scheduled scan against a published corpus of known Solana attack patterns, property tests over economic invariants, fuzzing, and a gate that combines the results and reports inconclusive rather than passing when coverage is missing.

Extending that chain to this program costs machine time, not money — the tooling is built and already runs elsewhere. It is named here so that its absence today is not mistaken for its presence.

⚠️ The decimal mismatch is worth stating precisely, because it is an example of the sort of thing this project would rather find in a testnet than in production. Amounts crossing the bridge are serialised at a fixed precision. That precision has to satisfy an arithmetic constraint — with a supply of one quadrillion tokens, encoding at six decimal places would make it impossible to move more than a small fraction of the supply, because the destination chain's balances would overflow. The correction is a move to three decimal places. Measured today: the destination-side token already uses three, and both source-side adapters still report six. The correction is half applied and the halves disagree — a state that is harmless on a test network and would not be on a real one.

ℹ️ Note what this gate list does not contain: funding. The bridge does not need a treasury to be deployed. It needs the two items above, and the second of them is the same step as §7.4.

7.7 Step 6 — the products that would sit on top

Named plainly, without an umbrella term (that construct is being removed — §4.3).

What follows describes what each product would offer, not how it would be built. The mechanics live in the code, and they change; a description tied to them would be out of date the week after it was written. What does not change as easily is the purpose, and that is what a reader needs in order to judge whether the plan is worth anything.

A marketplace

A place to buy and sell NFTs, where SHIBC is one of the accepted currencies. That last part is the reason it appears in this document at all: it is one of the few designs in which holding the token does something other than sit in a wallet.

Three properties are worth stating, because they are decisions rather than details:

• A seller names a price, a buyer may pay in a different currency. Someone can list for one currency and be paid in another, with the conversion handled in the middle. A buyer is not forced to acquire a specific token before bidding.
• The trade settles as one operation. The asset and the payment change hands together, or neither does. There is no window in which a seller has given up an item and is waiting for money.
• The seller keeps ownership until the sale. A listing can be withdrawn.

The reference implementation accepts SHIBC alongside two other currencies (§4.5). 🔴 It is not deployed anywhere, and this project's site has no marketplace page.

A wallet application

One place to hold SHIBC, move it between the two chains, and exchange it — rather than three separate tools with three separate sets of instructions. The bridge is one route inside it, not a separate product.

The value it would add is not new capability but removed friction: today, crossing a chain means understanding what a bridge is. 🔴 Not deployed; no wallet page on the site.

An NFT collection with a purpose attached

The previous version of this document listed an NFT platform as an operating product with a quarterly revenue figure. It never operated, and the figure had no basis (§8.6). What was sound in it was the idea underneath, and that is worth keeping:

• A collection for the people who kept the project alive. Not a sale — a record of who was there. The community carried this token through an abandonment (Chapter 2), and that is an unusual thing to be able to point at.
• Holding one would do something. The intended benefits are access rather than yield — entry to things the project runs, weight in governance beyond a plain token balance, and recognition that accumulates rather than resets.

⚠️ Everything in that second point is a design, not a mechanism. None of it is specified tightly enough to be built today, and where it touches governance it collides with the open question in §6.8: voting power that nobody holds cannot be extended by an NFT either. Saying what it is for is useful. Saying it is nearly ready would be the old document's mistake again.

🔴 Nothing of this collection exists on-chain. Designs exist; the project's own page for it says "in preparation", which is accurate.

All three depend on step 5, and none of them has a date for the reason in §7.1. What they share is a condition that has nothing to do with code: each of them only matters if there is a reason to hold the token in the first place, and that is Chapter 5.

7.8 What is planned outside the bridge

Everything in §7.7 waits on step 5. Three things do not, and they are listed apart for exactly that reason — putting them in the same section would imply a gate they do not have.

A white-label version of the project's own tooling

This project maintains a multi-agent system that runs parts of its own operations. It is the most fully built piece of software in the portfolio and the least visible from outside. The plan is to offer it as a product other projects can run under their own name, paid for in crypto.

Why it appears in this chapter at all: it is the first route on which money could reach the project without a bridge, without a marketplace and without a legal entity. Payment would arrive at an address the project controls, which is the "own sales" row in §5.7 — and the reason that row has no counterparty problem.

🔴 Not offered to anyone today, and no payment route is live.

A shop for the project's own merchandise, paid in crypto

Print-on-demand goods sold by the project itself, with SHIBC accepted and given an advantage over the other currencies.

⚠️ This is not the "payments in the real world" idea that §7.9 rules out, and the difference is the direction of the trade. There, a shop that does not want the token is asked to accept it and sells it immediately — which produces selling pressure rather than demand. Here the project is the seller, the payment lands at its own address, and nobody has to be persuaded of anything.

🔴 No shop exists.

More games

Two titles run, and neither has been updated since March 2025 (§4.2). Further ones are planned, including a competitive format. They belong here rather than under §7.9 because they are the demand side of Chapter 5: the ecosystem revenue in §5.7 only exists if there is somewhere to spend the currency — and today there are two such places, both of which ignore the token entirely (§4.8).

🔴 Nothing beyond the two existing titles is built.

None of the three is gated on the bridge, and none of them is started. That is a different statement from the one in §7.7, and the difference is worth keeping: those products cannot begin yet. These simply have not.

7.9 What is explicitly not planned

Some ideas are worth recording without pretending they are scheduled. The project's tracker keeps these in a list that carries no timeframe at all, and this document reproduces that honestly rather than promoting them into a roadmap.

They are named with a sentence each rather than as a bare list, because an idea reduced to two words cannot be judged — and a reader is entitled to judge them:

• Payments in the real world. Accepting the token at merchants, in the ordinary sense of buying something. The hard part was never the payment; it is that a shop needs a reason to accept a token whose price moves.
• An education platform. Material explaining how any of this works, aimed at people who are not already in the space. Cheap to start, expensive to keep good.
• Environmental initiatives around NFTs. Carbon offsetting tied to minting. Worth noting that the chains this project actually uses are not the ones that made this an issue.
• A launch platform for other projects. Helping vetted projects start. This is the one that requires the most credibility, and a project that cannot yet route its own revenue is not in a position to vouch for anyone else's.
• Expansion to further chains. Mechanically the cheapest item on the list once the bridge works, and the least useful before it does.

These are ideas, not commitments. They are printed because the previous version of this document presented several of them as parts of an ecosystem that was being built, and silently dropping them would leave a reader who remembers the old text wondering what happened. Nothing happened: they were never started.

⚠️ If any of them moves into the ordered list in §7.2, it will be because a gate for it was defined — not because it was mentioned often enough.

7.10 How to hold this chapter to account

Every item above is either work with no gate, or work with a named gate. That makes this chapter falsifiable in a way a dated roadmap is not:

• If a gate closes and the item does not move, that is a fair criticism and this document will have to explain it.
• If an item in §7.3 is still open at the next quarterly report, the same applies — those are the items with no excuse available.
• If something appears on the website that is not in this chapter, the chapter was incomplete and should be corrected rather than quietly extended.

And the standing commitment that governs all of it: anything from this chapter that becomes real moves to Chapter 4 with a measurement attached, not with an announcement. That is the same rule every other chapter here follows, and it is the only one that matters.

⚠️ One honest limitation of this chapter, which the other chapters do not have. Everywhere else in this document, a claim comes with a command a reader can run — a balance, a contract call, an HTTP status. The gate statuses above come from the project's issue tracker, and that tracker is not public. So this chapter asks for more trust than any other, and it should not: a plan that only its author can check is a plan on the honour system.

What is being done about it: the same work items are to be published — planned and completed — on the project's own site, drawn from the tracker rather than retyped, so that this chapter becomes checkable the way §4.10 and §5.10 already are. Until that exists, the two things a reader can verify independently are the ones that matter most here: the bridge is not on mainnet (§4.10), and the treasury is empty (§5.10). Those two are the gates behind most of this chapter.

Chapter 7 of the Shiba Classic whitepaper (rewrite, issue #118). Gate statuses read from the project's issue tracker on 24 August 2026; the decimal-encoding state in §7.6 measured directly against the Sepolia testnet and Solana devnet on the same day. No item in this chapter is in operation.

8. Risks and Limits

Evidence rating: ✅ exists — this chapter describes measured facts, not intentions. All figures measured 23 August 2026 against two independent Ethereum RPC endpoints. Market-dependent values change continuously; the commands to re-measure are in §3.9.

The previous version of this document had no risk chapter. That is a strange omission for a token project, and it costs more than it saves: every risk listed below is discoverable by a reader in a few minutes. Naming them here is not a confession, it is the difference between a document that has been checked and one that has not.

8.1 One person maintains this project

Shiba Classic is maintained by one person, publicly identifiable as @LegendaryKlack on X and @KlackKlick on Telegram (§9.6).

No company, foundation or association owns or controls Shiba Classic, and none is going to. That is a decision, not a stage the project has yet to reach: the DAO is intended to be the organisation, and there is no plan to place a legal entity above it (§5.7). Nobody can be bought out of it, and nobody can be pressured into changing it, because there is no entity to buy or pressure.

⚠️ The same sentence has a cost, and it is stated here rather than left to be discovered. An arrangement with no legal entity has no liability shield either. What that means for the person named above, and for anyone who takes part in a vote, is not settled — it depends on how an unincorporated group is classified, and this document does not claim to know the answer. It is recorded as an open risk rather than presented as a solved one.

Development and infrastructure are carried out by that same person, who also trades under a separate business name. That is a supplier relationship, not ownership — it gives no rights over the token, the contract or the DAO, and it changes nothing in the paragraph above.

That person works on the project unpaid, and pays for the servers and the website out of their own pocket. They hold 3.78 % of circulating supply (2.26 % of total), bought on the open market like everyone else — there was no allocation, because this is a community takeover and there was nothing to allocate.

This is stated in the same place as the reason it matters, rather than in two separate sections. It is simultaneously:

• the clearest risk in this document. A project carried by one unpaid person is one person's circumstances away from stopping. No amount of code changes that.
• the reason a compensation share exists in the treasury design described in Chapter 5. Contributors who do the work should be able to be paid for it, decided by the DAO rather than by whoever holds the keys.

Neither half is honest without the other. Alone, the first reads as a complaint and the second as self-interest.

Visible activity is not the same as activity

One consequence deserves saying out loud, because the alternative is letting people guess.

The same person also holds a job and runs a separate business. Within the project, the work is spread across the frontend, the Telegram Mini App, the Directus backend, the deployment infrastructure, and the cross-chain work described in Chapter 4 — the bridge, the marketplace and the vault. Communication channels compete with all of that for the same hours.

So there have been, and will be again, periods where little is visible from outside while work continues, and periods where communication picks up. Neither is a reliable signal about the state of the project. That is an uncomfortable thing to admit in a document meant to inspire confidence, and it is more useful than the alternative — because a reader who expects continuous public activity from a one-person project will eventually conclude, wrongly, that it has been abandoned.

The honest version: what can be checked is the code, the commits, and what is deployed. What cannot be inferred from a quiet week is anything at all.

The sharper version of this risk: access, not effort

Capacity is the visible half. The harder half is that every credential currently sits with the same person — the domain registrar, DNS, the server, the deployment platform, the secret store, the database, the code repository, the CI system, the container registry, the Telegram bot and the public accounts.

That is not a workload problem, it is a continuity problem. If one person stops, the project does not slow down — it stops, and parts of it cannot be recovered by anyone else at all. The domain is the clearest example: everything else can be rebuilt with effort, a lapsed domain cannot.

It is stated here because distributed control is a standard due-diligence question, and the honest answer today is "one person". A reader evaluating this project should weigh that at least as heavily as anything in §8.2 or §8.4 — and should also weigh what is being done about it, below.

What is planned about it, in the order it can actually happen:

1. Emergency access — recovery codes and credentials secured outside the running system, with a named person and a defined condition for using them. Costs nothing, needs no team, and removes the worst outcome. This is the first step.
2. A second holder for the systems that permit it, so no single account is the only way in.
3. A multisig for anything holding value. ⚠️ Not to be confused with Chapter 5: a multisig as custodian of keys is the solution to this risk; a multisig able to override the distribution contract would undermine the governance described there. Both hold at the same time — the difference is between who has the keys and who may change the rules.
4. A team from the community — people who have been around long enough to be known, with described roles rather than vague "help wanted". This is the slowest step, because in this field trustworthiness is the scarce resource, not availability. It also connects to the Work/Focus Groups decision that was voted on and never implemented (Chapter 6).

None of this is done yet. It is tracked as issues in the project's repository, which is not public today — so the plan above can be described here, but not yet inspected. That is a gap in precisely the dimension this section is about, and it is named rather than glossed over; what can be checked today is what is deployed and what this document states.

Until the steps above are done, this section is the most significant risk in this document, and it is also the one being worked on first.

8.2 Holdings are concentrated

Eight addresses hold 21.93 % of circulating supply between them (Chapter 3, §3.7). None is a contract, an exchange wallet or a tagged institution — each was checked individually — but who controls them is not known, and the chain does not answer that question.

Concentration means a small number of decisions can move the price a lot. This is true of most tokens with a small market and is not evidence of intent; it is simply a fact a holder should know before, not after.

Two things that are not risks here, and are often confused with this one: the largest position in the list is the liquidity pool itself (21.89 %), which is not a person, and the burned supply at 0x…dEaD (40.23 %) cannot re-enter circulation at all.

8.3 One residual privilege the renounce did not cover

Ownership is renounced (§3.2), which permanently disables the levers over fees, trading and limits. It does not disable everything, and Chapter 3 §3.3 sets out the exception in full:

Three functions — removeSellLimit, clearStuckEth, clearStuckTokens — check against a separate deployerWallet address rather than owner. That address is 0x1314e07ec05cf76D7ed88426fc433d710462c62f, the wallet that deployed the contract, and therefore an address from before the community takeover. The project does not control it.

Measured scope of that privilege:

These functions reach only assets sitting in the token contract itself. They cannot touch a holder's balance, cannot mint, cannot change fees and cannot stop trading. Today they can move nothing at all, because the contract holds nothing. The contract does accept ETH, so funds sent to it in future would be withdrawable by that address — a reason not to send anything there.

⚠️ Both have been exercised, which is why this is listed as a live risk rather than a technicality (Chapter 2, §2.3): removeSellLimit on 13 November 2024, 27 minutes after the renounce, and clearStuckEth on 6 January 2025, withdrawing 0.7944 ETH from the contract. Neither was a breach — both are functions the contract grants that address — but they establish that the privilege is used, not dormant.

8.4 Liquidity is burned — and it is thin

Burned liquidity (§3.5) removes one specific risk: nobody can withdraw the pool. It does not make the pool deep, and depth is what determines whether you can sell without moving the price.

The pool is small in absolute terms — a trade of a few ETH moves the price substantially in either direction, and a large holder cannot exit at anything close to the quoted price. That is the single most important property in this chapter for anyone considering a position, and it does not depend on what the pool happened to hold on any given morning.

Two things should be said about it, and leaving out either one would be misleading:

Market capitalisation is the weaker of the two figures. It is supply multiplied by the last traded price, and at this depth that price is not one at which the supply could be sold. Anyone quoting a market capitalisation without the pool liquidity next to it is quoting the more flattering half.

Relative to its own size, the pool is unusually deep. Liquidity is a substantial fraction of market capitalisation, where single-digit percentages are the norm for a token of this type. The ratio is a direct consequence of the burned LP tokens (§3.5): the pool cannot be drained, so it has stayed proportionate as the market capitalisation fell. Small in absolute terms, well-covered in relative terms. Both are true.

⚠️ This document prints no market figures, and that is deliberate. Reserves, liquidity, market capitalisation and the exchange rate change by the hour; a number written here would be wrong the day after publication and would keep looking authoritative while being wrong. §9 names the pool contract and the burn address instead. What is stated here is the shape of the situation, which holds across a wide range of values — and where an exact number matters, the reader is better served by reading it off the chain than by trusting a figure of unknown age.

And depth has to grow with the project, which is less obvious than it sounds. In a pool of this type the value of the pool grows only with the square root of a price increase, while the market capitalisation grows with the whole of it. A rising price on its own therefore makes the ratio above worse, not better — the unusually good coverage this pool has today would decay into the single-digit range that is normal for tokens of this type, without anybody doing anything wrong.

The intention is therefore that part of any future income goes into the liquidity of the trading pair over time, so that depth keeps pace with size. It is an intention: there is no income yet (§5.1), so there is nothing to route.

8.5 Trading venues are limited, and one of them is exposed to EU regulation

SHIBC trades in two places: the Uniswap V2 pool above, and Biconomy, its only centralised exchange listing. The order book there has no meaningful depth.

Biconomy.com is registered in the British Virgin Islands and does not appear in the ESMA registers of authorised crypto-asset service providers. Since 1 July 2026, only CASP-licensed firms may serve customers in the European Union. If Biconomy is not licensed, the listing may become unreachable for EU users — independent of the depth question. That is Biconomy's regulatory position rather than the project's, but the effect on tradability is real and belongs here.

Absence from a register is not proof of anything; an application may be pending. This paragraph describes what is publicly visible, not a legal conclusion.

8.6 Most of the value-flow design does not exist yet

Chapter 5 describes how value is intended to return to the project: revenue to a treasury, distribution by contract, allocation shares governed by the DAO, no multisig override.

None of that exists today. It is architecture, not operation:

It is written in the future tense throughout that chapter for exactly this reason. A reader who takes it as a description of something running would be misled — which is precisely the failure the previous version of this document contained, where a revenue figure was quoted for a product that never operated.

8.7 The audit, and what it does and does not cover

The contract was audited by Hashlock Pty Ltd in December 2024. The report is public: hashlock.com/audits/shiba-classic.

The auditor's conclusion: "the Shiba Classic project seems to have a sound and well-tested code base… Hashlock is not able to identify any further vulnerabilities."

Three qualifications belong next to that, because a rating quoted alone is worth less than it appears:

The findings are marked "Acknowledged", not "Fixed". Each of the six items carries that status in the report. Acknowledged means the issue was understood and accepted, not corrected — and after the ownership renounce the contract cannot be changed anyway. They are minor (missing events, a deprecated .transfer(), an unchecked return value, redundant SafeMath), but "audited" does not mean "every finding was removed".

The rating is "Secure", not Hashlock's higher "Hashlocked" tier. By their own definition that tier is reserved for projects maintaining a bug bounty programme or on-chain monitoring. This project runs neither.

On one point, this document is more complete than the report. Finding [L-01] records a statement by the then-team: "only the function removeSellLimit can be executed by deployerWallet, other mentioned functions can't be called because the ownership is renounced." The verified source shows three functions checking against deployerWallet — removeSellLimit, clearStuckEth and clearStuckTokens (§8.3). The auditor evidently saw the other two, since QA items Q-01 and Q-02 are about exactly those functions. The team's summary of the scope was simply narrower than the code. §8.3 states the full picture.

An audit is a snapshot of a code base at a point in time by people who can miss things — as their own disclaimer says. It is meaningful evidence, not a guarantee.

8.8 What holding SHIBC does not give you

Plainly, because these are the points most often left implicit:

• The value can fall to zero. SHIBC is a volatile crypto-asset with no intrinsic value, no revenue backing and no redemption claim against anyone.
• Continued tradability is not guaranteed. No party is obliged to maintain a market, and the venues in §8.5 can change or disappear.
• It may not be liquid when you need it to be. See the pool depth in §8.4.
• It is not covered by any investor compensation scheme.
• It is not covered by any deposit guarantee scheme.
• It grants no claim on any entity — no equity, no dividend, no repayment, no share of revenue. Governance participation is not ownership of anything.

8.9 How these are being dealt with

Listing risks without saying what happens next would leave a false impression in the other direction — that they are accepted as permanent. They are not. So, in the order they are being worked on:

What this project is, and is not

One sentence, because it changes how everything above should be read:

The people maintaining Shiba Classic are not its owners. There are no owners. Ownership of the contract was renounced on launch day (§3.2) and cannot be reinstated by anyone. What remains is an executing role — someone who builds, publishes and keeps the lights on on behalf of the community, not above it.

Today one person holds that role, which is the whole of §8.1. The direction of travel is the opposite of consolidation: more people who can decide and act, so that the project stays able to make decisions in the community's name if any individual steps away — and so that significant moves require the community's agreement rather than one person's judgement. That is not yet fully established; it is what Chapter 6 describes and what the work above is for.

None of the above is a reason the project cannot work. It is the list of things that have to be true for it to. Publishing that list, rather than the version that reads better, is the one thing a reader can check today.

8.10 Conflicts of interest

Every one of the five below is already stated somewhere in this document. They are collected here because a conflict a reader has to assemble out of four chapters is one most readers will never find — and because the list is short enough to print in full.

⚠️ The last row has no mitigation, and inventing one would be the worst kind of entry in a table like this. The same organisation builds and operates the game whose in-game currency SHIBC would buy, and built the protocol the integration runs through. The first intended source of revenue in Chapter 5 is therefore a share of something this project neither operates nor measures. The exposure is real, and nothing currently limits it except that none of it is live.

Naming a conflict does not remove it. What this table is good for is narrower than it looks: it lets a reader check whether the limits in the third column actually exist — each of them is a date, a contract rule or a published figure rather than an undertaking. Two of the five have no limit at all, and they say so.

8.11 Status of this document

This is a project description, not investment advice and not legal advice. It has not been reviewed or approved by any regulatory authority, and it has not been submitted to one.

Where this document states a number, it is measured and the command to re-measure it is included. Where it describes something that does not exist yet, it says so and marks it. Where something is unknown — such as who controls the addresses in §8.2 — it is written as unknown rather than filled in with a plausible guess.

This document is versioned. Which version this copy is, and everything that changed before it, is in §9.10. A paper that is edited without saying so is worth less than one that is not edited at all.

Chapter 8 of the Shiba Classic whitepaper (rewrite, issue #118). On-chain values verified against two independent RPC endpoints on 23 August 2026.

9. Addresses and Evidence

Evidence rating: ✅ exists — this chapter is a register, not an argument. Every address and transaction below was resolved on 23 August 2026 against Ethereum mainnet. Addresses and transaction hashes do not change; balances and market figures do, which is why this chapter carries none of them and points to where they live instead.

Earlier chapters make claims and show the calls that support them. This one collects the identifiers those calls refer to, so that a reader who wants to check something does not have to hunt through the text for an address.

9.1 How to read this register

Each fact in this document has exactly one home. Where a figure changes on its own — with the market, with every trade, with every block — this paper does not print it at all; it names the address or the call the reader can use to obtain the current one:

This chapter deliberately does not repeat them. Two places carrying the same number is how documents come to contradict themselves, and a document that contradicts itself is worth less than one that says nothing.

9.2 Contract addresses on Ethereum mainnet

Addresses for the products described in Chapter 4 are not listed here. When any of them runs under a mainnet contract, its address belongs in this table and Chapter 4 states its status until then.

9.3 The transactions the claims rest on

Every load-bearing statement in Chapters 2 and 3 is a transaction, not an assertion. These are the transactions, in order.

Prefix any hash with https://etherscan.io/tx/ or https://eth.blockscout.com/tx/ to open it.

Three of them are worth opening if you only open three: the renounce is the guarantee, removeSellLimit is the proof that the renounce did not cover everything (§3.3), and the DAO creation is the whole of the on-chain governance record so far (§9.5).

9.4 The burn address is not where the burning is decided

The project's website links 0x654d433463cb2444D063397a245678a33961090B under the label "burn wallet". Anyone following that link finds an address holding no SHIBC at all, which invites exactly the wrong conclusion. The explanation is straightforward, and it is better stated here than left to a reader's imagination.

That address is a forwarding point, not a vault. Tokens are sent to it, and it passes them on to 0x…dEaD in batches. Measured over its entire history:

In and out match to the last decimal. Nothing that entered that address stayed there.

This resolves where the burned supply in §3.6 comes from. Reading every transfer into 0x…dEaD since the token existed — 52 in total — the balance decomposes exactly:

The amounts above are rounded for reading. Computed in full precision the sum is 402317700120603346118150441812511 wei, which is exactly what balanceOf(0x…dEaD) returns — to the wei, with no remainder. The two dust entries are real transfers of a fraction of a token each, listed because a row silently dropped is how a decomposition stops being one.

⚠️ Reproduce this in integer arithmetic. These amounts have 33 significant digits in wei; IEEE-754 doubles carry about 16, so dividing by 10¹⁸ in floating point loses the tail and produces a total that disagrees with the balance in the last decimals. The mismatch looks like a discrepancy in the data and is an artefact of the arithmetic.

So the 40.23 % figure is not one event. Forty per cent was burned at launch, by the original deployer, before any takeover existed — Chapter 2 §2.2 is explicit that this was inherited, not earned. The remaining 0.2318 % was burned afterwards, in ten separate batches, and that part did not come from the launch.

⚠️ The honest part of this: the last batch was 16 December 2025. At the time of writing there has been no burn for eight months. Burning is not an automatic mechanism here, it is something someone does — and §8.1 explains why activity in this project is uneven. It is described in the present tense in exactly one sense: the address works, the route is open, and every batch that ever ran is listed above with its date.

Re-check the whole decomposition in one request — this reads the token's own transfer log and filters for the burn address as recipient:

curl -s "https://eth.blockscout.com/api?module=logs&action=getLogs\
&fromBlock=21180000&toBlock=latest\
&address=0x9562e2063122eaa4d7c2d786e7ca2610d70ca8b8\
&topic0=0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\
&topic2=0x000000000000000000000000000000000000000000000000000000000000dead\
&topic0_2_opr=and"

Each entry's topics[1] is the sender and data is the amount in wei. Summing them reproduces the table above; sorting by sender reproduces the split.

9.5 Governance addresses, and their measured state

A DAO exists on-chain. It was created on 30 December 2024 through Aragon's DAOFactory, it resolves under the ENS name shiba-classic.dao.eth, and it can be opened at app.aragon.org.

Because governance is the area where a link is most likely to be mistaken for a working process, here is what the two contracts actually hold today:

That it is a wrapper rather than a separately minted governance token is measured, not assumed — the distinction matters, because it decides whether voting power has to be claimed by holders or handed out by someone:

# underlying() on the governance token — selector 0x6f307dc3
curl -s -X POST https://ethereum-rpc.publicnode.com -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x70abdb199A8AF9456F847B0c705539E70B9bdde7","data":"0x6f307dc3"},"latest"]}'
# → 0x…0000009562e2063122eaa4d7c2d786e7ca2610d70ca8b8

which is the SHIBC contract itself (§9.2). Voting power is therefore something a holder creates by depositing SHIBC and receiving gSHIBC; nobody distributes it, and nobody can withhold it.

A voting wrapper with zero supply means nobody currently holds voting power through it — not because it was denied to them, but because no one has deposited. The structure is deployed; it is not in use. That is a plain description of a measurement, and what it means for how decisions are actually made — including the Work/Focus Groups vote referenced in §8.1 — belongs in Chapter 6, which is where governance is assessed rather than merely listed.

The address is printed here for the same reason as every other one: the link is on the project's website, so a reader will reach it anyway, and it is better to arrive with the numbers than to discover them and wonder why they were not mentioned.

9.6 Official channels

These are the channels the project publishes and controls. Each was resolved on 23 August 2026.

The maintainer — one person, as set out in §8.1 — is reachable as @LegendaryKlack on X (the handle linked from the project's own site) and as @KlackKlick on Telegram. One person, one handle per platform; there is no third account anywhere.

⚠️ Anything not in this list is not us. There is no other Telegram group, no other X account, no support desk, no airdrop channel and no staking portal operated by this project. Nobody here will ever send you a private message asking for a seed phrase, a wallet connection, a "verification" signature or a payment. This paragraph is the only defence a project of this size has against impersonation, and it works only if the list above is the one you check against — reached through the website, not through a link someone sent you.

9.7 Third-party sources

These are useful and worth knowing about. None of them is maintained by the project, which is the point of listing them separately: they can be wrong, and their being wrong is not something this document can fix.

⚠️ Two cautions that apply to aggregators generally. Their figures are derived, arrive late and are computed by rules we do not set — where such a figure differs from one in this document, the difference is a matter of method, and this document states its own method next to each number. And more than one token uses the name "Shiba Classic": the contract address in §9.2 is the only identifier that distinguishes this one. Match it before you act on anything a third party tells you.

9.8 Verifying rather than trusting

The commands are already where the claims are: §3.9 for the contract state — ownership, fees, trading, supply, burned liquidity, holders — and §2.6 for the launch timeline. §9.4 adds the one query this chapter introduces.

Between them they cover every on-chain statement in this document. None of them needs an account, an API key or our cooperation, and none of them depends on this document being honest. That is the intended property: the parts of this paper that matter most are the parts you can check without us.

9.9 What this register does not contain

Stated so the absences are not read as oversights:

• No holder identities. Eight addresses in §3.7 are marked unknown. They are unknown to us as well, and a plausible guess would be worse than the gap.
• No follower or member counts. They are not evidence of community size, and Chapter 2 §2.5 declines to use them for the same reason.
• No infrastructure addresses. Servers, deployment systems and the credential store are named as a risk in §8.1; naming them individually would help nobody except an attacker.
• No contact address for legal or regulatory correspondence, because there is no legal entity to receive it. §8.11 and §8.8 state what follows from that.
• No price, market capitalisation, liquidity or supply-in-circulation figures — anywhere in this document. This is the rule the paper follows rather than an omission from this chapter. Such a value is true for a morning. Printed in a document that is read for years, it keeps its authoritative appearance long after it stopped being correct, and no amount of dating fixes that: a reader who finds a dated figure still has to decide whether to trust it, and most will not check. What this paper prints instead is the shape of a situation — that the pool is small in absolute terms and unusually deep relative to its own size (§8.4) — which stays true across a wide range of values, plus the addresses above, from which anyone can read today's numbers directly. ⚠️ This applies to counts as well as to currency: transfers, transactions, test cases, proposal tallies. A number that grows by itself belongs to whatever measures it, not here.

9.10 Version and change history

This document is versioned, and every change to it is recorded here. A reader who saw an earlier version can tell what has changed without reading the paper again. A reader seeing it for the first time can tell how often it moves, and in which direction.

The paper before version 1.0 is not in this table, because it was not a version of this document. It was a different one: Shiba-Classic-White-Paper.pdf, published in January 2025 under shibaclassic.io/wp-content/uploads/2025/01/ and no longer served from the site. It is named here rather than quietly dropped, and it is still readable:

curl -sI https://web.archive.org/web/20250127073354/https://shibaclassic.io/wp-content/uploads/2025/01/Shiba-Classic-White-Paper.pdf

That snapshot was taken on 27 January 2025 and answers 200 with 404,558 bytes of application/pdf. §1.6 says why it was rewritten from scratch rather than corrected.

The rules this table follows, written down so that a missing row means something:

• Every change of substance gets a version and a row — a changed number, a changed mechanism, a claim added or withdrawn.
• A row says what changed, not that something changed. "Figures updated" is not an entry.
• Corrections to spelling, wording or layout do not get their own version. They are named in the next row that appears, so they are recorded without inflating the count.
• Nothing leaves this table. A version that turned out to be wrong stays in it, and the correction is the next row — not a quiet edit of the old one.

⚠️ What this table is not. It is written by hand and it lives inside the document it describes, so it carries exactly as much weight as the rest of the text: it can be read against the paper, but it is not an independent record. That is the same limit §8.11 states for everything here that is not on-chain. The statements that hold without trusting us are the ones in §9.8, and a change history cannot be one of them.

Chapter 9 of the Shiba Classic whitepaper (rewrite, issue #118). Addresses, transactions and channels resolved 23 August 2026 against Ethereum mainnet and the project's published sites.