Public verification artifacts for a 1,000,000,000 GLC treasury timelock:
200 tranches of 5,000,000 GLC, one released per year for 200 years, enforced
on-chain by OP_CHECKLOCKTIMEVERIFY (BIP65).
Funding transaction:
e45539ddb23ee3e760afa62f95567a07a29c2a81e72efd6a0c0c9c5c48867db2
Tranche i is output i of that transaction (i = 0..199). Output 200 is change and is not part of the timelock.
| Total locked | 1,000,000,000 GLC |
| Tranches | 200 × 5,000,000 GLC |
| Interval | 237,380 blocks (≈1 calendar year) |
| First unlock | block 2,814,042 |
| Last unlock | block 50,052,662 |
| Destination | E6XZFm98fprabjTKoD27WW474RBCLshjiK |
Each tranche is a P2SH output whose redeem script is:
<unlock_height> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <hash160> OP_EQUALVERIFY OP_CHECKSIG
Spending requires both the private key for the destination address and a
transaction whose nLockTime is at or past the tranche's unlock height, with a
non-final nSequence. Consensus rejects an early spend outright — this was
verified on mainnet before the treasury was committed.
Every tranche can be checked against the chain with no trust in this repo:
# confirm a tranche exists, is unspent, and holds 5,000,000 GLC
goldcoin-cli gettxout e45539ddb23ee3e760afa62f95567a07a29c2a81e72efd6a0c0c9c5c48867db2 0
# confirm the redeem script decodes to the expected height and P2SH address
goldcoin-cli decodescript 035af02ab17576a9148b6edf99e720e2b287737fb97b55c6b20bf5c0cb88ac
A P2SH address is the hash of its redeem script, so if the address in
schedule_review.json matches the address holding the coins on-chain, the
script is proven correct.
Regenerate the entire schedule from scratch and confirm it matches
(byte-identical, sha256 d98091e651b260e98647579eac9ec68832a35fd6295e099697908475a646b525):
python3 generate_schedule.py \
--destination-address E6XZFm98fprabjTKoD27WW474RBCLshjiK \
--tranches 200 --amount-per-tranche 5000000 \
--start-height 2814042 --interval 237380 \
--out check.json
| File | Purpose |
|---|---|
schedule_review.json | All 200 tranches: unlock height, amount, P2SH address, redeem script |
parameter_card.txt | The values needed to rebuild the schedule if the JSON is lost |
generate_schedule.py | Deterministic schedule generator |
timelock_lib.py | Script/address/serialization primitives used by the generator |
RUNBOOK.md | Operational procedure, including backup and recovery |
Goldcoin targets 120 s per block, but the measured rate over the year to 2026-08-19 was 132.94 s (30-day: 132.52 s, 90-day: 133.34 s), giving 237,380 blocks per calendar year. The schedule uses the measured figure, not the target.
Block spacing has trended downward for years (165 s in 2019 → 132 s in 2026) as hashrate has grown toward the target. No fixed block interval can track calendar years indefinitely; later tranches will drift relative to wall-clock dates.
This repository contains no key material. The redeem scripts and addresses are public by design — they reveal the lock schedule but confer no ability to spend.
1 commits
Python
100.0%
Public verification artifacts for a 1,000,000,000 GLC treasury timelock:
200 tranches of 5,000,000 GLC, one released per year for 200 years, enforced
on-chain by OP_CHECKLOCKTIMEVERIFY (BIP65).
Funding transaction:
e45539ddb23ee3e760afa62f95567a07a29c2a81e72efd6a0c0c9c5c48867db2
Tranche i is output i of that transaction (i = 0..199). Output 200 is change and is not part of the timelock.
| Total locked | 1,000,000,000 GLC |
| Tranches | 200 × 5,000,000 GLC |
| Interval | 237,380 blocks (≈1 calendar year) |
| First unlock | block 2,814,042 |
| Last unlock | block 50,052,662 |
| Destination | E6XZFm98fprabjTKoD27WW474RBCLshjiK |
Each tranche is a P2SH output whose redeem script is:
<unlock_height> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <hash160> OP_EQUALVERIFY OP_CHECKSIG
Spending requires both the private key for the destination address and a
transaction whose nLockTime is at or past the tranche's unlock height, with a
non-final nSequence. Consensus rejects an early spend outright — this was
verified on mainnet before the treasury was committed.
Every tranche can be checked against the chain with no trust in this repo:
# confirm a tranche exists, is unspent, and holds 5,000,000 GLC
goldcoin-cli gettxout e45539ddb23ee3e760afa62f95567a07a29c2a81e72efd6a0c0c9c5c48867db2 0
# confirm the redeem script decodes to the expected height and P2SH address
goldcoin-cli decodescript 035af02ab17576a9148b6edf99e720e2b287737fb97b55c6b20bf5c0cb88ac
A P2SH address is the hash of its redeem script, so if the address in
schedule_review.json matches the address holding the coins on-chain, the
script is proven correct.
Regenerate the entire schedule from scratch and confirm it matches
(byte-identical, sha256 d98091e651b260e98647579eac9ec68832a35fd6295e099697908475a646b525):
python3 generate_schedule.py \
--destination-address E6XZFm98fprabjTKoD27WW474RBCLshjiK \
--tranches 200 --amount-per-tranche 5000000 \
--start-height 2814042 --interval 237380 \
--out check.json
| File | Purpose |
|---|---|
schedule_review.json | All 200 tranches: unlock height, amount, P2SH address, redeem script |
parameter_card.txt | The values needed to rebuild the schedule if the JSON is lost |
generate_schedule.py | Deterministic schedule generator |
timelock_lib.py | Script/address/serialization primitives used by the generator |
RUNBOOK.md | Operational procedure, including backup and recovery |
Goldcoin targets 120 s per block, but the measured rate over the year to 2026-08-19 was 132.94 s (30-day: 132.52 s, 90-day: 133.34 s), giving 237,380 blocks per calendar year. The schedule uses the measured figure, not the target.
Block spacing has trended downward for years (165 s in 2019 → 132 s in 2026) as hashrate has grown toward the target. No fixed block interval can track calendar years indefinitely; later tranches will drift relative to wall-clock dates.
This repository contains no key material. The redeem scripts and addresses are public by design — they reveal the lock schedule but confer no ability to spend.
1 commits
Python
100.0%