Everything, checkable

What this page is

That hash identifies the running code on this network. It is not meant to match a hash you compute yourself — a Pact module hash covers its dependencies too — so the check that proves something is the byte-for-byte comparison in VERIFY.md at github.com/SmartPacts/spt ↗, which reads the code back off the chain and diffs it against the published source.

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?

Reading the chain…

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?

Not under the contract’s rules. 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 in the contract’s code can push the number up; the one exception, until the contract is frozen, is the administrator override stated under “What the administrator can and cannot do”.

Can we take yours?

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

Not under the contract’s rules, 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. One exception, and it is ours: until the contract is frozen, two of our three admin devices can override those rules in a single transaction, with no new code — including changing any account’s balance or key. It is stated in full under “What the administrator can and cannot do”, and freezing ends 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 no private key can spend from them under the contract’s rules — not ours, not anyone’s. They move only through the specific routes the contract provides, with one exception until the contract is frozen: the administrator override stated below reaches these accounts too.

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. Until the contract is frozen, the administrator override stated below reaches these accounts as well.

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. And until the contract is frozen, the administrator override stated below can reach locked tokens too.

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.

Follow the money

Where did the money from the sale go, and what is it doing now?

Sale funds leave the contract by exactly one door: a withdrawal signed by two of the three administration keys, into an account that is also under that same two-of-three rule — the company account. From there every move is a public transaction. Below, the accounts that money has touched, with their balances read from the chain right now, and every transaction on that path so far, each checked against the chain when this page loads.

The accounts on the path

Balances are read from the chain when the page loads. “Explorer” opens the account on the public block explorer, which lists its recent transfers — the place to follow anything this page does not list.

Each table — roulette, baccarat and slots — pays a fee on every board it accepts, from its own pot to the SPT funding account — never from a player’s stake. The funding account’s chain 2 balance above is those fees so far.

Every transaction so far

The list of transactions is ours; the amount, the block and the outcome beside each one are read from the chain when the page loads, and a transaction the network does not confirm is shown as unconfirmed, never as done. Each key opens the transaction on the public explorer.

What the administrator can and cannot do

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

The contract’s code gives nobody a way to do any of these — but read the last item of the next list:

• 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.
• Withdraw the sale proceeds to an account of its choosing, up to the amount the two signatures approve. Two devices. Every withdrawal is a public transaction; the ones made so far are under “Follow the money” above.
• Until the contract is frozen, override every rule on this page. Two devices, in a single transaction: publish a new version of the contract, or — with no new code at all — change any record it keeps, including any account’s balance and any account’s key. Such a transaction is public on the chain, but the published source would not change. Freezing ends both permanently, 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, and its records changed directly by two admin devices. 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.