The Ikigai Reimbursement — verifying “same proposer” purely on-chain

The original Info Action 「Cardanoの生きがい - Ikigai -」 was submitted on 2024-09-18 in this transaction. Inside a Cardano transaction body, field 20 is `proposal_procedures` — it records, on-chain and immutably: the 100,000 ADA deposit, the governance action type ([6] = Info), the metadata anchor, and crucially the REWARD ACCOUNT the deposit should return to when the action ends. Decoding it gives reward account hex e12058a6f9…23, which is the bech32 stake address below. Note also that the submitting wallet's own address carries the very same stake part — the proposer used their own wallet's stake key as the return account.

🔍 How to check yourself: How to check yourself: open the tx on AdaStat / Cardanoscan / cexplorer and look at the governance-action (proposal) section; or fetch the raw CBOR and decode field 20 against the Conway CDDL — this is exactly what @Quantumplation demonstrated on X. With cardano-db-sync: SELECT sa.view FROM gov_action_proposal gap JOIN stake_address sa ON sa.id = gap.return_address WHERE …;

Ledger rule: when a governance action ends, the deposit is returned to the specified reward account — but only if that account is REGISTERED. A bug in the cardano-node at the time allowed the action to be submitted with an UNREGISTERED stake key in the first place. The action expired at epoch 517 (Oct 2024) while the return account was still unregistered, so the 100,000 ADA could not be paid out and was swept into the treasury instead. On-chain you can verify the address had zero registration certificates before 2026: its first and only stake registration in history is dated 2026-04-20 (step 4).

🔍 How to check yourself: db-sync: SELECT count(*) FROM stake_registration sr JOIN stake_address sa ON sa.id=sr.addr_id WHERE sa.view='stake1uys93…' — returns exactly 1 row, dated 2026-04-20. Explorers show the same under the stake address's certificate history.

The Treasury Withdrawal action #126 (submitted 2026-06-09) also carries a `proposal_procedures` in field 20 of its transaction — and its withdrawal map directs 103,000 ADA to reward account e12058a6f9…23: byte-for-byte the SAME account the original 2024 action named as its deposit-return address. This is the single most important fact. A withdrawal into a reward account can only ever be spent by a WITHDRAWAL SIGNED WITH THAT STAKE KEY. So even in the worst case — even if the person who submitted #126 were a total stranger — the 103,000 ADA can only be claimed by whoever holds the original 2024 stake key. The design makes the identity question almost moot: the money is cryptographically locked to the original proposer.

🔍 How to check yourself: db-sync: SELECT sa.view, tw.amount FROM treasury_withdrawal tw JOIN stake_address sa ON sa.id=tw.stake_address_id WHERE tw.gov_action_proposal_id=<#126>; — or open the action on AdaStat / GovTool and compare the withdrawal address with step 1's address character by character.

On 2026-04-20 (epoch 626) — before #126 was submitted — a transaction registered stake1uys93… for the first time in its history (2 ADA deposit). Two details make this strong evidence of continued control: (a) the registration means the withdrawn funds CAN now actually land in the account (fixing the very failure mode that lost the deposit in 2024), and (b) the transaction's change output goes back to addr1q9fn0s96… — exactly the wallet address that submitted the original 2024 action. Spending from that address requires its payment key, so the original wallet was demonstrably alive and acting in April 2026. One honest caveat raised by @Quantumplation: before the v11 hard fork, a legacy registration certificate did not strictly require the stake key's own signature, so registration ALONE would not be conclusive — but combined with the change going to the original wallet, and with step 3 (funds only spendable by the original key anyway), the picture is coherent.

🔍 How to check yourself: Open the registration tx on any explorer: check the certificate (stake registration for stake1uys93…) and the output addresses. db-sync: SELECT … FROM stake_registration JOIN tx …; then SELECT address FROM tx_out WHERE tx_id = <that tx>.

DRep Nimuë (@nimuepool) — who verified the address match and the registration, but voted NO over the extra 3,000 ADA — noted that the cleanest possible proof would have been to add the original stake key as a REQUIRED SIGNER on the withdrawal action's transaction itself. That would have cryptographically demonstrated, at the moment of submission, both (a) current control of the key and (b) the key holder's consent to the reimbursement. A CIP-8 signed message from the original key would serve similarly. Neither was done here — the community instead relied on the payment-target binding (step 3), which protects the funds but does not by itself prove the SUBMITTER is the original proposer.