Everything, checkable

What this page is

It reads the chain, not our records

Each figure below is a query your browser sends straight to a public Kadena node. You can send the same queries yourself — the exact commands are at the bottom.

It asks nothing of you

No wallet, no connection, no account. This page only reads.

A blank is never a zero

If a query cannot be answered, you will see why — “the contract has no such record on this chain” and “the network did not answer” are different statements, and this page never turns either into a 0.

Where all the tokens are

Are you sitting on a pile you are about to sell into the market?

Nothing is in circulation yet. That is not a gap in the data: no tokens have been sold or released, so every one of them is still sitting in the contract’s own accounts, which is what the table shows.

The four allocations below are constants inside the deployed contract, and the contract refuses to start unless they add up to the total. So this is not a summary we prepared — it is the arithmetic the program enforces on itself.

Can more be created?

Can you mint more and shrink what mine is worth?

No. The only function that creates tokens runs once, on one chain, and refuses to run a second time. There is exactly one place in the whole contract that can increase an account’s balance, and every use of it is paired with a matching decrease somewhere else — a transfer, not a mint.

The honest caveat: the total can go down. A transfer between chains is two steps, and one abandoned halfway strands those tokens permanently. Nothing can push the number up.

Can we take yours?

Once I hold some, can you freeze my account, claw them back, or stop me selling?

No, and this is worth checking rather than believing. Spending from an account requires that account’s own guard and nothing else. There is no blacklist function, no pause switch, no clawback and no administrative transfer anywhere in the contract — not disabled, not gated behind a key, absent. The same is true of changing an account’s key: only the account’s current guard can do it.

The accounts holding everything

Who is actually holding it, and what would it take to move it?

They are not all guarded the same way, and the difference matters:

Guarded by a rule — no key exists

No key can satisfy these. They are guarded by a rule inside the contract rather than by a signature, so there is no private key anywhere that could empty them — not ours, not anyone’s. They move only through the specific routes the contract provides.

Guarded by the contract

These are guarded by the contract itself. No outside key can touch them either, but the contract’s own code can move them through the routes it defines — funding a reward pool, settling a sale. Those routes are listed further down, and each one leaves a permanent record on chain.

These are real addresses on Kadena mainnet. Look any of them up in a block explorer — you do not have to take these balances from us.

The release calendar

Could you just take the treasury tomorrow?

🔴 Read the scope of this before the numbers. Three of the four allocations sit under a release calendar. The fourth — the sale reserve — is under no calendar at all: it is the pool tokens are sold from, and it can move whenever the sale is open. Do not read the locks below as covering it.

A calendar has two dates. Nothing at all is available until the cliff. After that it unlocks smoothly, a little each day, until the full-unlock date. The amount available right now is shown for each — and releasing is something anyone can trigger, not a private lever.

What the calendar does not do: it controls when tokens can move, never where they go afterwards. Once an amount has unlocked, the destination is the administrator’s to choose.

The money

Is there any money in this, and where has it gone?

All of these read zero because nothing has happened yet: the sale has never been open, so nothing has been received, and no reward round has ever been declared, so nothing has been set aside or paid out.

The contract holds funds in named accounts, and those balances are public. Every label below says exactly what the contract reports — not a friendlier version of it.

What the administrator can and cannot do

What are you locked out of, and what can you still change after I am in?

Cannot be changed by anyone, ever:

• Create tokens. The function that mints runs once, on one chain, and refuses to run again.
• Move, freeze or block an ordinary holder’s tokens. Spending needs that account’s own guard; there is no blacklist, no pause and no clawback in the contract.
• Change an account’s key. Only that account’s current guard can.
• Bring a release date forward, or take tokens before a cliff.
• Change the number of decimal places, the total, or the four allocation amounts.
• Undo a transfer. There is no reversal function of any kind.

Can be done by the administrator:

• Open and close the sale, and set its price — but only while the sale is closed, so the price cannot move under a buyer mid-sale. One device.
• Release tokens that a calendar has already unlocked, and choose where they go. The calendar controls when, never where.
• Move funds into the reward pool, declare a reward round, and recover pool funds nobody is owed. Two devices for each.
• Set the record date that decides who a reward round pays, and cancel it. One device.
• Withdraw a declared round or a scheduled record date, up to six hours before it lands. One device.
• Announce a vote and cancel one before voting opens. One device. Holders vote; holders do not propose.
• Upgrade the contract, until it is frozen. Freezing is permanent and has not happened.

🔴 On “two of three devices”. Some actions need two of three hardware devices and some need only one. Both sets of keys belong to the same operator — the three devices are all held by Smart Pacts. The two-of-three requirement limits the damage a single lost or misused device can do; it is not a second party’s approval, and you should not read it as one.

The contract is not yet frozen, which means it can still be upgraded. Freezing is permanent and has not happened. This page reads that switch on all 20 chains and reports what it finds — if it ever says frozen, upgrades have ended for good.

Why another chain looks empty

I looked at a different chain and everything was empty or errored. Is this broken?

Kadena is 20 separate chains, and the token exists on all of them — but everything was created on chain 0, so that is where it all still sits. On the other 19 the accounts have never been created, and asking for a balance there does not return zero, it returns an error. That is the correct answer to the question “what is in an account that does not exist”, and this page shows it as an absence rather than as a 0.

Check any of it yourself

Everything above is a public read. Nothing below needs a wallet, an account, or our permission.

# every figure on this page is a read like this one — no wallet, no account
curl -s https://api.chainweb-community.org/chainweb/0.0/mainnet01/chain/0/pact/api/v1/local \
  -H 'Content-Type: application/json' -d @- <<'JSON' | jq -r .result.data
{ "cmd": "{\"networkId\":\"mainnet01\",\"payload\":{\"exec\":{\"data\":{},
  \"code\":\"(n_48867b242317a0216a67f8c7ca26696b5878e0e3.SPT.chain-report)\"}},
  \"signers\":[],\"meta\":{\"chainId\":\"0\",\"gasLimit\":150000,
  \"gasPrice\":1e-8,\"sender\":\"\",\"ttl\":600,\"creationTime\":0},
  \"nonce\":\"n\"}", "hash": "", "sigs": [] }
JSON

The strongest check is not a balance — it is that the program running on the chain is the program we published. The source is public, and the code on chain can be compared against it directly.

# is the chain running the code we published?
# 1. ask the chain for its own copy of the source
#    (describe-module returns the module form ALONE — no preamble, no table footer)
# 2. take the module form out of the published deploy bytes:
sed -n '/^(module SPT /,/^)$/p' deploy-bytes/SPT.pact > /tmp/repo.pact

# 3. compare with the trailing newline normalised — see the note below
diff <(printf '%s' "$(cat /tmp/repo.pact)") \
     <(printf '%s' "$(cat /tmp/onchain.pact)") && echo "identical"

🔴 One trap, so you do not conclude the wrong thing. The chain’s copy of the source has no newline at the very end and a copy extracted from the repository does, so a plain diff reports a one-byte difference and exits with an error even when the code is identical. Compare with the trailing newline normalised, as shown, or you will get a false mismatch.

What this page does not tell you

Silence about an omission reads as concealment, so here is what is missing and why.

The sale price and terms

Recorded on chain, where anyone can read them. Not restated here — this page declines to restate sale terms, it does not hide them.

Anything off-chain

This page can only show what the contract knows. It cannot show money held anywhere else, what has been spent, or on what. Nothing here should be read as a complete picture of the company.

A history

These are all readings taken right now. The contract records its actions as permanent events on chain, but this page does not yet assemble them into a timeline.

Who holds what

Individual holders are not listed, and will not be.