$ZC Holder Rewards Rewarding sustained ownership.

Scores are computed from Ethereum mainnet only: the Transfer events of the $ZC token (0x4E67…8722) and block timestamps. No off-chain data and no identity data. Each address's history is replayed from the token's launch, so holding age carries into the first epoch.

An address holds its coins as lots, each stamped with the time it arrived.

• ·Incoming transfer: a new lot with age 0.
• ·Outgoing transfer: every lot is reduced by the same fraction, so the age mix of what remains is unchanged.
• ·Balance reaches zero: all lots end. Later coins start at age 0.

Production implementations may bucket lots by day. The result differs by at most one day of age.

A coin of age a carries tenure weight w(a), rising linearly and then capped:

w(a) = 1 + (W − 1) × min(a, T) ÷ T

T = 168 days        W = 2.00

The address's Duration Weight for the epoch is the mean tenure weight of its coins, weighted by balance and by time:

DW = ∫ Σᵢ bᵢ(t) · w(aᵢ(t)) dt  ÷  ∫ b(t) dt

Both integrals run over the epoch. DW is always between 1.00 and 2.00.

TWAB = (1 ÷ L) × ∫ b(t) dt        L = 28 days

A balance changes only at transfers, so the integral is exact: the sum of balance × duration over the intervals between transfers. This is equivalent to sampling every block, and there is no single moment worth timing.

BW = TWAB                 if TWAB <= K
BW = sqrt(TWAB × K)       if TWAB >  K

K = 1,000,000 zc

Why the knee rather than a plain square root. Any curve that bends applied per address rewards splitting: n wallets of B ÷ n score √n times one wallet of B under a pure square root, all the way down to the smallest eligible balance. With a linear segment, splitting below K changes nothing. Ordinary holders have no reason to split at all, and only positions above K can gain, by at most √(B ÷ K).

S = BW × DW

Adding coins never lowers S. Below K, S equals the integral of weighted balance divided by L, and new coins add to it. Above K, with D = TWAB × DW, S = √K × D ÷ √TWAB. Adding coins raises TWAB by some x and D by at least x, and the change in S then has the sign of (2·TWAB − D) + x, which is never negative because DW ≤ 2. This is why the Duration Weight cap is 2.00 and not higher. The reference implementation tests the property on randomised histories.

An address is eligible for an epoch when all of these hold:

• ·It is not on the published exclusion list.
• ·Its time-weighted balance is at least the eligibility floor: To be announced. The floor keeps distribution economical; it is not set to exclude holders.
• ·It holds $ZC at the epoch's closing block.

Burn addresses

0x0000…dEaD and the zero address. Burned coins are gone.

zipcoin privacy pool

The $ZC pool 0x6d0e…a422 and its Entrypoint 0x7a8D…9193. Zipped coins belong to notes, not addresses.

zipcoin spending contracts

ZipBroadcaster, ZipDoorstep, the Tellers and ZipHearth. They hold nothing between calls.

Liquidity and trading contracts

The Uniswap v4 PoolManager holding the pool's liquidity, the launch hook, and any router or pool contract holding $ZC for traders.

Treasury, team and prizes

The treasury, team wallets and prize deposits. zipcoin's @zipcoinbook already marks team wallets.

Exchange wallets

Centralised exchange deposit and hot wallets, where they can be identified from public labels.

Other shared custody

Any contract that holds $ZC on behalf of many users. A smart-contract wallet controlled by one holder is eligible.

The full list, with addresses, is published before each epoch opens.

shareᵢ      = Sᵢ ÷ Σ S
allocationᵢ = pool × shareᵢ

Per-address cap: 5%proposed of the pool. Shares above the cap are fixed at the cap and the excess is shared among the remaining addresses in proportion to their scores, repeating until none exceeds it. If every address is capped, the remainder carries into the next epoch's pool.

Eligible addresses are ordered by S, highest first. Equal scores share a rank. An address in rank r of N is in the top r ÷ N. Bands (top 1%, 5%, 10%, 25%, eligible) are labels on that percentile and play no part in allocation.

Buying just before close

Time-weighted balance counts only the time held, and new coins start at 1.00×.

Flash loans and same-block round trips

Zero time held, so zero contribution.

One very large address

Balance Weight grows with the square root above 1,000,000 zc, and the per-address cap holds any one address to 5% of a pool.

Splitting across addresses

No gain below the reference balance. Above it, the gain is at most √(B ÷ K), costs the holding age of every moved coin, and needs the eligibility floor in every address. A split position can at most recover its pro-rata share.

Cycling coins between own addresses

Moved coins restart at 1.00× in the receiving address. It can only lower a score.

Wash trading and volume

Volume is not an input. Each trade also pays the 1% swap fee.

Parking coins in pool contracts

Pool and custody contracts are excluded, and their depositors are not credited.

Splitting is limited, not prevented. Preventing it would need identity checks or wallet clustering, and this program uses neither. The ceiling matters more than the gap: the most a splitter can reach is roughly what a plain pro-rata system would have paid anyway.

• ·Inputs are limited to what Ethereum already makes public: $ZC balances and transfers. Nothing is added to them.
• ·No KYC, no sign-up, no email, no IP-based checks.
• ·No wallet clustering. Linking addresses by funding source, timing or behaviour is the same analysis zipcoin's privacy pool exists to defeat. Addresses are scored independently.
• ·Zipped coins are not counted. A note is designed so nobody can tell which address it belongs to. Crediting it would mean undoing that.
• ·Public results are aggregates by band. No balances, no exact scores and no full addresses are published by this site. Rankings list only addresses whose holders opt in.

Under consideration for later versions, not part of v0.1: a zero-knowledge proof that a zipped note has existed for a given time, so private holders could take part without revealing which deposit is theirs.

At each close, the following are published:

• ·The opening and closing block numbers.
• ·The exclusion list, with addresses.
• ·The methodology version and the scoring code.
• ·The total eligible Holder Score and the number of eligible addresses.
• ·A commitment to the full allocation set, such as a Merkle root.

Anyone can recompute every score from public chain data. The reference implementation ships with this site's source as src/lib/score.ts, with tests. In zipcoin's words about its own numbers: the chain is the receipt.

• ·Holding age belongs to an address. A holder who moves to a new wallet starts again.
• ·Using the privacy pool lowers a public balance. That is the honest trade for not tracing notes.
• ·Coins held on an exchange earn nothing, even when they belong to a long-term holder.
• ·Splitting above the reference balance is limited, not prevented.
• ·zipcoin's own contracts are unaudited, as its docs state. Holder Rewards adds no contract that holds user funds.