Withdraw 540,750 ada for Oura by TxPipe: Maintaining Cardano’s Event Pipeline
116 DReps voted · 36 with a rationale · 3 changed their vote
Open a row to read the 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に賛成します。
Ouraは、Cardano nodeからon-chain eventsを検知し、indexing、monitoring、analytics、webhook、queue、databaseなどへ接続する重要なOSS event pipelineです。これは特定dAppのための私的開発ではなく、Cardanoの開発者・運用者・インフラ事業者が再利用できる公共財性の高いDevX基盤です。
また、OuraはTxPipeのPallasを基盤にしたRust-native toolingであり、Cardanoのdata access layerと実利用層の分散性を高める効果があります。資金額も中規模で、Intersect管理のSmart Contract Disbursement、milestone-based controls、oversight committee、dashboard透明性を備える点も、Treasury資金管理として評価できます。
I vote Yes on this Treasury Withdrawal.
Oura is an important open-source event pipeline for Cardano. It detects on-chain events from Cardano nodes and connects them to indexing, monitoring, analytics, webhooks, queues, databases, and other off-chain systems. This is not private development for a single dApp. It is reusable DevX infrastructure that benefits Cardano developers, infrastructure operators, and downstream projects.
Oura is also Rust-native tooling built on TxPipe’s Pallas library, which strengthens Cardano’s data access layer and improves decentralization at the practical infrastructure level. The requested amount is moderate, and I also value the use of Intersect-managed Smart Contract Disbursement, milestone-based controls, external oversight, and dashboard transparency.
- Abstain2.5M ₳No rationale
- No2.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
These Intersect excerpts are tedious.
But given this is mature, open-source infrastructure, that is already widely used in the Cardano ecosystem to stream blockchain events, it has my support. - Yes2.1M ₳No rationale
- Yes2.1M ₳Rationale
I am voting YES on the TxPipe Oura proposal.
Oura is useful open-source developer and infrastructure tooling for Cardano. It provides a Rust-native event pipeline that connects to Cardano nodes, monitors blockchain activity, filters relevant events, and routes those events to downstream systems such as databases, webhooks, queues, analytics services and application backends.
This matters because many wallets, dApps, explorers, governance tools, indexers, monitoring systems and analytics platforms need reliable ways to process Cardano events without each team having to build and maintain custom event-pipeline infrastructure from scratch.
In the current NCL environment, I believe DReps need to be selective. My priority is to support focused proposals that maintain essential public goods, open-source infrastructure, developer tooling, protocol compatibility and the technical rails that Cardano builders rely on.
Oura fits that framework.
This is not a speculative growth proposal. It is a modest, scoped maintenance request for an existing open-source tool. The work covers dependency updates, Cardano protocol compatibility, performance improvements, bug fixes, documentation, community support, issue triage, review of external contributions and continued improvements based on ecosystem feedback.
I also view it positively that Oura is built on Pallas, has an active open-source footprint, and supports a wide range of data sources and output sinks. That makes it useful for production infrastructure, low-resource setups, monitoring, indexing, analytics and real-time event processing.
The 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.
While I rank Oura slightly below the most foundational TxPipe proposals such as Pallas and Dolos, I still consider it a valuable part of the Cardano developer infrastructure stack. Under my “fund the rails before the growth bets” approach, this is the kind of practical maintenance work the treasury should support.
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 ₳Rationale
I vote Yes for Oura by TxPipe, recognizing its essential role in maintaining a core component of Cardano’s developer infrastructure. The proposal aligns with key ecosystem priorities, however, the ₳541K budget demands stronger justification tied to measurable outcomes.
I'd also like better clarification on why Oura remains uniquely indispensable compared to other indexing solutions to avoid redundant spending.
- 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 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 deserves this and all the the proposals as the value they continue to show is remarkable. Brillant team that will deliver.
- Yes480.2K ₳No rationale
- Yes444.7K ₳No rationale
- Yes415.3K ₳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
- Yes314.6K ₳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
TxPipe has a well earned reputation for building and maintaining great tools. I want these tools to continue existing.
- Yes298.3K ₳No rationale
- Yes271.8K ₳No rationale
- Yes260.4K ₳No rationale
- Yes215.5K ₳No rationale
- No191.2K ₳No rationale
- Yes182.3K ₳No rationale
- Yes167.9K ₳No rationale