Withdraw 540,750 ada for UTxO RPC by TxPipe: Maintaining Cardano’s Integratio...
115 DReps voted · 37 with a rationale · 4 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. - Yes4.2M ₳No rationale
- 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.6M ₳Rationale
私は本Treasury Withdrawalに賛成します。
UTxO RPCは、簡単に言えば、CardanoなどのUTxO型ブロックチェーンにアクセスするための共通API仕様です。Cardano node、Amaru、Dingo、Dolos、wallet、indexer、developer toolingなどがCardanoデータへアクセスするための共通インターフェース標準であり、特定dAppの私的開発ではなく、Cardano全体で再利用可能なOSS DevX基盤です。
さらに、UTxO RPCがCardano専用ではないことは弱点ではなく、むしろUTxO系エコシステムで共有できる標準としての波及効果を持ちます。Cardano node実装群で採用され、UTxO型ブロックチェーン間で共通化が進めば、Cardanoのdata access layer、developer experience、client diversityを強化し、CardanoがUTxO標準化の中心的な役割を担う可能性があります。
また、本提案はIntersect管理のSmart Contract Disbursement、TRSC/PSSC、milestone-based controls、oversight committee、dashboard透明性を備えており、Treasury資金管理としても評価できます。
I support this Treasury Withdrawal.
UTxO RPC is, simply put, a common API specification for accessing UTxO-based blockchains such as Cardano. It provides a shared interface for Cardano node, Amaru, Dingo, Dolos, wallets, indexers, and developer tooling to access Cardano data. This is not private development for a specific dApp, but reusable OSS DevX infrastructure for the broader Cardano ecosystem.
The fact that UTxO RPC is not Cardano-only is not a weakness. Rather, it gives the project broader value as a standard that can be shared across the UTxO ecosystem. If it continues to be adopted by Cardano node implementations and becomes more common across UTxO-based blockchains, it can strengthen Cardano’s data access layer, developer experience, and client diversity, while positioning Cardano as an important contributor to UTxO standardization.
I also value the funding design of this proposal. It uses Intersect-managed Smart Contract Disbursement, TRSC/PSSC, milestone-based controls, an oversight committee, and dashboard transparency. These are positive elements for responsible Treasury fund management.
- 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.
- Yes2.3M ₳No rationale
- Yes2.1M ₳Rationale
Although this treasury withdrawal action is only a partial excerpt of the original proposal from the Intersect budget process and remains underdefined here, I consider this to be important work: It focuses on maintenance, evolution and useful standards for supporting the ecosystem.
- Yes2.1M ₳No rationale
- Yes2.1M ₳Rationale
I am voting YES on the TxPipe UTxO RPC proposal.
UTxO RPC is important developer infrastructure for Cardano because it helps standardise how applications, tools, SDKs and services interact with UTxO-based blockchain data.
This is not the same as funding another hosted API provider like Blockfrost or Koios. UTxO RPC sits at a different layer. It is an open interface specification that can be implemented by different backends and used across multiple languages and developer environments.
That matters because Cardano needs more interoperability, less integration fragmentation, and better developer experience. A common interface for UTxO-based data access can make it easier for wallets, dApps, indexers, SDKs, infrastructure providers and future tooling to communicate in a consistent way.
In the current NCL environment, I believe DReps need to be selective. My priority is to support scoped proposals that maintain essential public goods, open-source infrastructure, developer tooling, protocol compatibility and the technical rails that Cardano builders rely on.
UTxO RPC fits that framework.
The proposal is modest in size compared with many other live treasury requests and is focused on maintenance, compatibility, SDK support, documentation, community support and continued improvement of a standard already used by several ecosystem workstreams.
I also view it positively that this proposal is structured through the 2026 treasury management framework, with Intersect administration, oversight controls, milestone-based disbursement and community auditability.
There is some overlap with other data access tools and providers in the ecosystem, but I do not see that as a reason to reject it. Cardano benefits from having open, interoperable, self-hostable and implementation-neutral standards that reduce reliance on any single provider or integration path.
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
- Yes1.3M ₳No rationale
- Yes1.2M ₳No rationale
- Yes1.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
- Yes862K ₳No rationale
- Yes830.3K ₳Rationale
We support Intersect's budget process. This proposal is part of it.
- Yes799.1K ₳No rationale
- Yes795K ₳No rationale
- Yes620K ₳No rationale
- Yes608.1K ₳No rationale
- Yes590K ₳Rationale
Supporting the withdrawal for the proposal to get underway
- Yes587.6K ₳No rationale
- Yes535.2K ₳Rationale
Critical and good deal.
- 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!
- NoRevoted365.9K ₳History
Earlier votes
No1mo agoSuperseded
- 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
I think this is a reasonable price to pay for UTxO RPC to not die. Framing it in such dramatic terms makes me grateful for this treasury and our ability to use it to stave of death for many important projects during this particularly brutal winter. I'm glad that Cardano doesn't live or die on the whims of a handful of VCs.
- Yes298.3K ₳No rationale
- Yes271.8K ₳No rationale
- Yes260.4K ₳No rationale
- Yes227.9K ₳No rationale
- Yes215.5K ₳No rationale
- Yes191.2K ₳No rationale
- Yes182.3K ₳No rationale
- Yes167.9K ₳No rationale
- Yes162.9K ₳No rationale