# \[Shutter DAO 0x36 Impact Pilot Program Round 1 - Proactive Grant\] PEN Ownership-Chain Verification and Deployment Runbook **URL:** \ **Category:** General\ **Created:** [September 28, 2026, 5:47pm UTC](https://shutternetwork.discourse.group/t/shutter-dao-0x36-impact-pilot-program-round-1-proactive-grant-pen-ownership-chain-verification-and-deployment-runbook/964 "2026-09-28T17:47:36Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Crezno](https://avatars.discourse-cdn.com/v4/letter/c/34f0e0/32.png) [@Crezno](https://shutternetwork.discourse.group/u/Crezno)\ **Post date:** [September 28, 2026, 5:47pm UTC](https://shutternetwork.discourse.group/t/shutter-dao-0x36-impact-pilot-program-round-1-proactive-grant-pen-ownership-chain-verification-and-deployment-runbook/964/1 "2026-09-28T17:47:36Z")
# PEN Ownership-Chain Verification and Deployment Runbook _Close the verification gap above the PEN treasury. Ship the tooling the README already promises._ ## 1. Application **Applicant name or organization:** Crezno — Independent Contributor **Primary contact / forum handle:** Crezno **Social Handle (X and/or LinkedIn):** X — [Crezno (@0xCrezno) / X](http://x.com/0xCrezno) **Github Profile:** [fcrezno · GitHub](https://github.com/fcrezno) **How did you hear about this grant program?** I replied to the program RFC in thread 940 on 31 August 2026, before the template existed. alexsotodigital then cc’d me on thread 952 on 28 September 2026. **Wallet address for payment (if approved):** `0x934C80e3a3e9136eE3558950385B66Ac5e7D9bf7` (Ethereum Mainnet) **Application type:** ☑ Round 1 — Proactive grant for defined future work **Round 1 objective:** ☑ Objective 6 — Advance Shutter PEN Adoption, Operations, and Funding Readiness **Contribution area:** ☑ Research or technical work☑ Operations or coordination * * * ## 2. The Shutter need or opportunity ### What specific need, opportunity, or gap does this contribution address? Two gaps in the live PEN deployment. I found both when I deployed PEN to Ethereum Mainnet, and neither is closed. **Gap 1 — the contract above the PEN treasury has no verified source on Etherscan.** `TimelockExecutionStrategyImplementation` (`0xf2A1C2f2098161af98b2Cc7E382AB7F3ba86Ebc4`) is the implementation behind the execution strategy that is now the only owner of the PEN treasury Safe (`0xB7f69C3cd9E3dFB4aE0Ed9ee65eb2Ed42EdeECE3`). Etherscan still shows the “Are you the contract creator?” banner for it today. Etherscan is the explorer that the DAO, most wallets, and most review tooling open first. **I correct my own earlier diagnosis here, because the record matters more than the story.** When I deployed PEN, I attempted this verification and it failed on a bytecode mismatch. I concluded that the original build settings were lost and sat only with Snapshot Labs. That conclusion was wrong. The contract is verified on Blockscout, and has been since 10 July 2024. The settings are public: | Setting | Value | | --- | --- | | Compiler | `v0.8.18+commit.87f61d96` | | Optimizer | enabled, 10,000 runs | | EVM version | `paris` | | Source path | `src/execution-strategies/timelocks/TimelockExecutionStrategy.sol` | My attempt failed because the pinned sx-evm submodule now builds with solc 0.8.27. I used the wrong compiler, not an unknowable one. **What that correction does not close.** The Blockscout entry is a partial match, not a full match. The source and the compiler are right, but the metadata does not reproduce exactly. So a straight recompile is not guaranteed to produce an exact Etherscan match. Closing this needs the correct sx-evm commit for the 8 January 2024 deployment, the pinned OpenZeppelin versions of that date, and a standard-json submission that reproduces the metadata. If that fails, it needs the Etherscan cross-chain similar-match route, or a written record of why neither route closes it. That is the work. It is a bounded engineering task with a real chance of a negative result, and I would rather state its true size than inflate it. **Gap 2 — the documented PEN verification tooling does not exist.** The deployment README, at Step 9, documents `script/VerifyPENSystem.s.sol` and `script/verify-pen.sh` in detail. Neither file is in the repository. So there is no supported way for the DAO, an auditor, or the next operator to read the live PEN state back from chain and confirm that it is correct. I verified the deployment by hand, one call at a time. That does not scale, and it leaves no artifact. ### Why is it relevant to Shutter now? PEN is live on mainnet and it holds a treasury. The DAO is about to use this program to fund more PEN work, and two Objective 6 applications are already open. All of that work sits on a deployment whose ownership chain ends at a contract with no verified source on Etherscan, and which has no reproducible way to check its own state. Objective 6 names this case directly: “an artifact resolving a defined PEN design, legal, capital-stewardship, or coordination blocker.” ### What specific demand signal supports this work now? - Shutter DAO 0x36 asked for the PEN mainnet deployment as a bounty, and asked for the redeployment after the first Space failed to index on Snapshot. - The artifacts pull request is public and merged: `shutter-network/shutter-pen-deployment-artifacts` PR #1, merged on 27 August 2026. The unverified implementation and the missing scripts are both recorded there. - Objective 6 of this program names PEN security, operational and capital-stewardship work as eligible. ### Who benefits from the outcome, and how? - **Shutter DAO 0x36 and PEN SEAT holders.** The ownership chain over the PEN treasury becomes readable end to end. - **Auditors and reviewers.** They get a verified contract, or a public record of exactly why it cannot be verified and what to do next. - **The next PEN operator.** They get a tested runbook and a working verification script, in place of documentation for files that are absent. - **SEEDGov and the DAO.** They can check a live PEN instance with one command before they approve a payment against it. ### Value pathway ☑ Durable ecosystem, adoption, or public-goods value aligned with Shutter’s mission ### Who is the relevant decision-maker, operating owner, funder, partner, or beneficiary group? - **Shutter DAO 0x36** — the operating owner. It holds the PEN treasury, and it decides what to accept if the Etherscan match cannot be reproduced. - **Snapshot Labs** — the fallback counterpart for Gap 1 only, and only if the reproduction fails. They maintain sx-evm and hold the build history for the January 2024 deployment. The contact path is the sx-evm repository and the Snapshot developer channels. I do not need them to start. - **The next PEN operator** — the beneficiary of Gap 2. Any person or team that the DAO funds to deploy, audit, or extend PEN. - **SEEDGov** — the operator of the public record for this program. ### What problem are they solving, and what evidence supports the value of addressing it? Shutter DAO 0x36 holds the PEN treasury. The control path over that treasury ends at a contract with no verified source on the explorer that reviewers open first. The cost is not theoretical. It blocks a clean external audit of PEN governance, and it blocks any institution that needs a readable control path before it puts capital into a SEAT. Gap 2 costs the DAO money directly. The DAO is funding more PEN work through this program. Every operator it funds will read a README that gives a run command for a verification script that does not exist, and will then verify by hand, as I did. ### What Shutter product, deployment, service, or capability would this contribution advance? Shutter PEN on Ethereum Mainnet. The specific parts are the treasury Safe, the timelock execution strategy, and the deployment and verification tooling in `shutter-network/perpetual-endowment-network`. ### What decision, implementation step, or next action should this contribution enable, and by when? By the delivery target in the week of 30 November 2026: 1. The DAO can state whether every contract in the PEN ownership chain carries a verified source on Etherscan, with evidence, and not as an assumption. 2. If the metadata cannot be reproduced, the DAO holds a written record of each route tested and a costed recommendation, and can decide. 3. Any person can deploy PEN, or audit a live PEN instance, from the runbook alone, and confirm the result with one command. ### What evidence will show progress beyond outreach, general interest, or a speculative concept? - A verified contract page on Etherscan, or a public reproduction record that names each commit, compiler, and dependency set tested and rejected. - A published verification status table for every address in the PEN ownership chain, with explorer links. - A public repository with `VerifyPENSystem.s.sol` and `verify-pen.sh`, and their output against the live mainnet deployment. - A pull request against `shutter-network/perpetual-endowment-network`. * * * ## Scope and deliverables ### Part A — Close the Etherscan verification gap in the PEN ownership chain 1. Reproduce the January 2024 build of `0xf2A1C2f2098161af98b2Cc7E382AB7F3ba86Ebc4` at the published settings: solc `v0.8.18+commit.87f61d96`, optimizer on at 10,000 runs, EVM version `paris`. Find the sx-evm commit and the OpenZeppelin versions of that date that reproduce the metadata, not only the runtime bytecode. 2. Submit the standard-json verification to Etherscan. 3. If the exact match fails, work the two remaining routes in order: the Etherscan cross-chain similar-match route from a sister deployment, then a direct request to Snapshot Labs for the build history. 4. Audit every address in the PEN ownership chain for Etherscan verification status, and publish the result as a table with links. The DAO can then cite one artifact instead of checking seven addresses by hand. 5. If no route closes the match, deliver instead: - a public reproduction record that names every commit, compiler, and dependency set tested, - a short advisory that states the risk to the PEN treasury in plain terms, - a costed recommendation, which includes the option to replace the execution strategy with a verified implementation. **This part carries a real risk of a negative result, and I state that here on purpose.** A partial match on one explorer is not a verified source on another. The result the DAO needs is a closed question with evidence. A documented and reproducible failure closes the question. An untested assumption does not. ### Part B — Build the missing verification tooling 1. Write `script/VerifyPENSystem.s.sol` and `script/verify-pen.sh`, the two files that the README already documents and the repository does not contain. The README specifies the behaviour across lines 284 to 298, including the run command, the `DEPLOYMENT_FILE` default, and the full check list. I build to that specification. 2. The script reads the live state back from chain and checks it: the Safe owners and threshold, the execution strategy as an enabled Safe module, `SeatToken.spaceLocked`, the Space authenticator set, the strategy quorum, the timelock delay, and the veto guardian. 3. Run it against the live mainnet deployment and publish the output. ### Part C — The deployment runbook 1. A tested and public runbook that takes a third party from zero to a verified PEN deployment, and lets an auditor check an existing one. 2. It corrects the five documentation errors that I found and recorded in PR #1. Two of them produce a silently wrong deployment in place of a failure: - The `Decimals` field in the `OZ Votes` strategy dialog defaults to 18, but `SeatToken` is `decimals = 0`. At the default, every seat balance renders as `0.000000000000000001`. - `VOTING_DELAY`, `MIN_VOTING_DURATION` and `MAX_VOTING_DURATION` changed from seconds to blocks. An operator who reuses an older `.env` deploys a Space with voting windows twelve times too long. 3. Submit it as a pull request to `shutter-network/perpetual-endowment-network`. ### Reviewable milestone for the second 50% Part A and Part B complete and public: - the Etherscan verification, or the reproduction record with the advisory and the costed options, plus the verification status table for the whole ownership chain, - the two scripts in a public repository, with their output against the live mainnet deployment. The DAO can read the milestone and judge the work before it releases the second payment. Part C follows. ### Out of scope No new PEN deployment. No change to PEN governance parameters. No transaction that moves PEN treasury funds. No custody of any key that belongs to the DAO. * * * ## 3. Funding request **Amount requested: $2,000** **Payment structure:** 50% after DAO approval and award. 50% after the milestone review. **Proposed use of funds:** | Work | Share | | --- | --- | | Part A — metadata reproduction across commits and dependency sets, Etherscan submission, cross-chain route, ownership-chain verification audit, written record | $800 | | Part B — verification script and shell wrapper, built to the README specification, tested against mainnet | $700 | | Part C — runbook, five documentation corrections, pull request | $500 | This figure is below the middle of the stated $1,000 to $3,000 band, and it covers three deliverables. I set it there on purpose. The deployment already exists, the findings already exist, and I do not need to rebuild either. The DAO pays for the work that closes them. On Part A specifically: the compiler settings are public, so I am not charging the DAO to discover them. I am charging for the reproduction work that a partial match leaves open, for the routes to try if it fails, and for the ownership-chain audit that turns a one-contract question into a standing artifact. No paid media. No hardware. No third-party purchases. No upfront spend. Gas costs apply to read-only calls only, and I cover them. * * * ## 4. Prior compensation and disclosures **Have you, your organization, or a related party received or requested compensation for this work from Shutter or another source?** ☑ Yes **Source and amount.** Shutter DAO 0x36 paid me a bounty of 0.001 ETH plus $250 SHU. I claimed it on 26 August 2026. **What that bounty compensated.** Running the documented deployment flow to Ethereum Mainnet, publishing the broadcast artifacts, and opening the artifacts pull request. That is the PEN mainnet deployment, in full. `shutter-network/shutter-pen-deployment-artifacts` PR #1 was merged on 27 August 2026. **The relationship to this application.** This application is future work. None of it was delivered under the bounty, and none of it is a second payment for the deployment: - The unverified implementation is a finding from that work. To resolve it is a separate task, and no bounty covered it. - `VerifyPENSystem.s.sol` and `verify-pen.sh` do not exist. To write them is new work. - The runbook does not exist. The five documentation errors are recorded in the merged pull request as findings. To correct the documentation and to publish a tested runbook is separate work. **One further disclosure, in good faith.** I also intend to apply in Round 2, the retroactive round, for work that is already finished and that the bounty did not cover: the second deployment and the diagnosis that made it necessary, and the verification of the end state on chain. That is past work and a separate scope. I raise it here so that the DAO sees both, and so that no part of it is read into this request. If the DAO prefers to assess the two together, I accept that. **Do you have any financial, professional, or organizational conflict relevant to this application?** ☑ No I am applying as an independent contributor. I hold no role with Axia Network, SEEDGov, Snapshot Labs, or Shutter. * * * ## 5. Public discussion **Forum post link:** This thread. **Questions or feedback requested from the community:** 1. If the exact metadata match cannot be reproduced, would the DAO accept an Etherscan cross-chain similar-match verification as a sufficient outcome, or does it want an exact match only? 2. If neither route closes it, does the DAO want a costed plan to replace the execution strategy with a verified implementation, or a documented acceptance of the risk? 3. Should the runbook and the scripts land in `shutter-network/perpetual-endowment-network`, or in the artifacts repository next to PR #1? * * * ## 6. Applicant attestation I confirm that the information in this application is accurate to the best of my knowledge, that I have disclosed relevant prior compensation and conflicts, and that I understand that any award remains subject to the published process and DAO approval. **Name / handle:** Crezno **Date:** September 28, 2026 cc @SEEDGov @Rika_AxiaNetwork ---
**Author:** ![SEEDGov](https://dub1.discourse-cdn.com/flex017/user_avatar/shutternetwork.discourse.group/seedgov/32/546_2.png) [@SEEDGov](https://shutternetwork.discourse.group/u/SEEDGov)\ **Post date:** [September 29, 2026, 12:48pm UTC](https://shutternetwork.discourse.group/t/shutter-dao-0x36-impact-pilot-program-round-1-proactive-grant-pen-ownership-chain-verification-and-deployment-runbook/964/2 "2026-09-29T12:48:54Z")
Hi Crezno! Thanks for the application. Given that Part A asks to fund an exact match for `TimelockExecutionStrategy` at `0xf2A1C2f2098161af98b2Cc7E382AB7F3ba86Ebc4` and that Etherscan now shows Source Code Verified (Exact Match) it is considered past work rather than a Round 1 deliverable. A suggestion in order to formalize the application would be: - Move the delivered Part A into your Round 2 retroactive application, separate from this request. - Revise this Round 1 application to Parts B and C only, and cut the ask to 1,200$ - Point the second 50% milestone at those two parts, since Part A would no longer be in this round. ---
**Author:** ![Crezno](https://avatars.discourse-cdn.com/v4/letter/c/34f0e0/32.png) [@Crezno](https://shutternetwork.discourse.group/u/Crezno)\ **Post date:** [September 29, 2026, 12:59pm UTC](https://shutternetwork.discourse.group/t/shutter-dao-0x36-impact-pilot-program-round-1-proactive-grant-pen-ownership-chain-verification-and-deployment-runbook/964/3 "2026-09-29T12:59:01Z")
Agreed on all three points, and thank you for the quick turnaround. Revising as suggested. ## Part A moves to Round 2 The `TimelockExecutionStrategy` exact-match verification at `0xf2A1C2f2098161af98b2Cc7E382AB7F3ba86Ebc4` comes out of this application entirely. I will submit it as a retroactive item in Round 2, on its own evidence, separate from this request. It is not billed in both rounds. For the record on what it actually took, since I would rather state it plainly than let it look larger than it was: the only thing that had to be recovered was the compiler version. The submodule pinned in the PEN deploy repo sets `solc = "0.8.27"`, while the January 2024 deployment used `0.8.18`. The other settings — `via_ir`, `bytecode_hash = "none"`, `optimizer_runs = 10_000` — are declared in sx-evm’s own `foundry.toml` and always were. Pulling the original `compiler_settings` object from Blockscout and feeding it verbatim into a standard-json input is what made it quick rather than a version bisect. Result was deterministic: 14,252 hex characters, identical to `cast code` at every position, zero warnings. Etherscan returned Pass - Verified on the first check. > **[Contract Name - Address: 0xf2A1C2f2...3ba86Ebc4 | Etherscan](https://etherscan.io/address/0xf2A1C2f2098161af98b2Cc7E382AB7F3ba86Ebc4#code)** > > 1 Internal Transaction found. | Contract: Verified | Balance: $0 across 0 Chain | Transactions: 0 | As at Sep-29-2026 12:57:49 PM (UTC) ## Revised scope — Parts B and C only **Part B — build the missing verification tooling** 1. Write `script/VerifyPENSystem.s.sol` and `script/verify-pen.sh`. Both are documented in the PEN README across lines 284 to 298, including the run command and the `DEPLOYMENT_FILE` default, and neither exists in `shutter-network/perpetual-endowment-network`. I build to that written specification. 2. The script reads live state back from chain and checks it: Safe owners and threshold, the execution strategy as an enabled Safe module, `SeatToken.spaceLocked`, the Space authenticator set, the strategy quorum, the timelock delay, and the veto guardian. 3. Run it against the live mainnet deployment and publish the output. **Part C — the deployment runbook** 1. A tested, public runbook that takes a third party from zero to a verified PEN deployment, and lets an auditor check an existing one. 2. It corrects the five documentation errors recorded in the merged artifacts pull request. Two of them produce a silently wrong deployment rather than a failure: the `Decimals` field in the `OZ Votes` strategy dialog defaults to 18 while `SeatToken` is `decimals = 0`, and `VOTING_DELAY` / `MIN_VOTING_DURATION` / `MAX_VOTING_DURATION` changed from seconds to blocks, so a reused `.env` produces voting windows twelve times too long. 3. Submit it as a pull request to `shutter-network/perpetual-endowment-network`. ## Revised milestone for the second 50% Pointed at both parts, as suggested. The DAO reviews all of the following before the second payment: - **Part B** — the two scripts in a public repository, with their output against the live mainnet deployment, so anyone can re-run the check rather than take my word for it. - **Part C** — the runbook published, and the pull request opened against the PEN repository. Nothing in this round now depends on Part A. ## Revised funding request **Amount requested: $1,200** | Work | Share | | --- | --- | | Part B — verification script and shell wrapper, built to the README specification, tested against mainnet | $700 | | Part C — runbook, five documentation corrections, pull request | $500 | Payment structure unchanged: 50% after DAO approval and award, 50% after the milestone review. No paid media, no hardware, no third-party purchases, no upfront spend. Everything in section 4 of the original application stands, including the bounty disclosure. ## One open question Should the scripts and the runbook land in `shutter-network/perpetual-endowment-network`, or in the artifacts repository next to the merged PR? I will follow whichever the maintainers prefer. The full reproduction record for the verification — standard-json input, scripts, and the 8-of-8 ownership-chain audit table — is written up and ready. Happy to post it in the Round 2 application, or here, or wherever is most useful.