IO: Cardano High Assurance Technical Collaboration

System 2mo ago1post

236 DReps voted · 75 with a rationale

Open a row to read the rationale.

  • Yes 534.3K ₳ Rationale

    All IO request IMO at non-negotiable at the point, No other team in the world can deliver the results at a cheaper rate.

  • Yes 487.1K ₳ No rationale
  • No 481.5K ₳ Rationale

    A PDF version of this rationale is also made available.

  • Yes 473.6K ₳ No rationale
  • Yes 466.2K ₳ No rationale
  • Yes 445.1K ₳ No rationale
  • Yes 443.5K ₳ Rationale

    I support all IO projects.

  • Yes 441.7K ₳ No rationale
  • Abstain 438.7K ₳ No rationale
  • Yes 426.2K ₳ No rationale
  • Abstain 385.6K ₳ Rationale

    Abstaining, as I’m part of the Cardano Constitution Committee Tingvard.
    Reading proposals and staying updated, just like you.
    Thanks to all fellow DReps who are also doing the hard work.
    Follow and DM me on X: @kenerik if you have any questions.

  • Yes 382.6K ₳ No rationale
  • No 377.3K ₳ No rationale
  • Yes 365.3K ₳ No rationale
  • Yes 332K ₳ No rationale
  • Yes 328.9K ₳ No rationale
  • Yes 327.1K ₳ No rationale
  • Yes 321.1K ₳ No rationale
  • Abstain 314.4K ₳ Rationale

    I am voting ABSTAIN. While I strongly support reinforcing Cardano’s high-assurance identity, I am deeply concerned that we risk spending over 13 million ADA on developer tools that may ultimately lack real-world adoption.

    A PDF version of this rationale is also made available.

    I have decided to vote ABSTAIN on the "IO: Cardano High Assurance Technical Collaboration" Treasury Withdrawal proposal.

    Cardano's reputation for security and correctness is its primary differentiator. In the minds of users, the security of the underlying protocol and the DApps built on top of it are deeply interlinked. A vulnerability in a major DApp damages the reputation of the entire ecosystem. Therefore, delivering automated formal verification tools to ensure our DeFi landscape is as secure as possible is an objective I fundamentally agree with.

    In fact, I consider ecosystem security so critical that I would normally be willing to overlook my usual strict requirements for budget transparency to protect the network's reputation. Once again, this proposal presents a financial "black box", with 86% of the requested ₳13,078,578 budget (amounting to ₳11,247,577) allocated broadly to "Development" without granular details. I have repeatedly expressed my frustration with this opacity in past IO proposals.

    However, the budget structure is not my primary reason for abstaining this time.

    My definitive reservation is the risk of non-adoption. The proposal aims to build a Container-Based Developer Environment (CBDE) and open automated formal verification tools (Blaster). Yet, the proposal itself explicitly acknowledges the risk that, without dedicated promotion and developer outreach, these tools might see low adoption despite on-time delivery.

    We cannot afford to fund a 13-million ADA public good if it ends up being underutilised or ignored by the developer community. Until there is a clearer, guaranteed pathway to ensure active developer onboarding and the integration of these tools into everyday workflows, I cannot confidently commit treasury funds to this endeavor.

  • Yes 313.1K ₳ No rationale
  • Yes 298.6K ₳ Rationale

    Voting YES on ALL IOG Withdrawals

    May 20th 2026

    Summery

    Nine treasury withdrawals from IOG totalling around 162M ada ($40M USD)

    Important Citation

    https://x.com/EdnStuff/status/2051321214728118360

    EdnStuff said the following on May 4th 2026

    I see the IO proposals as a package deal. But by all accounts I see most dreps only voting yes on a small selection of the 9. This is going to lead to some extremely lopsided, fragmented, and piecemeal results that will fall short of what we need on #Cardano 
    $ADA.
    

    Charles quote tweeted saying

    https://x.com/IOHK_Charles/status/2051376829949464792

    Sadly, this is the end result of a piecemeal roadmap. It's an iPhone by committee, with people deciding whether they prefer the fingerprint sensor to wireless charging. You end up with a bizarre, useless product.
    

    Statement

    There are a handful of people who, when they speak, I think it unwise not to listen to. Charles is one such person. His statement above makes this choice pretty easy.

    While we need to foster a wide ecosystem of R&D firms, we cannot afford to jeopardize our relationship with our biggest contributor. It is obvious and undeniable that the long-term success of Cardano remains dependent on the continued efforts of IO.

    I am voting for all of these IO proposals because Charles has made it clear that he does not believe Cardano can be successful without each of them, and it would be unwise to disregard his intuition.

    Signed,

    William Doyle

    Your friendly neighbourhood DRep!

    $computerman

    drep1yfpgzfymq6tt9c684e7vzata8r5pl4w84fmrjqeztdqw0sgpzw3nt

    https://x.com/william00000010

  • No 295.2K ₳ No rationale
  • No 279.5K ₳ No rationale
  • Yes 271.5K ₳ No rationale
  • Yes 261.3K ₳ No rationale
  • No 258.6K ₳ Rationale

    Review Methodology Disclaimer [EN]

    Due not only to the unusually high volume of Treasury Withdrawal Governance Actions and budget proposals submitted in April and May 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 — Cardano High Assurance

    1. Introduction

    Cardano High Assurance requests ₳13,078,578 from the Cardano Treasury to deliver automated formal verification tooling and a unified, containerized developer environment for secure and verifiable smart contract development on Cardano.

    The proposal is organized into two workstreams: Blaster, IO’s automated formal verification tool for Lean 4 and UPLC-based smart contracts, and CBDE, a Container-Based Developer Environment intended to reduce setup friction for developers using the Plinth high-assurance toolkit.

    The Blaster workstream includes DApp-level verification, language integrations for Aiken, Pebble, Scalus, and Futura, a VS Code extension, a Common Vulnerability Library, an equivalence checking tool, and proof reconstruction.

    The CBDE workstream includes a pre-configured environment with compilers, libraries, property-based testing, static analysis, formal verification, and profiling tools.

    The proposal presents this work as a way to make high-assurance development more accessible and to support Cardano’s positioning around correctness, security, and institutional-grade applications.

    2. Governance Action Analysis

    Positive aspects

    This vote should not be interpreted as opposition to formal verification, high-assurance development, developer tooling, or the technical capabilities of the teams involved.

    The proposal addresses a legitimate area of technical improvement for Cardano. Tools such as Blaster, language integrations, the Common Vulnerability Library, VS Code support, and the Container-Based Developer Environment may contribute to safer smart contract development and better developer experience over time.

    Negative aspects

    Technical value alone is not sufficient to justify treasury funding at this scale.

    The proposal requests ₳13,078,578, with ₳11,247,577, or 86% of the total budget, allocated to “Development.”

    While the proposal provides a high-level split between the Blaster workstream and the CBDE workstream, it does not provide enough granular detail on FTE allocation, team-by-team budget distribution, rate assumptions, seniority levels, subcontractor allocations, or the specific mapping between budget amounts and deliverables.

    For a multi-million-ADA treasury withdrawal, this level of budget abstraction is not sufficient for dReps and the community to assess whether the requested amount is proportionate, efficient, or properly scoped.

    This concern is consistent with the standard applied in previous votes. Large treasury requests require clear budget breakdowns.

    If dReps accept broad development categories without sufficient cost justification, it becomes difficult to enforce treasury discipline across the rest of the ecosystem.

    A second concern is the lack of sufficiently concrete and measurable impact targets.

    The proposal aligns itself with Cardano Vision 2030 and connects the work to KPIs such as TVL, monthly transactions, monthly active users, protocol revenue, and throughput capacity. However, many of these connections remain indirect, speculative, or difficult to verify.

    Formal verification may improve security and confidence, but the proposal does not clearly demonstrate how this work will materially move the needle on adoption, liquidity, transaction volume, developer retention, or ecosystem growth within a measurable timeframe.

    For example, the proposal states that CBDE could reduce a multi-day setup process to a 60-second initialization and expects a 3–5x increase in active Plinth developers within 12 months of release.

    These are relevant claims, but they would be stronger with clearer baselines, current developer counts, measurement methodology, and independently verifiable milestone targets.

    Risks and concerns

    The proposal acknowledges that delivery alone may not produce adoption.

    It states that community visibility and developer outreach are required to convert tool delivery into measurable MAU and KPI impact, but these activities are not fully funded within this proposal and depend on coordination with other initiatives.

    This weakens the link between the requested treasury spend and the broader ecosystem outcomes used to justify it.

    A third concern is prioritization.

    This proposal is a desirable technical addition rather than a pressing ecosystem need.

    It does not appear to be part of the direct continuity of core development or maintenance of existing critical infrastructure in the same way as some other IO-related proposals.

    It may improve the quality and security of Cardano’s technical stack over time, but it is not clear that this is among the most urgent constraints currently facing the ecosystem.

    Under the current Net Change Limit environment, this matters.

    The ecosystem is already directing substantial treasury resources toward infrastructure, protocol development, maintenance, scalability, and other technical initiatives. A significant share of these resources is also flowing to IO or IO-affiliated workstreams.

    The proposal itself states that IO and affiliated entities have already been allocated ₳130,708,860 across treasury-funded projects, with ₳78,459,777 withdrawn to date.

    That does not mean IO should be excluded from funding. IO remains an important technical contributor to Cardano.

    But repeated large allocations to the same organization increase the burden of transparency, cost justification, and prioritization.

    If treasury funding continues to concentrate heavily in infrastructure and IO-led initiatives, other crucial areas of the ecosystem may be left without sufficient funding.

    3. Vote and Rationale

    Vote: NO

    This treasury withdrawal is rejected primarily due to insufficient budget granularity, limited measurable impact targets, and concerns about prioritization under the current Net Change Limit constraints.

    The vote is based on three main concerns:

    1. Insufficient budget granularity for a proposal of this size.
    2. Insufficiently concrete impact metrics, targets, and baselines to evaluate contribution to Cardano Vision 2030.
    3. Weak prioritization under current NCL constraints, since this appears to be a desirable high-assurance tooling initiative rather than an urgent ecosystem need.

    This type of proposal would be more open to reconsideration if it included a more detailed budget breakdown, clearer team-level accountability, stronger KPI baselines and targets, measurable adoption criteria, and a clearer explanation of why this work should be prioritized over other competing treasury needs in this funding cycle.

    4. Conclusion

    The proposal addresses a valid technical area and may improve Cardano’s high-assurance development tooling over time.

    However, the requested funding is not supported by sufficient budget granularity, concrete impact measurement, or prioritization strength under current NCL constraints.

    For these reasons, the proposal cannot be supported in its current form.


    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 em abril e maio 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 — Cardano High Assurance

    1. Introdução

    A Cardano High Assurance solicita ₳13.078.578 do Tesouro da Cardano para entregar ferramentas automatizadas de verificação formal e um ambiente de desenvolvimento unificado e containerizado para desenvolvimento seguro e verificável de smart contracts na Cardano.

    A proposta é organizada em dois workstreams: Blaster, a ferramenta de verificação formal automatizada da IO para Lean 4 e smart contracts baseados em UPLC, e CBDE, um Container-Based Developer Environment destinado a reduzir a fricção de configuração para desenvolvedores que usam o toolkit de alta garantia Plinth.

    O workstream Blaster inclui verificação em nível de DApp, integrações de linguagem para Aiken, Pebble, Scalus e Futura, uma extensão para VS Code, uma Common Vulnerability Library, uma ferramenta de equivalence checking e proof reconstruction.

    O workstream CBDE inclui um ambiente pré-configurado com compiladores, bibliotecas, testes baseados em propriedades, análise estática, verificação formal e ferramentas de profiling.

    A proposta apresenta esse trabalho como uma forma de tornar o desenvolvimento de alta garantia mais acessível e de apoiar o posicionamento da Cardano em torno de correção, segurança e aplicações de nível institucional.

    2. Análise da Ação de Governança

    Aspectos positivos

    Este voto não deve ser interpretado como oposição à verificação formal, desenvolvimento de alta garantia, ferramentas para desenvolvedores ou às capacidades técnicas das equipes envolvidas.

    A proposta aborda uma área legítima de melhoria técnica para a Cardano. Ferramentas como Blaster, integrações de linguagem, Common Vulnerability Library, suporte a VS Code e Container-Based Developer Environment podem contribuir para um desenvolvimento de smart contracts mais seguro e uma melhor experiência para desenvolvedores ao longo do tempo.

    Aspectos negativos

    Valor técnico, por si só, não é suficiente para justificar financiamento do tesouro nesta escala.

    A proposta solicita ₳13.078.578, com ₳11.247.577, ou 86% do orçamento total, alocados para “Development.”

    Embora a proposta forneça uma divisão de alto nível entre o workstream Blaster e o workstream CBDE, ela não fornece granularidade suficiente sobre alocação de FTEs, distribuição orçamentária por equipe, premissas de rate, níveis de senioridade, alocações para subcontratados ou o mapeamento específico entre valores orçamentários e entregáveis.

    Para uma retirada de tesouro de vários milhões de ADA, esse nível de abstração orçamentária não é suficiente para que dReps e a comunidade avaliem se o valor solicitado é proporcional, eficiente ou adequadamente escopado.

    Essa preocupação é consistente com o padrão aplicado em votos anteriores. Grandes solicitações de tesouraria exigem breakdowns orçamentários claros.

    Se dReps aceitarem categorias amplas de desenvolvimento sem justificativa suficiente de custo, torna-se difícil aplicar disciplina de tesouraria no restante do ecossistema.

    Uma segunda preocupação é a falta de metas de impacto suficientemente concretas e mensuráveis.

    A proposta se alinha à Cardano Vision 2030 e conecta o trabalho a KPIs como TVL, transações mensais, usuários ativos mensais, receita do protocolo e capacidade de throughput. No entanto, muitas dessas conexões permanecem indiretas, especulativas ou difíceis de verificar.

    Verificação formal pode melhorar segurança e confiança, mas a proposta não demonstra claramente como esse trabalho irá mover materialmente a agulha em adoção, liquidez, volume de transações, retenção de desenvolvedores ou crescimento do ecossistema dentro de um período mensurável.

    Por exemplo, a proposta afirma que o CBDE poderia reduzir um processo de configuração de vários dias para uma inicialização de 60 segundos e espera um aumento de 3–5x no número de desenvolvedores Plinth ativos em até 12 meses após o lançamento.

    Essas são afirmações relevantes, mas seriam mais fortes com baselines mais claros, contagens atuais de desenvolvedores, metodologia de mensuração e metas de milestone independentemente verificáveis.

    Riscos e preocupações

    A proposta reconhece que a entrega, por si só, pode não produzir adoção.

    Ela afirma que visibilidade comunitária e outreach para desenvolvedores são necessários para converter a entrega das ferramentas em impacto mensurável em MAU e KPIs, mas essas atividades não são totalmente financiadas dentro desta proposta e dependem de coordenação com outras iniciativas.

    Isso enfraquece o vínculo entre o gasto solicitado do tesouro e os resultados mais amplos do ecossistema usados para justificá-lo.

    Uma terceira preocupação é priorização.

    Esta proposta é uma adição técnica desejável, e não uma necessidade urgente do ecossistema.

    Ela não parece fazer parte da continuidade direta do core development ou da manutenção de infraestrutura crítica existente da mesma forma que algumas outras propostas relacionadas à IO.

    Ela pode melhorar a qualidade e a segurança do stack técnico da Cardano ao longo do tempo, mas não está claro que esteja entre as restrições mais urgentes enfrentadas atualmente pelo ecossistema.

    No ambiente atual de Net Change Limit, isso importa.

    O ecossistema já está direcionando recursos substanciais do tesouro para infraestrutura, desenvolvimento de protocolo, manutenção, escalabilidade e outras

  • Yes 257K ₳ Rationale

    I am voting YES on “IO: Cardano High Assurance Technical Collaboration.”
    This proposal extends already‑proven formal verification work on Cardano (Blaster on real production contracts such as stablecoin and DeFi protocols) into a full DApp‑level toolkit, with clear, testable deliverables across UPLC equivalence checking, DApp‑wide proofs, a Common Vulnerability Library, multi‑language integrations, and a container‑based development environment (CBDE). It is one of the few proposals that directly strengthens Cardano’s long‑term differentiator—high assurance smart contracts—at a time when AI‑assisted attacks and complex DeFi systems increase the cost of getting security wrong.
    The budget is mid‑sized relative to other 2026 technical proposals and is heavily weighted toward engineering work by multiple ecosystem teams, not overhead. I share other DReps’ concerns about IO’s large cumulative treasury allocation and the lack of FTE‑level cost breakdowns per partner, and I expect any future high‑assurance or Blaster‑related funding requests to provide more granular financial transparency and clearer ex‑post reporting before I would support another tranche at this scale. However, on balance, I consider this a justified, one‑time investment in shared high‑assurance infrastructure: even a single major exploit prevented over the coming years would likely exceed the value of this ask, and the resulting tooling will be available to all Cardano developers, not just its authors.

  • No 245K ₳ Rationale

    Most active Cardano developers will not use formal verification tooling in the near term, and the institutional TVL benefit that justifies the investment scale is a long-tail outcome. With all of the other developments being proposed, adding 13.08M ADA for tooling with a narrow current addressable audience is not the best use of the remaining budget. Resubmit in a future cycle once Blaster adoption among Cardano developers has broadened to justify the investment scale.

  • Yes 237.5K ₳ No rationale
  • Yes 234.1K ₳ No rationale
  • A$Y
    Abstain 215.5K ₳ No rationale
  • Yes 212.5K ₳ No rationale
  • No 208.6K ₳ Rationale

    I'm increasingly concerned about Cardano's overall treasury spend rate, especially following the recent approval of the Draper/Dragon Orion Fund. To provide a necessary counter-balance, I am defaulting to NO on treasury withdrawals at this time.
    This proposal (₳13 M) is important infrastructure work, but it does not meet my strict criteria for approval right now. It is not core/critical infrastructure such as IO Hydra L2 production hardening or deliverables directly required to advance the Midnight partnership.
    I will continue voting YES only on the highest-priority items that directly strengthen essential scaling and partnership infrastructure.

  • Yes 207.3K ₳ No rationale
  • Yes 206.4K ₳ No rationale
  • Yes 203.6K ₳ No rationale
  • No 190.9K ₳ No rationale
  • Abstain 190.2K ₳ No rationale
  • No 183.7K ₳ No rationale
  • Yes 182K ₳ No rationale
  • Yes 181.9K ₳ No rationale
  • Yes 180.9K ₳ No rationale
  • TNT
    Yes 142.3K ₳ No rationale
  • Yes 137.3K ₳ No rationale
  • Yes 131.7K ₳ No rationale
  • Abstain 131.6K ₳ No rationale
  • Yes 127.9K ₳ No rationale
  • Yes 120.8K ₳ No rationale
  • Yes 120.1K ₳ No rationale
  • Yes 115.6K ₳ No rationale