Withdraw 540,750 ada for Pallas by TxPipe: Maintaining Cardano's Core Rust Li...
116 DReps voted · 35 with a rationale · 3 changed their vote
Open a row to read the rationale.
- Yes4.6M ₳No rationale
- Yes4.4M ₳Rationale
I will support all TxPipe proposals that have emerged from Intersect’s Ekklisia process. Although I do not have the technical expertise to fully evaluate the costs of these initiatives, I recognize the importance of the work and TxPipe’s strong track record in the Cardano ecosystem.
I also trust the judgment of my fellow DReps who participated in the Ekklisia process and brought these proposals forward.
Therefore, I will support them. - Yes3.8M ₳Rationale
I see this as a administrative vote which is to process a withdrawal that DRep's have previously approved. I do not believe in throwing monkey-wrenches into approved and planned for processes, and thus I vote yes so as not to obstruct progress and momentum, and to not undermine previous decisions.
- Yes3.6M ₳No rationale
- Yes2.8M ₳No rationale
- Yes2.8M ₳No rationale
- Yes2.6M ₳Rationale
私は本Treasury Withdrawalに賛成します。
Pallasは、CardanoのOuroboros / ledger / CBOR / cryptography / networking / transaction buildingなどの基礎処理をRustで扱うための重要なOSSライブラリ群です。これは特定dAppのための私的開発ではなく、Aiken、Dolos、Oura、Mithril、Amaru、UTxO RPCなど、Cardanoの複数プロジェクトが再利用できる公共性の高いDevX基盤です。
また、Pallasの保守は、Cardanoのdata access layerと開発者基盤をHaskell中心に閉じず、Rust-native toolingへ広げる意味があります。これはCardanoのclient diversity、tooling diversity、開発者体験を高める支出として評価できます。
資金管理面でも、Intersect管理のSmart Contract Disbursement、TRSC/PSSC、milestone-based controls、oversight committee、dashboard透明性を備えている点を評価します。
I support this Treasury Withdrawal.
Pallas is an important open-source set of Rust libraries for handling core Cardano functions such as Ouroboros, ledger data, CBOR, cryptography, networking, and transaction building. This is not private development for a single dApp. It is a high-public-value DevX foundation that can be reused by many Cardano projects, including Aiken, Dolos, Oura, Mithril, Amaru, and UTxO RPC.
Maintaining Pallas also helps expand Cardano’s data access layer and developer ecosystem beyond Haskell-centered tooling. It strengthens client diversity, tooling diversity, and the overall developer experience on Cardano.
I also value the funding management design: Intersect administration, Smart Contract Disbursement, TRSC/PSSC, milestone-based controls, an oversight committee, and dashboard transparency.
- Abstain2.5M ₳No rationale
- Yes2.5M ₳Rationale
Due to rationales becoming stressful and the bear market vibes - I will not be providing rationale. I voted the way that I did bc we need a 'no stress' environment more than ever.
- YesChanged2.3M ₳History
Earlier votes
No1mo agoSuperseded
- Yes2.1M ₳Rationale
Although this is only an excerpt as a description here, given the proposal's objectives, Palla's role in the ecosystem and the principles put forward, this has my support.
- Yes2.1M ₳No rationale
- Yes2.1M ₳Rationale
I am voting YES on the TxPipe Pallas proposal.
Pallas is core developer infrastructure for Cardano. It provides Rust libraries for important Cardano primitives, including ledger data structures, serialization, cryptography, transaction building, chain synchronization, multi-era support, and node communication.
This is not a speculative growth proposal. It is a focused maintenance request for open-source tooling that sits low in the Cardano development stack and is used by multiple downstream projects and developer tools.
In the current NCL environment, I believe DReps need to be selective. My priority is to support proposals that maintain critical public goods, core developer infrastructure, protocol compatibility, open-source libraries, and the technical rails that Cardano builders rely on.
Pallas clearly fits that category.
I consider this one of the stronger TxPipe proposals because it is foundational. Higher-level tools and applications depend on reliable lower-level libraries. If those libraries fall behind ledger changes, hard forks, dependency updates or protocol evolution, the impact can propagate across the ecosystem.
I also view it positively that this proposal is modest in size compared with many other live treasury requests and is structured through the 2026 treasury management framework, with Intersect administration, oversight controls, milestone-based disbursement and community auditability.
Given the current budget pressure, I am prioritising infrastructure and maintenance over larger speculative or commercial proposals. Pallas is exactly the type of low-level open-source developer tooling that the treasury should be willing to maintain.
For these reasons, I consider this a responsible and proportionate use of treasury funds.
I vote YES.
- Yes1.9M ₳No rationale
- Yes1.8M ₳No rationale
- Yes1.6M ₳No rationale
- No1.5M ₳No rationale
- No1.3M ₳No rationale
- Yes1.2M ₳No rationale
- No1.2M ₳No rationale
- Yes1.1M ₳No rationale
- Yes1.1M ₳No rationale
- Yes1M ₳No rationale
- Yes988.4K ₳No rationale
- Yes924.2K ₳No rationale
- Yes870.4K ₳No rationale
- Abstain862K ₳No rationale
- Yes830.3K ₳Rationale
We support Intersect's budget process. This proposal was part of it.
- Yes799.1K ₳No rationale
- Yes795K ₳No rationale
- YesChanged620K ₳History
Earlier votes
Abstain23d agoSuperseded
- Yes608.1K ₳No rationale
- Yes590K ₳Rationale
Supporting withdrawal
- Yes587.6K ₳No rationale
- Yes535.2K ₳Rationale
TxPipe will deliver, absolute must approval.
- Yes480.2K ₳No rationale
- Yes444.7K ₳No rationale
- No377.7K ₳Rationale
TxPipe is among the companies that in my opinion have extracted more than enough profits from the Cardano ecosystem and shouldn't be funded anymore.
Power to the edges!
- No365.9K ₳No rationale
- No360.4K ₳No rationale
- No309.6K ₳Rationale
Review Methodology Disclaimer [EN]
Due not only to the unusually high volume of Treasury Withdrawal Governance Actions and budget proposals submitted in mid 2026, but also to the lack of meaningful incentives for DReps to perform proposal analysis work, it is not feasible to apply my full standard review framework and reporting template to every proposal.
My standard analysis process usually requires approximately four hours of work per Governance Action. During that process, I research the proposal, review supporting materials, compare different perspectives from DReps and other ecosystem participants, and weigh both positive and negative arguments before reaching a reasonably qualified decision. Even with the use of artificial intelligence to automate parts of the workflow and improve productivity, a responsible evaluation still requires substantial human review, judgment, and contextual understanding.
In addition, this work does not end with the vote itself. It also involves writing and publishing rationales, preparing reports or summaries, communicating the reasoning publicly, and socializing the analysis through public channels and social media. This creates a significant workload, especially when dozens of proposals must be reviewed in a short period.
At present, this work carries no clear financial incentive and only limited reputational incentive, despite requiring substantial time, attention, and accountability. In practice, it is not sustainable to dedicate near full-time effort over several weeks or months to this activity without any form of compensation or institutional support.
Since I have a clear standard for my work and do not want to lower the quality of my judgment, I will reduce the scope of my analysis where necessary rather than rush decisions or produce superficial rationales. This means prioritizing focused due diligence over exhaustive review.
Under these constraints, my methodology during this period will focus on identifying critical strategic, operational, governance, reputational, or execution-related risks that could materially compromise a proposal’s viability, accountability, or successful delivery. In practical terms, this means narrowing my research toward the most critical gaps that may make approval unjustifiable. Where such a serious risk is identified, I may use it as the basis for a rejection vote.
This approach also helps reduce review overload: proposals with clear and material gaps would likely require rework regardless, so voting against them when those gaps are significant can be a responsible way to preserve review capacity while maintaining minimum due diligence.
Examples of such high-priority concerns may include, but are not limited to:
- Serious delivery failures in previous funded proposals;
- Significant unresolved delays in ongoing work;
- Major reputational or accountability issues within the ecosystem;
- Lack of credible execution capacity;
- Structural governance or transparency concerns;
- Severe budgetary or coordination risks.
Where I do not have sufficient time for a deeper evaluation, and no significant red flags or imminent execution risks are identified, I may abstain rather than issue an underdeveloped approval or rejection rationale.
This does not mean that other dimensions of proposal quality are unimportant. It means that, under current constraints, I will prioritize a narrower but still responsible review scope that preserves minimum due diligence, avoids rushed decisions, and keeps the quality of my judgment at an acceptable standard.
Governance Action Report
The maintenance proposals for Oura, Pallas, Dolos, and UTxO RPC follow practically identical structures. Each requests funding for a 12-month period using the same labor model, the same contingency mechanism, the same Intersect administration framework, and substantially similar quarterly milestones. Although the repositories perform different technical functions, the same material budget concern applies to all four proposals. For this reason, a standardized rationale is being used.
This standardized treatment does not mean that Oura, Pallas, Dolos, and UTxO RPC are technically equivalent or equally important to the Cardano ecosystem. Each project occupies a different position within the technical stack and may have a different level of strategic relevance, adoption, downstream dependency, and substitutability. The use of a common rationale reflects the similarity of their funding structures and the fact that the same budget deficiency remains unresolved across all four proposals.
There is no opposition to TxPipe as a team. TxPipe has a strong reputation within the Cardano ecosystem and is one of the most relevant contributors to Cardano’s technical stack. The team maintains several open-source projects used by other developers and ecosystem participants and has a broadly positive history of completing previously funded proposals. While one proposal experienced a limited delay of a few months, there does not appear to be a broader pattern of prolonged delays or execution failures. In general, TxPipe has demonstrated an ability to deliver funded work within reasonable timeframes.
There are also meaningful signs that these projects are not purely experimental or unused. The repositories associated with these proposals show relevant levels of activity, engagement, contributions, forks, integrations, and use by other ecosystem participants. Considering the relatively limited size of the Cardano developer ecosystem, this engagement suggests that the projects have already demonstrated practical usefulness for developers, infrastructure providers, and other contributors.
No independent conclusion is being reached regarding the precise technical essentiality of each project. Determining how indispensable Oura, Pallas, Dolos, or UTxO RPC may be, which alternatives exist, and what technical consequences could arise from discontinued maintenance requires specialized knowledge. Developers with direct experience using these tools and understanding their respective dependencies are better positioned to assess their strategic importance and technical differentiation.
Although the proposals identify Pillar 2, Adoption and Utility, as their primary strategic alignment, these activities appear more directly aligned with Pillar 1, Infrastructure and Research Excellence. These projects do not constitute adoption initiatives by themselves. They provide technical infrastructure, libraries, standards, or data-access components that enable other applications and services. Their contribution to adoption is therefore primarily indirect, while their immediate function is to support the infrastructure on which other ecosystem activity depends.
The principal concern is the budget. The maintenance proposals request the equivalent of USD 105,000 to fund a part-time developer for 12 months, but they do not adequately define what “part-time” represents. They do not disclose the expected number of weekly or monthly hours, the percentage of full-time equivalent capacity, the hourly or monthly rate, the specific seniority of the funded professional, or the estimated allocation of time among maintenance, community support, documentation, protocol compatibility, enhancements, and AI-related activities.
The proposals state generally that the work will be carried out by experienced Rust developers and that a dedicated technical lead will provide oversight, with the cost of that technical leadership absorbed by TxPipe. However, this does not identify the amount of labor capacity that the Treasury is actually purchasing. Without an objective definition of the expected level of commitment, it is impossible to determine whether USD 105,000 corresponds to ten, twenty, thirty, or nearly forty hours of specialized work per week.
This omission makes the cost-benefit evaluation excessively subjective. There is not enough evidence to conclude that the proposed price is excessive, unreasonable, or inconsistent with the market for specialized blockchain and Rust development. At the same time, there is also not enough information to verify that the price is proportionate to the amount of work being contracted. The team’s reputation and the apparent usefulness of the projects do not replace the need to explain how the labor cost was calculated.
The quarterly milestones reinforce this uncertainty. Across the maintenance proposals, the milestones repeat substantially similar activities and completion criteria, including dependency updates, protocol compatibility, bug fixing, performance improvements, documentation, issue triage, contribution review, and AI-friendly development resources. Terms such as responding to issues within a “reasonable timeframe” do not establish an objective service level.
There are also no clearly defined minimum volumes of work, release targets, response times, availability expectations, issue-resolution targets, or specific deliverables for the AI-related scope. Some flexibility is appropriate for maintenance work because future bugs, protocol changes, and community requests cannot be predicted precisely. However, that flexibility should be balanced by a clearer definition of the labor capacity being contracted.
The contingency reserve and the commitment to return unused funds are positive elements. The mechanism is designed to preserve a fixed USD budget if ADA falls below the proposal conversion rate, while requiring excess ADA to be returned to the Treasury when it is not needed to cover the approved USD amount. This reduces the risk that the contingency reserve automatically becomes additional compensation. Nevertheless, a sound exchange-rate mechanism does not resolve the absence of granularity in the underlying labor budget.
The fact that four similar proposals are being submitted by the same provider also increases the importance of consolidated staffing transparency. The documentation does not clearly establish whether the funded work will be performed by four separate developers, shared team members, or overlapping resources. It also does not provide a consolidated view of total full-time-equivalent capacity, responsibilities, or separation of work among the four projects.
This does not establish that overlapping billing or duplicated work will occur. However, the information provided is insufficient to exclude that risk or to verify the provider’s aggregate delivery capacity across all four contracts. When multiple simultaneous Treasury requests rely on similar descriptions of undefined part-time resources, a clear staffing and allocation map should be provided.
If the proposals specified the expected hours, full-time-equivalent allocation, seniority, staffing arrangement, and calculation of labor costs, the principal budget objection would be removed. Under those circumstances, the most likely position would be ABSTAIN, given TxPipe’s reputation, delivery history, and the evidence that these projects have practical use, while recognizing that more technically qualified participants are better positioned to determine the strategic essentiality of each project.
Under the current terms, however, a Treasury Withdrawal must allow DReps to assess not only whether the provider is reputable and the project appears useful, but also how much labor is being purchased and whether the requested amount is proportionate to that capacity. Because this fundamental information is not available, the cost-benefit relationship cannot be evaluated with sufficient confidence.
For these reasons, the vote on the Oura, Pallas, Dolos, and UTxO RPC maintenance proposals is NO.
Nota sobre metodologia e escopo de análise [PT]
Devido não apenas ao volume excepcionalmente alto de Treasury Withdrawal Governance Actions e propostas orçamentárias submetidas no meio de 2026, mas também à falta de incentivos significativos para que DReps realizem o trabalho de análise de propostas, não é viável aplicar meu framework completo de revisão e meu template padrão de relatório a todas as propostas.
Meu processo padrão de análise normalmente exige aproximadamente quatro horas de trabalho por Governance Action. Durante esse processo, eu pesquiso a proposta, reviso materiais de suporte, comparo diferentes perspectivas de DReps e de outros participantes do ecossistema, e peso argumentos positivos e negativos antes de chegar a uma decisão razoavelmente qualificada. Mesmo com o uso de inteligência artificial para automatizar partes do fluxo de trabalho e aumentar a produtividade, uma avaliação responsável ainda exige revisão humana substancial, julgamento e entendimento contextual.
Além disso, esse trabalho não termina no voto em si. Ele também envolve escrever e publicar rationales, preparar relatórios ou resumos, comunicar publicamente a justificativa e socializar a análise por meio de canais públicos e mídias sociais. Isso cria uma carga de trabalho significativa, especialmente quando dezenas de propostas precisam ser avaliadas em um curto período.
Atualmente, esse trabalho não possui incentivo financeiro claro e oferece apenas incentivo reputacional limitado, apesar de exigir tempo, atenção e responsabilidade substanciais. Na prática, não é sustentável dedicar um esforço próximo de tempo integral durante várias semanas ou meses a essa atividade sem qualquer forma de compensação ou apoio institucional.
Como tenho um padrão claro para o meu trabalho e não quero reduzir a qualidade do meu julgamento, irei reduzir o escopo da minha análise quando necessário, em vez de tomar decisões apressadas ou produzir justificativas superficiais. Isso significa priorizar uma diligência focada em vez de uma revisão exaustiva.
Sob essas restrições, minha metodologia durante este período se concentrará em identificar riscos críticos estratégicos, operacionais, de governança, reputacionais ou relacionados à execução que possam comprometer materialmente a viabilidade, a accountability ou a entrega bem-sucedida de uma proposta. Na prática, isso significa concentrar minha pesquisa nos gaps mais críticos que possam tornar a aprovação injustificável. Quando um risco sério desse tipo for identificado, poderei usá-lo como base para um voto de rejeição.
Essa abordagem também ajuda a reduzir a sobrecarga de revisão: propostas com gaps claros e materiais provavelmente exigiriam retrabalho de qualquer forma, então votar contra elas quando esses gaps forem significativos pode ser uma forma responsável de preservar capacidade de análise enquanto se mantém uma diligência mínima.
Exemplos dessas preocupações de alta prioridade podem incluir, mas não se limitam a:
- Falhas graves de entrega em propostas anteriormente financiadas;
- Atrasos significativos e não resolvidos em trabalhos em andamento;
- Problemas graves de reputação ou accountability dentro do ecossistema;
- Falta de capacidade crível de execução;
- Preocupações estruturais de governança ou transparência;
- Riscos severos de orçamento ou coordenação.
Quando eu não tiver tempo suficiente para uma avaliação mais profunda, e nenhum alerta significativo ou risco iminente de execução for identificado, poderei me abster em vez de emitir uma justificativa de aprovação ou rejeição pouco desenvolvida.
Isso não significa que outras dimensões da qualidade de uma proposta não sejam importantes. Significa que, sob as restrições atuais, priorizarei um escopo de revisão mais estreito, mas ainda responsável, que preserve uma diligência mínima, evite decisões apressadas e mantenha a qualidade do meu julgamento em um padrão aceitável.
Relatório de Ação de Governança
As propostas de manutenção de Oura, Pallas, Dolos e UTxO RPC possuem estruturas praticamente idênticas. Todas solicitam financiamento para um período de 12 meses, utilizando o mesmo modelo de custo de trabalho, o mesmo mecanismo de contingência, a mesma estrutura de administração da Intersect e milestones trimestrais substancialmente semelhantes. Embora os repositórios exerçam funções técnicas diferentes, a mesma preocupação orçamentária material está presente nas quatro propostas. Por essa razão, é utilizada uma fundamentação padronizada.
Esse tratamento padronizado não significa que Oura, Pallas, Dolos e UTxO RPC sejam tecnicamente equivalentes ou igualmente importantes para o ecossistema Cardano. Cada projeto ocupa uma posição diferente dentro da infraestrutura técnica e pode apresentar níveis distintos de relevância estratégica, adoção, dependência por outros projetos e possibilidade de substituição. A utilização de uma fundamentação comum decorre da semelhança entre suas estruturas de financiamento e do fato de que a mesma deficiência orçamentária permanece sem solução nas quatro propostas.
Não existe oposição à TxPipe enquanto equipe. A TxPipe possui grande reputação no ecossistema Cardano e é um dos principais times responsáveis pelo desenvolvimento de componentes relevantes da infraestrutura técnica da Cardano. A equipe mantém diversos projetos open-source utilizados por outros desenvolvedores e participantes do ecossistema e apresenta um histórico amplamente positivo de conclusão de propostas financiadas anteriormente. Embora uma proposta tenha apresentado um atraso limitado de poucos meses, não parece existir um padrão mais amplo de atrasos prolongados ou falhas de execução. Em geral, a TxPipe demonstrou capacidade de entregar trabalhos financiados em prazos razoáveis.
Também existem sinais relevantes de que esses projetos não são puramente experimentais ou sem utilização. Os repositórios associados às propostas apresentam níveis significativos de atividade, engajamento, contribuições, forks, integrações e utilização por outros participantes do ecossistema. Considerando as dimensões relativamente limitadas da comunidade de desenvolvimento da Cardano, esse nível de engajamento indica que os projetos já demonstraram utilidade prática para desenvolvedores, provedores de infraestrutura e outros contribuidores.
Não será adotada uma conclusão independente sobre o grau exato de essencialidade técnica de cada projeto. Determinar o quanto Oura, Pallas, Dolos ou UTxO RPC são indispensáveis, quais alternativas estão disponíveis e quais consequências técnicas poderiam decorrer da interrupção da manutenção exige conhecimento especializado. Desenvolvedores com experiência direta nessas ferramentas e compreensão de suas respectivas dependências possuem melhores condições de avaliar sua importância estratégica e diferenciação técnica.
Embora as propostas indiquem o Pilar 2, Adoption and Utility, como seu principal alinhamento estratégico, essas atividades parecem estar mais diretamente relacionadas ao Pilar 1, Infrastructure and Research Excellence. Esses projetos não constituem iniciativas de adoção por si próprios. Eles oferecem infraestrutura técnica, bibliotecas, padrões ou componentes de acesso a dados que habilitam outras aplicações e serviços. Sua contribuição para adoção é, portanto, principalmente indireta, enquanto sua função imediata consiste em sustentar a infraestrutura da qual outras atividades do ecossistema dependem.
A principal preocupação está no orçamento. As propostas de manutenção solicitam o equivalente a US$ 105.000 para financiar um desenvolvedor part-time durante 12 meses, mas não definem adequadamente o que “part-time” representa. Não são informados o número esperado de horas semanais ou mensais, o percentual de dedicação equivalente a tempo integral, a taxa horária ou mensal, a senioridade específica do profissional financiado ou a distribuição estimada do tempo entre manutenção, suporte à comunidade, documentação, compatibilidade com o protocolo, melhorias e atividades relacionadas a inteligência artificial.
As propostas afirmam genericamente que o trabalho será realizado por desenvolvedores experientes em Rust e que haverá supervisão de um technical lead dedicado, cujo custo será absorvido pela p
- Yes299.1K ₳Rationale
We definitely want Pallas to be maintained!
- Yes298.3K ₳No rationale
- Yes271.8K ₳No rationale
- Yes260.4K ₳No rationale
- Yes227.9K ₳No rationale
- Yes215.5K ₳No rationale
- No191.2K ₳No rationale
- Yes182.3K ₳No rationale
- Yes167.9K ₳No rationale