{"@context":{"CIP100":"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#","hashAlgorithm":"CIP100:hashAlgorithm","body":{"@id":"CIP100:body","@context":{"comment":"CIP100:comment"}}},"hashAlgorithm":"blake2b-256","body":{"comment":"# Withdraw 11,787,063 ada for the OpenZeppelin Stack administered by Intersect — Voting Rationale\n\n| Governance Voting Rationale |  |\n| :---- | :---- |\n| GAID | gov\\_action1gxxltxr02p28a398p8c6t08xhpg82wkkv9xgwvuxkly48lhgf20sqlkl2l8 |\n| Title | Withdraw 11,787,063 ada for the OpenZeppelin Stack administered by Intersect |\n| Type of GA | Treasury Withdrawal |\n| Amount | ₳11,787,063 (₳11,443,750 delivery, stated as USD 1,831,000 at a reference rate of USD 0.16 · ₳343,313 Intersect administration fee) |\n| Date submitted | 8 September 2026 (epoch 654\\) |\n| Expiration Date | 11 October 2026 (end of epoch 660\\) |\n\n---\n\n# Contents\n\n* 1.0 Introduction  \n  * 1.1 Summary  \n  * 1.2 Description of Governance Action  \n* 2.0 Discussion  \n  * 2.1 Method  \n  * 2.2 What this proposal gets right, stated properly  \n  * 2.3 A price agreed before the thing priced  \n  * 2.4 The gap is real, and it is not empty  \n  * 2.5 The part that forks and the part that is bought  \n  * 2.6 Who checks the checker  \n  * 2.7 A blueprint is a default  \n  * 2.8 The reference rate, the buffer and the ceiling  \n  * 2.9 What the commons retains  \n  * 2.10 Why this is a No and not an abstention  \n  * 2.11 Fiduciary verification (external instrument)  \n  * 2.12 What would make this a Yes  \n  * 2.13 What the vote does not reach  \n* 3.0 Conclusion  \n* Sources\n\n---\n\n# 1.0 Introduction\n\n## 1.1 Summary\n\nWe are voting NO (remediable) on the OpenZeppelin Stack, and I want the shape of that No to be legible, because it is not the No that the loudest objections to this proposal would predict.  \nIt is not a No on price. Read in the currency the work is contracted in, USD 1.83 million for twelve months of library engineering, three reference protocols, developer tooling and twenty-two researcher-weeks of security capacity is not an inflated number; if anything the breadth promised is wide for the money. It is not a No to an outside firm arriving with a treasury ask, either. A commons that funds only its incumbents has quietly stopped being one, and this DRep's method exists in part to stop a sector label or a recipient's origin from doing work that only the structure of a claim should do. And it is not a No to the problem, which is real and which Cardano's own engineering organisations describe in much the same terms the proposal uses.  \nThe No rests on three findings, each a property of this action rather than of the people behind it. First, the price is fixed while the thing priced is not: the smart contract language is to be chosen after the vote, the component list is described as preliminary and indicative, no team is named, and the budget is a payment schedule of five equal instalments rather than a statement of costs. The discretion over what the treasury receives is disclosed, and it is not bounded. Second, what the commons would retain is the code, under a permissive licence, and that is genuinely to the proposal's credit — but the stewardship of that code, its maintenance past month twelve, its canonical home and the name that gives it its institutional value all stay with the vendor, and the continuation is pre-figured as a second ask. The part that forks is not the part being bought. Third, the assurance that makes an audited library worth more than an unaudited one runs through the party being paid to build it: the security work is the author auditing the author, the final milestone's audit reports fall outside the last payment gate, and the acceptance criteria measure whether code compiles and is covered rather than whether anyone independent has found it sound.  \nThe external fiduciary instrument this DRep uses for the capital-allocation axis reaches No on the same structure from an unrelated foundation — budget clarity, continuity, independent verification and upfront exposure at a size where none of those is survivable. Two instruments built on different ground arriving at the same verdict is worth naming as what it is.  \nNone of the three findings needs a different team or a different ambition. Each names its own repair, and the proposal's own text commits to returning with a revised submission if this one does not pass. That commitment is the right one, and this rationale is written to be useful to it.\n\n## 1.2 Description of Governance Action\n\nThis Treasury Withdrawal requests ₳11,787,063 to fund a twelve-month engagement by OpenZeppelin, administered by Intersect, with Cardano Development Holdings as the contracting counterparty. The proposal states that it is not sponsored or endorsed by Intersect, which is prepared to act as administrator should it pass, and that this is OpenZeppelin's first request to the Cardano Treasury, with no Project Catalyst funding received.  \nThe work is presented as three coupled workstreams. The first is three end-to-end reference implementations — a liquid staking protocol issuing a transferable yield-bearing token for staked ada, a self-repaying loans protocol, and a tokenized money market fund — each with working code, architecture documentation, a demonstration front end and a threat model. The second is a contracts library for Cardano in the role OpenZeppelin Contracts plays for Solidity, with a preliminary component list running from access control, cryptographic utilities and DeFi mathematics through vaults, timelocks, staking and delegation utilities, governance, credentials and claims, account abstraction and multi-signature, vesting, a standardised messaging gateway and a proposed Cardano Contract ABI, together with a Contracts Wizard, a UI builder, AI-assisted development tools and documentation. The third is a security retainer of twenty-two researcher-weeks covering audits of the library and full-stack reviews and penetration tests of each reference implementation, scoped to OpenZeppelin-produced code, with findings published and with OpenZeppelin funding bug-bounty payouts at the levels of its standard program. A developer enablement and co-marketing program is described as included at no additional cost. Library code is to be released under the MIT licence and OpenZeppelin tooling under AGPL 3.0.  \nThe delivery budget is USD 1,831,000. The on-chain request converts that at a reference rate of USD 0.16 per ada to ₳11,443,750 and adds a three per cent administration fee of ₳343,313; the arithmetic is correct to the ada. On enactment the delivery portion is to be converted to a USD-denominated stablecoin at contract signature. Twenty per cent, USD 366,200, is released as a kick-off payment on signature, subject only to legal sign-off, and the remaining eighty per cent in four equal quarterly payments, each released after OpenZeppelin submits a milestone acceptance form with public evidence and Intersect's delivery assurance verifies it. Funds remaining in the contract at expiry sweep back to the treasury. Custody runs through the Sundae Labs treasury contract framework, with a six-entity oversight committee and multi-party authorisation for funding, disbursement, pause and sweep, and the funds are held undelegated to a stake pool and delegated to the predefined abstain option as the Constitution requires.  \nThe proposal states compliance with the 500 million ada Net Change Limit covering epochs 613 to 713\\. On the public count available during the voting window, roughly ₳457.4 million of that limit was already committed, leaving about ₳42.6 million of headroom for the nine months remaining in the period; this request is a little over a quarter of that remainder.  \n---\n\n# 2.0 Discussion\n\n## 2.1 Method\n\nThis action earns a deep reading, and on grounds that are easy to mistake, so they are stated plainly. It is not the size of the ask, and it is not that the proposer comes from outside the ecosystem. A twelve-month engagement that sunsets and returns unspent funds changes nothing structural on its face. What deepens the reading is what happens if the work succeeds. A standard library is a dependency by design: it is valuable exactly to the extent that many independent builders import it and stop writing their own. A dependency of that kind is easy to decline today and progressively harder to decline at each renewal, without any further decision being taken, and when this DRep read a maintenance grant for an existing wallet earlier this year the distinction that mattered was whether the action serviced a dependency the ecosystem already had or manufactured a new one. This action would manufacture one. That is not an argument against it — shared infrastructure is supposed to be depended on — but it is the reason the terms on which the dependency is created deserve to be read before it exists rather than after.\n\n## 2.2 What this proposal gets right, stated properly\n\nA finding is worth less if the affirmation around it is grudging, so this section is written at the length the criticisms get.  \nThe problem is correctly identified. Cardano does not have a standardised, audited contracts library that a builder can import with confidence, and the cost of that absence is paid in exactly the way the proposal says: each team rebuilds foundational components, audit effort is spent repeatedly on the same primitives, and an institution evaluating the chain has nothing canonical to evaluate. Input Output's own repository for a reusable contracts library opens by observing that the EVM ecosystem matured in part because OpenZeppelin gave it reusable contracts and that Cardano lacks an equivalent. The diagnosis is shared by the people best placed to dispute it.  \nThe financial construction is better than most of what crosses this desk, and better than the general critique of treasury procurement would lead a reader to expect. The contract is denominated in dollars, so the vendor carries no incentive to pad for volatility in the price of the work. Conversion happens once, at signature, rather than leaving a year of milestone payments exposed to the ada price. Four of the five payments are gated on public evidence verified by a party other than the vendor. What is left in the contract at expiry returns to the treasury automatically, at the contract level, rather than at anyone's discretion. Custody is on-chain, multi-party and auditable by anyone. That is a design by people who expect to be checked.  \nThe public-asset commitment is real. Library code under the MIT licence is as unencumbered as code gets; security findings and audit reports are to be published alongside releases rather than held; and OpenZeppelin commits its own funds to bug-bounty payouts at the level of its standard program, which is a genuine sharing of risk and one of the few places in any recent proposal where a vendor puts its own money beside the treasury's. The disclosures are clean: a first-time recipient that says so, an administrator that is explicit about not sponsoring the ask, and a statement that a failed vote will be followed by engagement on the concerns raised and a revised submission. That last sentence is the posture of a counterparty that expects correction, and it is the reason this rationale ends in a specification rather than a refusal.  \nAnd the capability is not in doubt. OpenZeppelin has carried a contracts library into several ecosystems that are not the EVM, and the claim that its presence makes a chain easier for institutions to evaluate is true as a description of how those institutions behave.\n\n## 2.3 A price agreed before the thing priced\n\nThe first finding is about order, and it is the one that makes this a No rather than a Yes with reservations.  \nThe proposal says that the specific smart contract language targeted will be determined during the initial evaluation phase, in collaboration with ecosystem stakeholders. That evaluation phase sits inside the first milestone, after the vote, after the contract is signed, and after the kick-off payment has been released. The choice is not a detail. Whether a Cardano library is written for Aiken, for Plinth, or for something else decides who can be hired to write it, what toolchain it is tested against, which existing codebases it can absorb or must duplicate, who in the ecosystem can review and later maintain it, and how much of the ecosystem will ever import it. It is also, on Cardano, a decision with a constituency: most application code written in the last two years sits on one side of that choice. A standard library whose language is unknown is not yet a specified deliverable, and delegated stake is being asked to fix its price.  \nThe same openness runs through the rest of the scope. The component list is described in the proposal's own words as preliminary and indicative. Additional standards are to be determined with ecosystem stakeholders. The reference implementations can include institutional patterns such as credential-based access and multi-signature controls. Penetration testing applies where applicable. The architecture documents that anchor the first milestone are to be reviewed by pre-agreed counterparties who are not named. None of this is unusual language for a statement of work between two firms, where a contracting officer on the buyer's side holds the pen. Here the buyer is a treasury, and the pen is held after the vote by the vendor and by stakeholders the proposal does not identify.  \nAgainst that, the budget offers no purchase at all. The Constitution asks a treasury withdrawal to state the relevant costs and expenses of the proposed activities. What this proposal provides is a payment schedule: five instalments of exactly twenty per cent each, identical whether the quarter contains a design phase or two audited protocols and a developer toolchain, with the columns for security and developer enablement reading \"included.\" There are no roles, no head-count, no rates, no allocation between the three workstreams, and no named delivery team with eUTXO experience. A reader cannot tell what share of the dollar figure buys security capacity and what share buys engineering, and so cannot tell what would be lost if any one component were cut or what should be saved if the language choice made a third of the list unnecessary.  \nStated in this DRep's own terms: the discretion over what the commons receives for a fixed sum is real, it is disclosed, and it is not limited. Disclosing an open discretion answers the question of whether it is known and leaves untouched the question of whether it is bounded. The repair is the one the failure names — scope the discretion — and it is available in either of two forms. Fix the language, the component list, the reviewing counterparties and the cost allocation before the vote. Or, if the evaluation genuinely has to come first, ask for the evaluation: a small first action that funds the language decision, the overlap analysis described in the next section and the architecture documents, and returns with a priced specification. The proposal's own milestone structure already isolates that work. What it does not do is isolate the commitment.\n\n## 2.4 The gap is real, and it is not empty\n\nThe proposal's problem statement says there is no standardised, audited contract library and that audited code is scattered across Cardano Foundation repositories, Intersect resources and individual project codebases. The first half of that sentence is true. The second half is the place where an inventory should be, and is not.  \nThe space is occupied, unevenly and incompletely, by work this proposal neither names nor positions itself against. Input Output maintains a public contracts library with an Aiken on-chain layer and off-chain builders, early in its life — a vesting contract in progress and a longer list triaged — and explicitly aimed at the role this proposal claims. Design-pattern libraries for both Plutarch and Aiken were built by Anastasia Labs with community funding, and an Aiken open-source contract library by MeshJS and TrustLevel was funded the same way. The programmable-token standard that the proposal lists as a library component and as a milestone-four contribution was merged into the CIP repository while this action was live, with reference work around it already underway in the ecosystem. None of these is the finished, audited, canonical thing. All of them are the material that a consolidation would have to consolidate.  \nThis matters to the proposal's own argument more than to any objection about duplication. The value claimed is consolidation — trusted, consolidated building blocks in place of fragments. A new library that arrives without stating what it absorbs, what it supersedes, what it leaves alone and whose maintainers it has spoken to is, on its face, one more fragment with a better-known name. It may well be intended otherwise; the proposal says OpenZeppelin will collaborate with Input Output, the Cardano Foundation, Intersect and other stakeholders. But a commitment to collaborate after the vote is not an account of the landscape before it, and the people asked to decide were given a problem statement in which the existing work appears only as scatter.  \nI want to be precise about what this finding is not. It is not a claim that the native efforts are sufficient, and it is not a claim that the treasury should prefer them because they are native. It is that the decision is being taken against an incomplete picture, by an electorate with limited time, and that the picture is cheap to complete. A public gap-and-overlap analysis, written with the maintainers of the existing work rather than about them, converts the central uncertainty of this proposal into its strongest section.\n\n## 2.5 The part that forks and the part that is bought\n\nAn open-source licence answers one question about a public asset — may anyone copy and change it — and it answers it here in the commons' favor. It does not answer who maintains the asset, where its canonical copy lives, who decides what is merged, or what the name on it is worth. For this proposal those are the questions that carry the value.  \nConsider what an institution is buying when it treats an OpenZeppelin library as a reason to build. It is not buying the source code, which it could read under any name. It is buying the assurance that a firm with a decade of reputation stands behind that code today: that it was audited by that firm, is maintained by that firm, and will be patched by that firm when the ledger changes underneath it. The proposal is candid that this is the point — production-ready paths with the enterprise-grade security patterns institutions require. That assurance is a relationship with OpenZeppelin, and a relationship cannot be forked. If the engagement ends, anyone may copy the repository, and what they will hold is a library that used to be maintained by OpenZeppelin.  \nSo the question the proposal has to answer is what binds the maintainer, and on that it is silent. Nothing is committed past month twelve. The final milestone's acceptance criteria include a twelve-month scope review completed with a year-two continuation proposal shared with the Cardano Foundation — which is to say that the last payment is released partly on delivery of the next ask, and that the next ask is addressed to a foundation rather than to the body that would pay for it. The documentation lives in a Cardano section of OpenZeppelin's own documentation site, the network page on OpenZeppelin's website, the Contracts Wizard in OpenZeppelin's tooling under a copyleft licence. There is no stated home for the repositories that survives the vendor's interest, no co-maintainer, no handover path, no contribution policy that gives the builders who will depend on the library any standing over it.  \nCardano changes underneath its contracts. A hard fork is in preparation and more will follow, and each one is an occasion on which a contract library must be re-examined. An audited library that is no longer maintained is not a neutral object: it is trusted precisely because it was audited, and that trust outlives the audit's relevance. This is the sense in which the ecosystem would be easier to enter than to leave. Declining the dependency costs nothing today. Declining to fund year two, once protocols and their users sit on top of the library, is a different decision, taken against a party whose standing this action would have created.  \nHeld against the standard this DRep applies wherever one party acquires the power to set terms that others build on — is that power matched by an obligation running the same direction — the reading is a partial inversion. The power to define default primitives for an ecosystem would pass to the vendor; no corresponding duty to maintain, to accept contribution, or to hand over would pass with it. The exit that exists on paper, the fork, is real and is credited. The exit that would matter in practice is not provided for. The repair is a correction path written into the design: stewardship terms that put the canonical repositories somewhere the commons can reach, at least one maintainer from the ecosystem with merge standing, a stated maintenance commitment across the next ledger era or a funded handover, and a continuation that is costed now, as a recurring service with a point at which it is re-competed, rather than discovered at month twelve.\n\n## 2.6 Who checks the checker\n\nThe third finding concerns the one property that distinguishes this library from the ones that already exist: that it is audited.  \nThe security retainer is scoped to OpenZeppelin-produced code and is performed by OpenZeppelin. That is how the firm works in other ecosystems and there is no suggestion here that its auditors are anything but separate from and rigorous toward its engineers. But the structure asks the treasury to pay one party to write the code, to examine the code, and to report what the examination found, and then releases payment on the publication of that report. The independent element in the acceptance criteria is a single line in the third milestone: at least one independent Cardano developer has reviewed and provided feedback on the library components, confirmed in writing. For three financial protocols and a foundational library intended to be imported across an ecosystem, one reviewer providing feedback is not an independent assurance function.  \nThe scale of the security capacity deserves a moment's attention for the same reason. Twenty-two researcher-weeks is to cover line-by-line audits of some fourteen library components and full-stack reviews and penetration tests of a liquid staking protocol, a synthetic-debt lending protocol and a tokenized fund with credential verification and dividend distribution. For comparison, the engagement OpenZeppelin announced with the Stellar Development Foundation allotted forty auditor-weeks over two years within a program covering a library and its tooling, with no reference protocols in scope. I do not know OpenZeppelin's internal sizing and it may be sound; the reference implementations may be thinner than their descriptions suggest. But that is the difficulty. The proposal describes them as production-ready, the acceptance criteria describe them as demonstrable on testnet with a functional demo front end, and those are not the same claim. A blueprint that carries an auditor's name and is read as production-ready by a team without the expertise to know the difference is a hazard created by the gap between the two descriptions.  \nThere is also a sequencing gap at the end. Audit reports for each milestone are published in the milestone that follows, with critical and high findings resolved — a sensible lag. But the fourth milestone has no successor. Its criteria require that critical and high findings be addressed and that a publication timeline be agreed, and the final twenty per cent is released on that basis. The audit of the tokenized fund, the most institution-facing deliverable in the program, is therefore published after the last payment gate has closed.  \nThe acceptance criteria elsewhere are objective, which is to their credit, and mechanical, which is their limit: code compiles, continuous integration passes, test coverage exceeds ninety per cent, documents are published. Those measure that work was done. They cannot register that the work was unsound, unused or unwanted, and nothing in the milestone table could come out badly in a way that told the ecosystem something it needed to know. The proposal says its deliverables are designed to enable measurable on-chain impact; no measure of it appears.  \nThe repair is modest. Fund an independent review — a second firm or a named panel of ecosystem auditors — for the reference implementations and the highest-risk library components, paid from the withdrawal and not chosen by the vendor. Hold a retention against publication of the final audit reports. And describe the reference implementations as what the criteria make them: audited testnet reference designs, with production readiness a claim to be earned by a specified standard.\n\n## 2.7 A blueprint is a default\n\nOne of the three reference implementations needs separate attention, because it touches the layer this DRep is elected to care about.  \nStaking on Cardano is already liquid. Ada delegated to a pool never leaves its owner's control, is never locked, and carries with it the owner's own choice of governance representative. A liquid staking protocol of the kind described — deposit, delegation across a set of pools, issuance of a yield-bearing token — replaces that arrangement with a pooled one. The ada sits behind a script; the script, or whoever governs it, chooses the pools; and because the ledger currently requires a stake credential to delegate its voting power before rewards can be withdrawn, the script must also choose a governance delegation for everything it holds. Each depositor's individual decision about where their stake and their vote go becomes a single protocol-level setting.  \nThe proposal's acceptance criteria for this implementation list deposit, delegation across a pool set, token issuance and accrual, and redemption. They do not mention the governance delegation of the pooled ada at all. The threat model is to document eUTXO-specific attack vectors; it is not asked to consider stake concentration or the accumulation of voting power as vectors. Yet a reference implementation is, in practice, a default. Whatever this blueprint does with the pooled vote — passes it through to token holders, parks it on abstain, or leaves it to an operator key — is what the first several forks of it will do, with an auditor's name attached. Other ecosystems learned what a dominant liquid staking protocol does to the distribution of both stake and governance weight only after it had happened.  \nThis is not a reason to oppose a liquid staking reference design, and it is not a finding of harm; the Constitution itself contemplates designees holding ada and reserves to the owner the choice of whether they may vote it. It is a reason the design constraints should be stated before the treasury pays for the template. A revised proposal should make the handling of pooled voting power and the pool-selection rule first-class requirements of the liquid staking implementation, name stake and governance concentration in its threat model, and put the architecture out for public review — not review by pre-agreed counterparties — before it is built. I will be monitoring this closely in any resubmission, and separately: an instrument that pools delegation also further obscures what the delegation register is measuring, at a moment when the ecosystem is about to change the rule that shapes that register.\n\n## 2.8 The reference rate, the buffer and the ceiling\n\nThe ada figure in the title is larger than the work costs, by design, and the design is mostly a good one. It nevertheless has three consequences the proposal does not discuss.  \nThe dollar budget is converted at USD 0.16 per ada. Across the voting window ada traded between roughly USD 0.20 and USD 0.25. At about USD 0.235, the price on the day of this reading, the delivery portion of the withdrawal would convert to about USD 2.69 million against a contract of USD 1.83 million — a margin of some forty-seven per cent, or about ₳3.6 million more than the work requires at spot. That margin is not paid to OpenZeppelin, whose milestone payments are fixed in dollars, and on the proposal's terms what is left sweeps back at expiry. This is the right way to carry price risk between a vote and a signature, and the common complaint that treasury proposals hand vendors a volatility windfall does not describe this one.  \nThe first consequence is that the margin is nonetheless withdrawn, and the ceiling counts what is withdrawn. With about ₳42.6 million of headroom left under the Net Change Limit for the nine months that remain in its period, this request occupies more than a quarter of it, and something like a third of that occupation is a buffer that nobody intends to spend. Under a ceiling this nearly exhausted, every dollar-denominated proposal that prudently buffers its conversion crowds out later proposals with money that will come back after the period has closed.  \nThe second is that the return path is unspecified. The whole delivery portion is converted to a stablecoin at signature. What sweeps back at expiry is therefore, on its face, a stablecoin balance, and the treasury is an ada account. When the contract expires, whether the surplus is swept on conversion rather than held for the year, at what rate and at whose cost it is converted back, and what happens in the opposite case — ada below the reference rate at signature and the contract short — are questions the proposal's text does not answer. They may have settled answers in the administrator's procedures; a self-contained withdrawal should carry them.  \nThe third is small in amount and worth recording for its shape. The administration fee is three per cent of the buffered ada figure and is not converted. An administrator's fee that scales with the size of the buffer rather than with the cost of the work administered is paid, at current prices, about half again what three per cent of the contract would be. I impute nothing by noting it. It is simply a place where the incentive and the service have come apart, and it is cheap to align: denominate the fee on the contract value.  \nNone of the three would carry a No by itself. Together they are why the favorable reading of this proposal's financial design, which I hold, is not the whole of the reading.\n\n## 2.9 What the commons retains\n\nThe treasury may fund the maintenance of commons relations; it may not fund the transfer of a private surplus. That is a test of the structure of a claim and not of the recipient, and a for-profit firm maintaining a non-rival good the ecosystem depends on passes it routinely.  \nThere is a private surplus here and it should be named without color. A security and infrastructure firm whose business is audits, retainers and enterprise tooling would be paid by the treasury to establish itself in a new ecosystem as the author of that ecosystem's standard library, with a dedicated account manager for a foundation, a network page, co-marketing, and first position with every institution that arrives later needing an audit. That is ordinary commercial logic and nothing in it is improper. It is also exactly the circumstance in which the proposal carries the burden of showing, in terms of relations rather than quantities, what capacity the commons holds afterwards and how its degradation would be recognised.  \nPart of that burden is met, and met properly. Reusable primitives under an unencumbered licence, that any builder can import and any builder can fork, are coordination capacity in the plainest sense, and the proposal states them as such. Published audit findings are a public record. Those are relational claims and they are credited in full.  \nPart of it is offered in the wrong currency. The case for why this firm is made almost entirely in quantities — trillions of dollars transferred through its contracts, a share of the largest protocols, billions of transactions, weekly downloads. Every one of those numbers is true and every one of them describes another ecosystem. They establish that OpenZeppelin is very good at what it does elsewhere, which is not disputed, and they say nothing about what relation would be maintained here. The more impressive such figures are, the more care is owed in not letting them stand in for the answer; precision about a quantity produced somewhere else is not evidence about a capacity retained here.  \nAnd the remaining part is the finding of section 2.5: the capacity the commons would retain has no durable form beyond the source text. I do not read this as a dispute at the margin about whether a well-stated relation is genuinely served — the kind of honest two-frame disagreement on which this DRep would stand aside. The relation is stated; what is missing is the set of terms that would make it hold, and those terms are nameable and within the proposer's gift. That places the proposal on the side of the line where a No that specifies is owed.\n\n## 2.10 Why this is a No and not an abstention\n\nFour grounds for abstaining were live and each is foreclosed, so the reasoning is set out rather than asserted.  \nThe first is that the ballot cannot carry what the analysis found. Some of it genuinely cannot: the tensions set out in section 2.13 are about how Cardano funds infrastructure at all, and no single vote reaches them. But the three findings that carry this token — scope left open under a fixed price, stewardship that stays with the vendor, and assurance that runs through the funded party — are properties of this action, stated on its face and fixable in it. Where the ballot reaches the finding, the ballot is owed the finding.  \nThe second is that the subject is outside what this DRep's framework can read. It is technical, and I am not a smart contract engineer. That is not a ground. Not understanding a domain is either an obligation to study or an admission of insufficiency, and neither is a claim that the framework has nothing to say; here it has a good deal to say about discretion, stewardship and verification without needing an opinion on a single line of code.  \nThe third is that the disagreement is a margin dispute, and it deserves the most care because this is the kind of proposal on which that reading is most tempting. The proposer is serious, the construction is careful, the track record is long. It would be easy to read all of that as good faith contested only at the edges and to withhold stake accordingly. But care in construction and reputation elsewhere are not evidence about the three structures in question, and withholding stake is not a neutral act: it lowers the bar an action must clear.  \nThe fourth is interest. I hold ada and use the chain, which is the interest every participant shares and disqualifies no one. This DRep has no engagement, past or pending, with OpenZeppelin, with Intersect's administration service, or with any of the teams whose existing work is discussed in section 2.4. One adjacent interest is declared rather than left to be discovered: several of the repairs proposed here would be natural clauses in a common standard for treasury proposals, and this DRep works on standards of that kind. That is an interest in the remedy and not in the action, and readers should weigh the specification with it in view.  \nWhat pulled hardest the other way should be said too, because this vote was closer than its token suggests. The gap is real and has been real for years; the existing efforts have not closed it; and here is a capable party offering to close it on better financial terms than most. A treasury that answers that with an indefinite No has chosen the status quo, and the status quo has costs that fall on every team rebuilding an access-control module and on every user of what they build. That is why the No is remediable, why the specification is short, and why I would rather read a corrected version of this proposal in the next cycle than see the question go quiet. At the time of writing the action stands at roughly three per cent approval against a threshold of sixty-seven; this rationale is addressed less to its outcome than to its successor.\n\n## 2.11 Fiduciary verification (external instrument)\n\nThis DRep's own framework reads the relational and structural question and by design does not read the capital-allocation one — price, instrument fit, size-calibrated discipline, upfront exposure, opportunity cost. Leaving that region unexamined would raise vigilance rather than lower it, so the proposal was run through the DRep Treasury Rule Book v17 as a subordinate gate, one that can lower a merits-Yes but cannot raise a merits-No.  \nBy economic substance this is open-source infrastructure and shared tooling delivered by a commercial firm, which the rulebook reads on its infrastructure scorecard with the public asset, its operability and its continuity treated as the principal return. At ₳11,787,063 nominal it classifies very large — the band that requires exceptional public return, capped upfront exposure and an explicit opportunity-cost case, and where a passing score is necessary and nowhere near sufficient. It should be said that the band is set in ada and the contract is modest in dollars; the rulebook's instruction is to take the highest band any test triggers and not to move down for a good purpose, and that instruction is followed here.  \nThe gate does not clear, and most of what stops it stops it before scoring. Budget clarity fails at this size: there is no itemisation, no rates, no allocation, and the rulebook's instruction where an applicant cannot separate a material bundled budget is unambiguous. Continuity fails: no maintenance, succession or handover is stated beyond the term, and the rulebook's warning that open source without operability and continuity is not yet a public asset is written for this case. Independent verification is partial: milestone evidence is public and is verified by the administrator, which is a real strength, but the security assurance is self-performed and the rulebook does not accept applicant self-certification at this band. Upfront exposure is twenty per cent on signature, subject only to legal sign-off, against a normal ceiling of fifteen per cent for very large requests and lower for a team new to the platform with its toolchain undecided. Dispute, jurisdiction and termination terms are deferred to a contract not yet written. And on instrument fit the rulebook names, as a warning sign, one large master plan before feasibility is shown — where here the feasibility work is literally the first milestone of the plan.  \nAgainst all that, several things score well and should be recorded: the public need is evidenced, custody and disbursement are exemplary, conversion and unspent-funds rules exist where most proposals have none, and prior funding is cleanly disclosed.  \nSo this is convergence at the conclusion rather than corroboration at a soft spot. A rights-derived reading and a capital-stewardship rulebook reach No against the same structure from opposite directions, and they meet at two points in particular — scope before price, and continuity after term. Had the fiduciary read come back clean, the relational No would have stood unchanged; had the relational read passed and the fiduciary one failed, the allocation defect would have been dispositive. The gate's function here is to sharpen the specification.\n\n## 2.12 What would make this a Yes\n\nThe specification is deliberately short, and every item is cheaper before the vote than after it.  \nFix the scope or stage the ask. Either name the language, the component list, the reviewing counterparties and the delivery team before funds are approved, or bring a small first action that funds the evaluation phase alone and returns with a priced specification.  \nPublish a gap-and-overlap analysis, written with the maintainers of the existing libraries and the programmable-token work, that says what this library absorbs, supersedes and leaves alone.  \nState the costs. Roles, allocation, rates, and the split between the three workstreams, so that the Constitution's requirement is met in substance and a change of scope can be priced.  \nWrite the stewardship into the proposal. A canonical home for the repositories that survives the vendor's interest, at least one ecosystem maintainer with merge standing, a maintenance commitment through the next ledger era or a funded handover, and a costed continuation presented now as a recurring service with a point of re-competition.  \nPut assurance outside the author. An independent review of the reference implementations and the highest-risk components, funded from the withdrawal and not selected by the vendor; a retention held against publication of the final audit reports; and the reference implementations described as what their acceptance criteria make them.  \nConstrain the liquid staking blueprint. Treat the governance delegation of pooled ada and the pool-selection rule as stated design requirements, name concentration in the threat model, and open the architecture to public review before build.  \nAnd on the allocation side: bring the kick-off payment inside the band's normal ceiling or tie part of it to the first verifiable output; say when the contract expires, in what asset the surplus returns and at whose cost, and what happens on a shortfall; and denominate the administration fee on the contract value.  \nDo those, and this becomes a proposal this DRep would expect to vote for.\n\n## 2.13 What the vote does not reach\n\nA vote is a snapshot; the log is the trajectory. This proposal is an unusually clear specimen of several tensions in how Cardano funds infrastructure, and converting those into this vote would misrepresent both the proposal and the tensions. They are recorded here, and they are held open rather than resolved, because I do not think any of them has a solution so much as a position the ecosystem occupies and can be watched moving along.  \nThe first is between the instrument and the good. A treasury withdrawal is a discrete purchase: a scope, a sum, a term, an end. A standard library is a continuous service whose value is its maintenance. Forcing the second into the first produces exactly what is visible here — a twelve-month build whose real subject is years two through ten, with the continuation appearing as a line in the final milestone. The ecosystem has no recognised instrument for a recurring public service with service levels and periodic re-competition, and until it has one, every infrastructure proposal will be a first instalment that cannot say so.  \nThe second is between prudence and the ceiling. This proposal handles price risk well and is penalised for it by a limit that counts ada withdrawn rather than value spent. The same mismatch sits underneath the several competing proposals to reform the Net Change Limit, each of which reaches in its own way for some reading of what was actually spent. Buffers that return after the period closes are a concrete case for that work, and I intend to carry this one into it.  \nThe third is between the brand and the reading. Representatives with limited time read signals, and a famous name is a strong one; the worry that large outside firms will be waved through on reputation is a reasonable worry. This vote is evidence against its strong form. The electorate did not defer: at the time of writing, explicit opposition outweighs support by more than ten to one. Whether that reflects close reading or a different reflex — suspicion of the outsider — the tally cannot say, and the second would be no healthier than the first. What I will be watching is the reasons given, here and at resubmission, more than the totals.  \nThe fourth is between openness and cultivation, and it is the one I would least like to see settled cheaply. A large allocation to a dominant outside firm for work that native teams have been doing on small grants tells those teams something about where the funding path leads, and capability that is not exercised atrophies. That is a real cost. So is its opposite: an ecosystem that treats nativeness as a qualification has built a guild, and the people it most reliably protects are not the ones doing the best work. I do not think the answer is a preference in either direction. I think it is a requirement that any proposal entering occupied ground say what is already there — which is why the overlap analysis is in the specification and why a standard for it belongs in a future proposal rather than in this vote.  \nThe fifth is between standardisation and shared fate. The argument for a standard library is that everyone stops rebuilding the same components badly. The argument against a single one is that everyone then fails together. Both are correct. A healthy position probably contains a canonical library and at least one independent implementation of the critical parts, and nothing in the current funding landscape asks for the second.  \nThree smaller readings belong beside these. The engagement's accountability is addressed to a foundation — the account manager, the continuation proposal — while its payment comes from the commons; the foundation also sits on the oversight committee. That is a pattern in how institutions come to stand in for the community in the self-description of proposals, and it is worth watching across proposals rather than objecting to in one. The component list would give the standing of a standard to a particular set of primitives — pause, timelock, role-based access, credential-gated transfer, token-voting governance — and what is on the paved road shapes what gets built; the commons was not asked which primitives it wanted paved. And the questions this DRep's intake asks that no proposal template yet does — what reverses this if it is wrong in eighteen months, what reads through it, what would register its degradation — went unanswered here because they were never put. That is a reading of the ecosystem's vocabulary and not a defect in the submission.  \nTwo of these are candidates for a future proposal rather than a future vote: a recognised instrument for recurring public-service funding, and a common standard for what a treasury proposal entering occupied ground must state — scope before price, an overlap account, stewardship terms, and how a conversion buffer is counted.  \n---\n\n# 3.0 Conclusion\n\nWe are voting NO (remediable).  \nThe problem this proposal names is real, the firm proposing to solve it is capable of solving it, and the financial construction is among the more careful this DRep has read. The refusal is not of the ambition, the price or the proposer. It is of three structures: a sum fixed before the language, the components, the team and the costs are; a public asset whose code the commons would hold while its stewardship, its maintenance and its name stay elsewhere, with the continuation arriving as a second ask; and an assurance claim verified by the party making it. Run separately, the external capital-allocation instrument reaches the same conclusion against the same structures.  \nEach is repairable by the proposer, and the proposal has already said it will return. Scope fixed or staged, an honest map of the ground already occupied, costs stated, stewardship written in, assurance placed outside the author, and the liquid staking template constrained where it touches the vote. That is the whole specification.  \nWhat I will carry forward beyond this action is the larger pattern it makes visible: a treasury that buys continuous infrastructure through discrete purchases, under a ceiling that counts buffers as spending, with no settled way of asking a newcomer what is already there. Those are not this proposer's doing, and they will outlast this vote. This DRep will continue to maintain a state of inquiry around them and will bring the two that are ripe into proposal form.\n\nDRep ID: *drep1yfaq8dsam7nusdccey2x2p684f6ulhr42pv24tslv0terqs3nq50q*  DRep Profile: [On DRepTalk](https://dreptalk.com/dreps/styg-nq50q/)\n\nMy thanks to the delegators who make this reading possible, and to the people at OpenZeppelin who brought a serious proposal to an open vote and said in advance that they would listen to the answer.\n\nStay in touch. X: [https\\://x.com/styg50](https://x.com/styg50)  \n---\n\n# Sources\n\nExternal figures were read on 8 October 2026 and should be re-verified at submission.\n\n* Governance action record, vote state and anchors: [Cardano Cube](https://www.cardanocube.com/governance/gov_actions/gov_action1gxxltxr02p28a398p8c6t08xhpg82wkkv9xgwvuxkly48lhgf20sqlkl2l8); submission epoch and closing time: [CryptoTicker](https://cryptoticker.io/en/cardano-ada-treasury-vote-check/); status at 2 October: [Intersect weekly update \\#131](https://intersectmbo.org/news/intersect-weekly-update-131-oct-2-2026).  \n* Net Change Limit usage (DRepTalk count, as reported): [CryptoBenelux, 94% article](https://cryptobenelux.com/altcoin-nieuws/cardano-nadert-treasuryplafond-openzeppelin-kan-verbruik-naar-94-brengen) and [reform article](https://cryptobenelux.com/altcoin-nieuws/cardano-wil-treasuryregels-hervormen-nu-500-miljoen-ada-plafond-bijna-volloopt).  \n* Ada price across the voting window: [CoinGecko](https://www.coingecko.com/en/coins/cardano); [CoinGape](https://coingape.com/markets/cardano-price-prediction-amid-crucial-11m-ada-treasury-withdrawal-vote/).  \n* Existing library work: [input-output-hk/contracts-library](https://github.com/input-output-hk/contracts-library); [Anastasia Labs design patterns](https://github.com/Anastasia-Labs/plutarch-design-patterns) and its [community funding record](https://www.lidonation.com/en/proposals/anastasia-labs-streamlining-development-a-user-friendly-smart-contract-library-for-plutarch-and-aiken-design-patterns-efficiency-f10); [MeshJS and TrustLevel Aiken library](https://lidonation.com/en/proposals/aiken-open-source-smart-contract-library-by-meshjs-trustlevel-f11); CIP-113 merge: [Cardano Forum digest, 30 September](https://forum.cardano.org/t/digest-september-30-9-years-of-cardano-cip-113-programmable-tokens-merged-into-the-cip-repo-cardano-node-update-token2049-singapore-developer-spotlight-ecosystem-governance-updates/157100).  \n* Comparator engagement: [Stellar Development Foundation and OpenZeppelin](https://stellar.org/blog/foundation-news/sdf-partners-with-openzeppelin-to-enhance-stellar-smart-contract-development).  \n* Contracting counterparty: [Intersect due diligence policy](https://docs.intersectmbo.org/intersect-knowledge-base/legal/policies-and-conditions/intersect-administration-policies/due-diligence-policy).  \n* A public rationale by another DRep reaching No on overlapping grounds: [as syndicated](https://www.kucoin.com/pt/news/insight/ADA/6aa811197d10fa0007cd771b)."}}