Risks and limits

Ostrakon is a narrow tool. It does one thing under clear conditions. This page lists what it does not do, what it accepts on purpose, and where it can fail.

Read it before you propose. Read it before you vote.

Market risks

The named can dump during the vote

A Shard is public from the block it lands in. The challenge and the vote take 72 hours together. During that time, the named addresses can sell into the old pool.

This is accepted. A dump is visible on-chain, and it tends to convince voters rather than scare them. The exiled were going to sell anyway; Ostrakon only changes when everyone finds out. Holders who stay are made whole in the new token, one for one, against their snapshot balance.

What a dump does do is lower the old price and take HYPE out of the old pool before Walls starts selling. The new pool may be thinner as a result.

Sweeps can be sandwiched

Anyone can call sweep, and a sweep is a sale into a public pool. A trader who sees one coming can trade just before it and just after it. Part of the sweep's value leaks to that trader.

Ostrakon limits this with small slices. A sweep sells at most a proportional share of what is pending, at most once an hour, over 72 hours. Each slice is small. What a sandwich can take from a small slice is small.

It is limited. It is not zero.

The old pool loses its value

As Walls sells, the old pool fills with old tokens and empties of HYPE. Holders who never claim are left holding an old token in a thin market. Claims have no deadline, but the old market will not wait for anyone.

Governance risks

A whale can propose

Any holder with 0.5 % of supply can propose. A whale can open a Shard against a rival.

Proposing is not winning. The Shard must reach a quorum of 20 % of non-exiled supply, and more than 66 % of the votes cast must be yes. The named addresses cannot vote. A whale who cannot convince two thirds of a real turnout loses nothing but time, unless quorum fails, in which case the bond burns.

Naming can be evaded by splitting

Naming is per address. A named address must hold at least 1 % of supply at the moment of proposing.

A holder who expects a Shard can split a bag across many wallets, each below 1 %. None of them can be named. Ostrakon cannot see that wallets share an owner, and does not try.

Splitting has to happen before the Shard. Once the snapshot is taken, the named balances are fixed.

A root nobody can reproduce

Votes and claims are proven against the balance root. If the root is wrong in a way no one can rebuild, no one can produce a proof. No one can vote. Quorum fails and the bond burns.

That is the safe failure. A bad root ends in nothing happening.

Trust model of the balance root

The proposer supplies the Merkle root of every holder's balance. The chain verifies it rather than computing it.

A misstated balance can be challenged. Anyone who shows a leaf whose balance differs from the token's checkpointed record cancels the Shard and takes the bond.

An omitted holder cannot be proven on-chain with a plain Merkle tree. A tree that leaves someone out is still a valid tree. The challenge cannot show what is missing.

The defence is reproducibility. The tree is canonical: anyone can rebuild it from the token's public Transfer events and get the same root. The Ostrakon site rebuilds it for every Shard and warns when the on-chain root does not match.

Token requirements

ERC20Votes is required

The challenge reads the token's own checkpointed balances at the snapshot block. Tokens without ERC20Votes-style checkpoints cannot be challenged. They are not supported by the testnet contracts.

Delegation breaks the assumption

ERC20Votes tracks voting power, which follows delegation. Ostrakon assumes voting power equals balance.

If holders of a token delegate their votes to other addresses, the checkpointed record no longer matches balances. A correct root could be challenged and an incorrect one could pass. The demo tokens lock self-delegation so this cannot happen. Other tokens may not.

Immutability

There is no owner. There is no admin. There is no pause. There is no upgrade.

That cuts both ways. No one can change the rules on holders. No one can patch a bug either. If a flaw is found, the deployed contracts keep running as written. A fix would mean new contracts, and holders would have to choose to use them.

The social limit

Ostrakon removes one address, or a few. It does not save a dead project.

If everyone wants to leave, Ostrakon is the wrong tool. A re-mint of a token nobody wants is still a token nobody wants. The protocol moves a community away from a bad actor. It cannot create a community that is not there.

Testnet differences

The testnet contracts use mocks where mainnet will not.

Testnet	Mainnet
Bond is a constant 1,000 mock OSTRA	Bond is pegged to a HYPE value, paid in $OSTRA
"OSTRA (testnet mock)", fixed supply, faucet	$OSTRA, not launched
DemoPool, a minimal constant-product pool	A Uniswap-v2-style router behind the same interface

Testnet tokens and testnet HYPE have no value.