Regen Compute retirement tracker, read straight off regen-1

Do something with this

See the latest retirement
The most recent EventRetire from this wallet, straight off regen-1.
Open tx →
See the burns, the other half of the same wallet
REGEN bought and destroyed, tracked the same way, never added to this count.
Open burn tracker →
Retire through the same door yourself
The board's compute lane counts your own retirements the same way once they land on chain.
Open the Regen baseline →

What we found

Counted regen.ecocredit.v1.EventRetire events whose owner is regen13hdw80n5c9yueg4mgvap82v2dcsl8dq50j00dh, the master wallet named in Regen Compute's own accounting spec. 8 retirements across 3 credit batches: 4 paid subscriptions and 4 of the team's own labeled test runs. 6 came through a marketplace purchase with auto-retire and 2 through a direct retire message.

Why the typed event and not the message. message.action='/regen.ecocredit.v1.MsgRetire' AND message.sender=<wallet> returns only the direct retirements (2 of 8 on 2026-09-03); a MsgBuyDirect auto-retire emits EventRetire without a second top-level message.

Three sources agree: primary node https://rpc-regen.ecostake.com (retention floor 25,498,036) reports 8 transactions; secondary node http://public-rpc.regen.vitwit.com:26657 (floor 25,277,882) reports 8; the registry indexer reports 8. A node pruned past the earliest retirement answers a clean, wrong zero, so this page refuses to build unless every floor sits below height 25,800,000 and the three record sets match.

date	credits	batch	kind	reason (on-chain)	how	tx
2026-05-20	0.001	BT01-001-20210309-20231212-001	dev test	Verify abbreviation fix: was failing before c6236df→7957633	direct retire	ce9e4a876e…
2026-05-07	0.001	C02-004-20210102-20211207-001	dev test	Verify post-deploy: class_id + lowercase tx_hash	purchase, auto-retire	16b8c7df51…
2026-05-07	0.001	C02-004-20210102-20211207-001	dev test	Schema verification test for CROSSLUCID: Regen Compute integration discovery	purchase, auto-retire	9eb152da5b…
2026-03-12	0.046426	USS01-002-20230901-20241231-001	subscription	Regenerative Compute subscription: subscriber #5 (regen1wd0rsnftg4c7tf99pjhldymyd4dggmwmnj84sp)	purchase, auto-retire	1820cad9d8…
2026-03-12	0.009039	USS01-002-20230901-20241231-001	subscription	Regenerative Compute subscription: subscriber #3 (regen1vqrvsdn6usryjmg2qwyjzy55tdfky744c5wrnx)	purchase, auto-retire	fd7d48f2e5…
2026-03-12	0.009039	USS01-002-20230901-20241231-001	subscription	Regenerative Compute subscription: subscriber #3 (regen1vqrvsdn6usryjmg2qwyjzy55tdfky744c5wrnx)	purchase, auto-retire	727844c66c…
2026-03-12	0.009039	USS01-002-20230901-20241231-001	subscription	Regenerative Compute subscription: subscriber #3 (regen1vqrvsdn6usryjmg2qwyjzy55tdfky744c5wrnx)	purchase, auto-retire	6448c2ef2c…
2026-03-03	1	BT01-001-20210309-20231212-001	dev test	Test retirement - regen-compute MCP server validation	direct retire	20d2ef26f6…

Trend: stalled (quiet longer than its own worst historical gap)

Gaps between successive retirements, oldest pair first: 9d → 0h → 3h → 3h → 56d → 1h → 12d. The last one was 116 days ago (2026-05-20). Trailing 30 days: 0; trailing 90 days: 0, which is 0 a day. A lifetime average would smooth over a quiet quarter, so this page never states one.

Reconciling against the program's own figure

regen-compute ACCOUNTING-SPEC.md, section 6, Current Production Data Snapshot (as of 2026-03-14) states 19 retirements by 2026-03-14. On chain by that date: 5.

Why they differ. a count of rows in the program's subscriber_retirements billing table (execution attempts), not on-chain EventRetire events; the spec's own known-issues list documents zero-credit attempts among them. The two figures answer different questions (attempted vs settled on chain) and are not in conflict. This page states only the on-chain count.

Verify it yourself

Nothing here is asserted on our own authority. Every number is re-derivable from these public calls.

curl "https://rpc-regen.ecostake.com/tx_search?query=%22regen.ecocredit.v1.EventRetire.owner%3D'%5C%22regen13hdw80n5c9yueg4mgvap82v2dcsl8dq50j00dh%5C%22'%22&per_page=100"

curl -X POST https://api.regen.network/indexer/v1/graphql -H 'content-type: application/json' -d '{"query":"{ allRetirements(condition:{owner:\"regen13hdw80n5c9yueg4mgvap82v2dcsl8dq50j00dh\"}) { totalCount nodes { amount batchDenom jurisdiction owner reason timestamp blockHeight txHash } } }"}'