Withdraw ₳199,911 for OpShin - Python Smart Contracts for Cardano
153 DReps voted · 45 with a rationale
Open a row to read the rationale.
- Yes 8.8M ₳ Rationale
「275M ADA Administered by Intersect」に含まれるすべての個別提案に対して、エクレシア投票の段階では必ずしもすべてに賛成していたわけではありませんが、最終的には本ガバナンスアクションに賛成票を投じました。Cardanoエコシステム全体への貢献を高く評価し、その前進を後押しする立場から、今回提出された39件すべての提案に賛成票を投じる判断をいたしました。\n\nWhile I did not necessarily support every individual proposal included in "275M ADA Administered by Intersect" during the Ekklesia vote, I ultimately voted Yes on this governance action. Recognizing its overall contribution to the Cardano ecosystem and in support of continued progress, I cast a Yes vote on all 39 proposals submitted under this initiative.
- Yes 8.1M ₳ No rationale
- Yes 7.8M ₳ No rationale
- No 7.3M ₳ No rationale
- Yes 7.1M ₳ Rationale
I voted YES for this proposal in the Ekklesia temperature check. I have now come to a position where I think that this might not be the best way forward. Meaning that direct funding of smaller open source maintenance and enhancement proposals from the treasury might not be the best approach going forward.
As I have already indicated my support for this proposal in Ekklesia, I will not overcomplicate matters by changing my vote at this - the final treasury withdrawal stage. So my original vote indication remains in place and I vote YES. Note: if this were to be resubmitted in 2026, I would consider this carefully.
Why? I am more in favor of seeing proposals like this funded through an initiative such as the OSC Budget Proposal - Paid Open Source Model for Sustainable Development. I voted YES for the OSC Budget Proposal - Paid Open Source Model for Sustainable Development.
Such budgetary initiatives do not have to come from the OSC, it could be another umbrella group of open source advocates / body that will prioritize and correctly value certain critical packages of maintenance and enhancement work on open source tools that are important for the Cardano ecosystem.
This group or groups would ideally rank the importance / relevance of these open-source tools and software kits, as well as realistically estimate how much maintenance / enhancement is needed and when it is critical.
Multiple tiny contracts approved by the treasury complicate oversight, whereas larger open-source infrastructure umbrella programs can rank repos by impact and rotate funding annually. The more exceptions the Treasury grants, the harder it becomes to enforce future budget discipline.
I imagine the maintenance and improvement of open source tools as something that could be tentatively grouped. Of course, these larger maintenance and enhancement support groups (like the OSC) for open source tooling could start discriminating against certain tools. In those cases, if a proposer is dissatisfied with the ranking or grouping, they could always directly apply to the Treasury with a rationale why the proposal needs funding and why it cannot obtain it elsewhere - but only directly from the Treasury.
Note: some other similar open source maintenance and enhancement proposals might differ in their perceived importance - and my vote indication in Ekklesia. I am currently considering to mostly mirror my voting indications from Ekklesia - in order to not overcomplicate the process. Exceptions will be indicated. - Yes 6.2M ₳ No rationale
- Yes 6M ₳ Rationale
Voting decision was made to be consistent with my reconciliation back in May 2025;
https://2025budget.intersectmbo.org/voters/drep1yfdfs28uwafjgmrkatdektlzrvha2cmvqjhuz700e04mawq23rmrgReady to move forward overall with the budgeting process and look forward to a smoother process next year. I voted for a lower NCL overall (200M), however found in supporting things that we really ought to have funded to keep momentum in development and enhancements on-chain (supporting both open and non-open-sourced projects) I came a bit higher than that (250M+).
We will need to strike a balance in treasury withdrawels for projects that push development forward (and therefore the chains efficiency, performance, resiliancy, and seucrity) -- and businsess that wish to participate, of any size, and extend the capabilities and real-world use cases of Cardano.
My votes, I hope, align with my overall goal as a DRep to see continuous improvement in the ecosystem. https://raw.githubusercontent.com/Tarrant64/mr_cata_gov/refs/heads/main/mr_cata_gov%20.txt
- Yes 5.5M ₳ No rationale
- Yes 5.3M ₳ No rationale
- Yes 5.3M ₳ Rationale
OpShin lowers the barrier to entry for Cardano development by enabling smart contract creation in Python, one of the most widely used and accessible programming languages. This aligns with STORM Partners’ goals to attract talent, improve infrastructure efficiency, and broaden adoption. As an open-source and bootstrapped project, we believe it deserves treasury support to continue growing and evolving. We vote YES.
- Yes 4.8M ₳ Rationale
Python with dataclass and type-hint really makes it readable and maintainable. On-chain script with Python will drive the future DApp development in Cardano.
Python with dataclass and type-hint really makes it readable and maintainable. On-chain script with Python will drive the future DApp development in Cardano.
- Yes 4.6M ₳ No rationale
- Yes 4.5M ₳ No rationale
- No 4.4M ₳ No rationale
- Yes 4.2M ₳ Rationale
I vote YES because core engineering is the priority of my DRep account.
Strength and honor.
- Yes 4M ₳ No rationale
- Yes 3.7M ₳ Rationale
Python's widespread use and importance justify supporting smart contract tooling for Python developers. I endorse this proposal to enhance Cardano's accessibility and functionality for the Python developer community.
- Yes 3.7M ₳ No rationale
- Yes 3.5M ₳ No rationale
- Yes 3M ₳ No rationale
- Yes 2.8M ₳ No rationale
- Yes 2.7M ₳ No rationale
- Yes 2.7M ₳ Rationale
A couple of months ago, I supported the resolution to bundle all of the Intersect Budget Proposals into 1 or 2 formal on-chain governance votes.
Each of these proposals has already received 50% or greater support from the active DReps in the ecosystem, and I will honor that prior decision.
A PDF version of this rationale is also made available.
A couple of months ago, I supported the resolution to bundle all of the Intersect Budget Proposals into 1 or 2 formal on-chain governance votes.
Each of these proposals has already undergone extensive scrutiny and received 50% or greater support from the active DReps in the ecosystem, and I will honor that prior decision and the work these prospective developers have put in by voting yes on all the proposals from the Intersect Budget team.
- No 2.6M ₳ Rationale
This looks more like a Catalyst proposal. Moreover, it lacks details and a budget breakdown, even though the requested amount is not the largest compared to others.
- Yes 2.5M ₳ No rationale
- Yes 2.5M ₳ No rationale
- Yes 2.5M ₳ Rationale
OpShinは、Pythonベースでスマートコントラクトを記述できるツールチェーンを提供することで、Haskell/Plutusに依存しない開発者参入のハードルを大幅に下げます。既にドキュメント・Pioneerプログラム・GitHub活動も整備されており、₳200K未満の支援で大きな波及効果が期待できるため賛成します。
OpShin lowers the entry barrier for smart contract development on Cardano by enabling Python-based development while retaining functional programming benefits. Given its maturity, documentation, and low cost, I vote in favor to expand accessibility and developer onboarding.
- Yes 2.5M ₳ Rationale
Python as the #2 used programming language on github, makes sense to support it especially with the project already being bootstrapped.
- Yes 2.1M ₳ No rationale
- Yes 1.9M ₳ No rationale
- Yes 1.9M ₳ No rationale
- Yes 1.8M ₳ Rationale
I am voting Yes. Python is one of the most widely used programming languages globally, and supporting it lowers the barrier to entry for a vast pool of developers unfamiliar with Haskell or functional DSLs. The proposal demonstrates strong technical grounding and ecosystem alignment. At a modest cost, this initiative offers high potential impact by expanding Cardano’s developer base and fostering broader innovation.
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.2M ₳ No rationale
- Yes 1.2M ₳ Rationale
I decided to vote ✅ YES on 37 treasury withdrawals, ➖ ABSTAIN on none, and ❌ NO on 2 treasury withdrawals from the Intersect 2025 budget.
It’s obvious I consider all proposals I approved in the budget vote on Ekklesia beneficial for Cardano, so those all receive a ✅ YES vote.
I also vote ✅ YES for most proposals I initially abstained from or voted against in the Ekklesia vote. There are a few reasons for this:
- Some proposals gained strong community support after all, so I don’t want to be the one standing in the way, especially when the requested amount is negligible in the bigger picture.
- Some proposals I actually liked, but I found them more suitable for Catalyst. However, with all the delays, it now makes more sense to fund them as soon as possible.
- Some didn’t get my initial support because I thought the requested amount was too high. But I now believe it’s better for the ecosystem to fund them, despite the larger budget, than not fund them at all.
- I needed to vote for budget proposals with my own NCL in mind. Not all those I approved made it, however, so that leaves some room for other ones.
I won’t approve the treasury withdrawal for two proposals:
❌ Withdraw ₳3,000,000 for High-yield RWA Asset for Cardano: Tokenized Real Estate
This proposal won’t bring much value to our ecosystem, imho.❌ Withdraw ₳1,500,000 for Complement Catalyst: Extended Quadratic Funding---Zero Operational Costs
While the proposal includes some interesting ideas for a fairer voting mechanism, I now support Catalyst and don’t see the need for an additional funding system at this moment, especially considering total spending. The requested amount also seems too small to meaningfully fund multiple projects. While the model relies on donations, it’s unclear what the donor incentive is. Since voting power is tied to donation size, why wouldn’t donors just support specific fundraisers run directly by the projects they care about? That way, they can ensure their contribution goes straight to their preferred initiative without needing it to win a vote first.
I do appreciate the idea of a hybrid funding model where the treasury covers part of a project, but ideally, the remaining portion should come from investors rather than donations, imho.
Lastly, I don’t appreciate that the proposal’s title refers to Catalyst, even though it has no relationship to it. This seems intended to mislead people into thinking Catalyst would benefit from this proposal, which it doesn’t...I acknowledge there’s a metadata issue in the proposal “Withdraw ₳45,217 for MLabs Core Tool Maintenance & Enhancement: Cardano.nix”, but I approved it nonetheless, as the problem is minor and not worth obstructing the process.
- Yes 1.1M ₳ No rationale
- No 1.1M ₳ No rationale
- No 1M ₳ Rationale
I vote No on this treasury withdrawal. I urge the proposer to return with a refined proposal that includes:
- Clear, quantifiable milestones and KPIs aligned to ecosystem growth metrics;
- Independent performance benchmarks and security audits;
- A sustainability plan for post-funding continuation;
- Transparent mechanisms for milestone validation and community reporting.
- Yes 1M ₳ No rationale
- Yes 947.9K ₳ No rationale
- Yes 922.9K ₳ No rationale
- Yes 819K ₳ No rationale
- Yes 810K ₳ No rationale
- Yes 793K ₳ No rationale
- Yes 785.2K ₳ No rationale
- Yes 733.1K ₳ No rationale
- Yes 717.1K ₳ No rationale