AURORA: Open infrastructure for bringing real credit markets to Cardano.
22 DReps voted · 11 with a rationale · 1 re-voted unchanged
Open a row to read the rationale.
Voting concentration
2 of 22 DReps cast half of the voted power.
Largest voter 38.5%, top 5 combined 87.3% of 1.2B ₳ voted.
- NoRevoted477.4M ₳Rationale
I vote NO on “AURORA”.
1.There is no track record, evidence or target for demand. Track record: cardano-loans, which this proposal builds on, has no recorded use on mainnet (checked with DBSync: zero beacons for loan requests, loan offers or active loans). On testnet there are only a few, created as examples for its guide. Evidence: no named lenders or borrowers who have committed to use it, and no letters of intent, are given. Target: adoption is not part of how delivery is measured, and there is no target for mainnet operation or usage.
2.The technical part can be built small. Using AI-assisted coding, I implemented this proposal’s requirements, except the third-party reviews and including a testnet demonstration, in about 25 minutes and about 1,300 lines of code (about 2,100 lines including specifications and documentation). It is first-version quality and not ready to use as is. What I want to point out is that the biggest hurdle for this proposal is not technical implementation but adoption: getting people to use it. Having no track record, evidence or target for that is, I believe, the biggest risk. The output, including the testnet transactions, can be checked here: https://adatool.net/open-credit-discovery
3.The track record does not match the size. Fairway has received Catalyst funding three times, but I could not find a track record in lending or market infrastructure. I also could not find any sign that their hiring and identity projects (two completed, and F12 with its final milestone under review) used Cardano mainnet. For F12 (Ethiopia national ID), the team’s own close-out report says Cardano was not used in the pilot. This request is about ten times their largest grant.
「AURORA」にNOを投票します。
1.需要の実績・根拠・目標がありません。 実績：提案が土台にしているcardano-loansは、メインネットで使われた記録がありません（DBSyncで確認。借入の申込み・貸出の申込み・成立した貸付のビーコンとも0件）。テストネットでも、手順書の例として作られた数件だけです。 根拠：使うことを約束した貸し手・借り手の名前や、意向表明の記載がありません。 目標：採用は成果の評価対象外で、メインネットでの稼働や利用の目標はありません。
2.技術の部分は、小さく作れます。 第三者レビューを除くこの提案書の要件（テストネットでの実演を含む）を、AIのコーディング支援を使って約25分、コード約1,300行（仕様・文書を含めて約2,100行）で実装しました。初版の品質で、そのまま使えるものではありません。ここで伝えたいのは、この提案の最大のハードルは技術の実装ではなく、採用＝使ってもらうことにある、という点です。そこに実績も根拠も目標もないことが、最大のリスクだと考えます。 成果物（テストネットの取引を含む）は次で確認できます。 https://adatool.net/open-credit-discovery
- 実績と規模が釣り合っていません。 FairwayはCatalystで3件の資金を得ていますが、貸付や市場の仕組みに関する実績は見つけられませんでした。また、人材・IDの案件（完了した2件と、最後のマイルストーンが審査中のF12）でも、Cardanoのメインネットが使われた形跡は見つけられませんでした。F12（エチオピアの国民ID）では、チーム自身の完了報告が「試験導入ではCardanoを使っていない」と書いています。今回はその最大の助成の約10倍の規模です
Earlier votes
No2d agoSuperseded
I vote NO on “AURORA”.
1.There is no track record, evidence or target for demand. Track record: cardano-loans, which this proposal builds on, has no recorded use on mainnet (checked with DBSync: zero beacons for loan requests, loan offers or active loans). On testnet there are only a few, created as examples for its guide. Evidence: no named lenders or borrowers who have committed to use it, and no letters of intent, are given. Target: adoption is not part of how delivery is measured, and there is no target for mainnet operation or usage.
2.The technical part can be built small. Using AI-assisted coding, I implemented this proposal’s requirements, except the third-party reviews and including a testnet demonstration, in about 25 minutes and about 1,300 lines of code (about 2,100 lines including specifications and documentation). It is first-version quality and not ready to use as is. What I want to point out is that the biggest hurdle for this proposal is not technical implementation but adoption: getting people to use it. Having no track record, evidence or target for that is, I believe, the biggest risk. The output, including the testnet transactions, can be checked here: https://adatool.net/open-credit-discovery
3.The track record does not match the size. Fairway has received Catalyst funding three times, but I could not find a track record in lending or market infrastructure. I also could not find any sign that their hiring and identity projects (two completed, and F12 with its final milestone under review) used Cardano mainnet. For F12 (Ethiopia national ID), the team’s own close-out report says Cardano was not used in the pilot. This request is about ten times their largest grant.
「AURORA」にNOを投票します。
1.需要の実績・根拠・目標がありません。 実績：提案が土台にしているcardano-loansは、メインネットで使われた記録がありません（DBSyncで確認。借入の申込み・貸出の申込み・成立した貸付のビーコンとも0件）。テストネットでも、手順書の例として作られた数件だけです。 根拠：使うことを約束した貸し手・借り手の名前や、意向表明の記載がありません。 目標：採用は成果の評価対象外で、メインネットでの稼働や利用の目標はありません。
2.技術の部分は、小さく作れます。 第三者レビューを除くこの提案書の要件（テストネットでの実演を含む）を、AIのコーディング支援を使って約25分、コード約1,300行（仕様・文書を含めて約2,100行）で実装しました。初版の品質で、そのまま使えるものではありません。ここで伝えたいのは、この提案の最大のハードルは技術の実装ではなく、採用＝使ってもらうことにある、という点です。そこに実績も根拠も目標もないことが、最大のリスクだと考えます。 成果物（テストネットの取引を含む）は次で確認できます。 https://adatool.net/open-credit-discovery
- 実績と規模が釣り合っていません。 FairwayはCatalystで3件の資金を得ていますが、貸付や市場の仕組みに関する実績は見つけられませんでした。また、人材・IDの案件（完了した2件と、最後のマイルストーンが審査中のF12）でも、Cardanoのメインネットが使われた形跡は見つけられませんでした。F12（エチオピアの国民ID）では、チーム自身の完了報告が「試験導入ではCardanoを使っていない」と書いています。今回はその最大の助成の約10倍の規模です
- No289.8M ₳No rationale
- Abstain128M ₳Rationale
I abstain on this proposal at this stage. I recognize the value of shared discovery and verification infrastructure for Cardano credit markets, the commitment to release the funded outputs under Apache License 2.0, and the proposed independent fund-management structure.
However, the public materials do not provide enough evidence of prospective adopting lending services or capital providers, their expressed interest, specific needs, or integration plans to assess whether demand and expected benefits justify the 940,000 ADA expenditure. A pilot vision is presented, but completing technically usable infrastructure and validating demand for its sustained use are separate challenges.
I would like to see evidence supporting adoption prospects, such as expressions of interest from prospective adopters, jointly validated requirements, and identified pilot participants, timelines, and evaluation metrics. I do not require guaranteed usage or revenue from public-infrastructure development. However, I currently lack sufficient evidence to reach a confident decision either way and therefore abstain.
僕は現時点では本提案に棄権します。Cardanoの貸付市場に共通の検索・検証基盤を整備する意義と、成果物をApache 2.0で公開する方針、独立した資金管理の設計は評価しています。
一方、公開資料からは、この基盤を実際に採用する貸付サービスや資金提供者、その利用意向・具体的な課題・導入計画を十分に確認できず、94万ADAの支出に見合う実需と効果を判断する材料が不足しています。実証に向けた構想は示されていますが、技術的に利用可能な基盤の完成と、継続的な利用につながる需要の検証は別の課題です。
初期導入を検討する組織からの意向表明、共同で確認した要件、実証の参加者・時期・評価指標など、採用可能性を裏付ける情報を示してほしいと考えます。公共基盤の開発に利用実績や収益の保証を求めるものではありませんが、現段階では賛否を決める確信を持てないため、棄権します。
- No94.8M ₳Rationale
As a DRep, I decided to vote NO on the proposal: AURORA: Open infrastructure for bringing real credit markets to Cardano.
My rationale:
The proposal identifies a potentially useful infrastructure concept, but it does not demonstrate that there is a market ready to use it. The proposed software can be built, but we must demand more than that.
First, the product may be technically complete but economically dead. A discovery engine cannot create loan supply, credible originators, or capital providers. The central challenge is not building an indexer, metadata schema, or API. It is bringing real credit opportunities and capital to the market. The proposal does not provide sufficient evidence that this demand exists.
Second, there are no adoption or mainnet KPIs. Delivery is measured through specifications, testnet functionality, open-source code, documentation, and a technical demonstration. These are useful outputs, but they do not demonstrate that the infrastructure has been integrated, used, or validated by real market participants.
Third, there is a serious risk of creating a "standard without an ecosystem." A shared standard becomes valuable only when multiple independent lending implementations, originators, applications, and capital providers actually adopt it. No concrete integration commitments or credible adoption pathway are presented. Without them, AURORA risks becoming a well-documented reference implementation rather than a shared Cardano market infrastructure.
Fourth, the milestones pay for technical artifacts rather than demonstrated utility. Significant funds can be released after publication of specifications and testnet components, while there is still no requirement for a mainnet integration, a real credit opportunity, a committed capital provider, or measurable usage.
For comparison, the Catalyst process has set a very high bar for funding. Teams requesting up to 200,000 ADA are expected to demonstrate quality of the team, adoption potential, technical feasibility, marketing and go-to-market thinking, realistic milestones, and value for money. This proposal requests 940,000 ADA, yet it does not provide comparable evidence in the areas that matter most for its success.
As a DRep, I want funding rules to become stricter and to be applied consistently. I am not saying on-chain governance must copy the Catalyst standard exactly. However, I would like on-chain governance to move in the same direction: stronger evidence, clearer accountability, and a higher burden of proof for large Treasury withdrawals.
If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.
MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8My DRep ID:
drep1y2m0g4r66...skqwqpBuy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0 - Abstain93.6M ₳No rationale
- No62M ₳Rationale
I am voting No on this proposal. This year's Net Change Limit (NCL) has been set well above the level I consider sustainable. Under my published voting framework, an appropriate NCL is roughly 15% of the previous year's staking rewards (on the order of 82M ADA), whereas the NCL currently in force is several times that amount. Because the treasury is already authorized to disburse far beyond my personal NCL threshold, I am voting No on all treasury withdrawal proposals until aggregate withdrawals are brought back within a sustainable limit — regardless of the individual merits of any single proposal. This vote reflects a position on total treasury spend, not a judgment on the value of your specific project. Reference: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem/\n\n[Japanese version follows]\n\n本提案に反対票を投じます。今年のNet Change Limit（NCL）は、私が持続可能と考える水準を大幅に上回って設定されています。公開済みの投票フレームワークでは、適正なNCLは前年のステーキング報酬の約15%（82M ADA）ですが、現行のNCLはその数倍に達しています。トレジャリーは既に私のpersonal NCL（個人として許容する上限）を大きく超える出金が認められている状態にあるため、出金総額が持続可能な範囲に戻るまで、個別提案の良し悪しに関わらず、すべてのトレジャリー出金提案に反対票を投じます。本投票はトレジャリー支出全体に対する立場の表明であり、貴提案の価値そのものを否定するものではありません。参照: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem-jp/
- No43.7M ₳No rationale
- No20.2M ₳No rationale
- Yes10.8M ₳No rationale
- No6.8M ₳No rationale
- Yes5.1M ₳Rationale
This is a small, five-month project to build free, open tools that help people find and compare lending opportunities on Cardano. The money is held by independent people, it’s paid out only as each stage is delivered, and it’s checked by outside auditors along the way. I support it, and I’ll be watching to see whether real lenders start using it.
- Yes3.1M ₳Rationale
私は本Treasury WithdrawalにYESと投票します。
AURORAは、CardanoのRWA成長戦略において、将来の信用市場の拡大を支える重要な市場接続インフラです。複数の貸付プロトコルや金融機関が共通して利用できるオープンな基盤を整備することには、長期的な公共的価値があります。
開発の頓挫や採用不足のリスクはありますが、提案チームの実績、成果物のオープンソース化、段階的な資金管理を評価し、Cardanoに必要な基盤への投資として支持します。
一方、資金管理については改善を期待します。特に、前払い資金の保全・回収方法、開発中断時の未完成成果物の公開と引継ぎ、未使用資金の確実なTreasury返還について、より明確で実効性のある仕組みを求めます。
I vote YES on this Treasury Withdrawal.
AURORA is an important piece of infrastructure for Cardano’s RWA strategy, supporting the future growth of credit markets. Its open, shared infrastructure could provide long-term value by enabling multiple lending protocols and financial institutions to connect and operate more efficiently.
Despite the risks of development failure and limited adoption, I support this investment based on the team’s track record, open-source commitments, and milestone-based funding structure.
However, I expect stronger Treasury fund safeguards, particularly clearer mechanisms for protecting and recovering advance payments, releasing and transferring unfinished work if development stops, and ensuring unused funds are returned to the Cardano Treasury.
- No1.8M ₳Rationale
BKIND votes No. AURORA asks 940,000 ada to index a credit market that does not exist on mainnet. The lending model it builds on has never been used there, no lender or protocol has committed to it, delivery ends on testnet, and most of the money is a fixed fee paid in advance.
Action: treasury withdrawal 14d6a48df8b909...b01b#0, 940,000 ada to the script stake address stake179uthrjzt0395mukqctux9u2zchytk5py4hr0xd9ka7jtdqa9jgyq under the current constitution's guardrails script, fa24fb305126805cf2164c161d852a0e7330cf988f1fe558cf7d4a64. I verified on chain that the action withdraws exactly this amount to that credential, that the credential is a native script requiring 3 of 5 signatures, published on chain on 16 October 2026, and that the proposal document hashes to the on-chain anchor, 2791bc5d48adfdb1d56b072891cfe0cd1e7235941e157d3c45774ea29b468fb1. The document carries no author signature.
What I support. Open standards and shared infrastructure can add real value to Cardano, and a working credit market on Cardano would. My No is to paying for that infrastructure before there is anything for it to serve.
No market to serve. AURORA indexes credit opportunities held as individual Loan Request UTxOs and made discoverable through beacon tokens. That is the model of cardano-loans, the protocol of the proposal's technical advisor, which the proposal cites as "directly relevant architectural experience". I checked my own db-sync. The loan validator of cardano-loans version 1 and version 2, b07bdac32910d4c1ea425edadf87ebbe1393394ee36623e97e1d14cc and 9ea2fdfeb892c9b62cdb42f004a606cd39dd5edd0b9833d8ad6dcf09, has never held an output on mainnet, and no minting policy on mainnet has minted an Ask, Offer or Active token in more than one transaction. The protocol's own guide states: "Registration has already been done for all scripts for the preproduction testnet." On mainnet there are no loan requests for AURORA to discover.
No demand shown. The proposal names no lending protocol that will adopt AURORA, and no lender, borrower, capital provider or letter of intent. It states the risk itself: "Open standards do not guarantee adoption by future lending protocols, applications or capital providers." And it leaves adoption out of what is measured: "Treasury delivery is measured by the completion and usability of the public infrastructure rather than by speculative adoption targets." The word mainnet does not appear in the full proposal. Delivery "culminates in an end-to-end testnet demonstration", and nothing after the five months is funded.
A fixed fee, paid in advance. 800,000 ada, 85 percent of the request, is "a fixed implementation fee payable to Fairway", paid "rather than reimbursed against Fairway's actual internal costs". The proposal shows no staffing, hours or rates. "Funding is released in advance for each implementation stage": 140,000 ada at commencement before anything is delivered, up to 460,000 ada after the first milestone, 750,000 ada after the second and the full 940,000 ada after the third. The money for the final independent review and release may leave custody before that work is done. Unused review, hosting and contingency funds may become "additional implementation payments to Fairway".
Limited protection for the treasury. The 3 of 5 multisignature holds only what is not yet paid out. "Implementation instalments leave this custody structure when transferred to Fairway", and on termination only the "ADA remaining under administrator custody" returns to the treasury. The administrators check that outputs "reasonably satisfy the approved completion criteria" and "are not expected to reproduce the engineering work or independently reimplement AURORA."
BKIND votes No: 940,000 ada for infrastructure that has no market to serve on mainnet, measured without adoption and paid largely in advance, is a promise, not evidence (govActionId 14d6a48df8b909...b01b#0).
- No1.6M ₳No rationale
- No1.1M ₳Rationale
Would rather like to see this an application first to prove product/market fit then come back to the treasury to open source to make available to others. It would then also justify more than the amount currently asked for.
- No609.3K ₳Rationale
This proposal as submitted is unconstitutional and fails the metadata immutability requirement of Article II.6.1.
A PDF version of this rationale is also made available.
This proposal as submitted is unconstitutional and fails the metadata immutability requirement of Article II.6.1.
- No194.5K ₳No rationale
- No142.5K ₳Rationale
AURORA: Open infrastructure for bringing real credit markets to Cardano — Voting Rationale
Governance Voting Rationale GAID gov_action1znt...jnuq3n Title AURORA: Open infrastructure for bringing real credit markets to Cardano. Type of GA Treasury Withdrawal Amount ₳940,000 (≈ USD 188,000 at the proposal's reference rate of USD 0.20) Recipient (on-chain) Script stake credential 78bb8e42…25b4(the proposed 3-of-5 AURORA Treasury multisignature)Date submitted 18 October 2026, 21:14 UTC (epoch 662) Expiration Date Epoch 669 (≈ 20 November 2026)
Contents
- 1.0 Introduction
- 1.1 Summary
- 1.2 Description of Governance Action
- 2.0 Discussion
- 2.1 Method
- 2.2 What this proposal gets right, stated properly
- 2.3 The strongest case, and the seam inside it
- 2.4 A document that can still be moved
- 2.5 Who holds the keys, and to whom they answer
- 2.6 A fixed fee, paid forward, with the last gate in the wrong place
- 2.7 An open standard and the company around it
- 2.8 What is already there, and what gets remembered about borrowers
- 2.9 What the commons retains
- 2.10 Why this is a No and not an abstention
- 2.11 Fiduciary verification (external instrument)
- 2.12 What would make this a Yes
- 2.13 What the vote does not reach
- 3.0 Conclusion
- Sources
- Appendix: Published Sort and Instrument Record
1.0 Introduction
1.1 Summary
We are voting NO (remediable) on AURORA, and this is a No I would have preferred not to reach. I came to this proposal disposed in its favor. It is an infrastructure ask of modest size, priced well below what the breadth of work would cost on the open market, whose outputs are open-licensed, whose acceptance criteria require that a third party be able to deploy the software without the proposer, and whose funds are held by a custody body the implementer does not control. Those are the features this DRep has spent a year asking proposals to have, and they deserve to be named first rather than conceded last.
The No rests on four findings, each a property of this action and each repairable by the proposer. First, the governance action's anchor document sits at a location that can still be changed, and the full proposal that the anchor says defines the funding terms is referenced by a movable tag with no hash — the opposite of what the proposal's own submission section promises and of what the Constitution requires. Second, the custody body's independence, which is the proposal's central safeguard, is stated without qualification while the recipient's own website lists a person of the same name as one of the five signers on its advisory board. Third, the fee is fixed and paid in advance, so that the whole of it can leave custody before the independent security review, the legal review and the public release exist, and once it has left, nothing in the proposal brings any of it back. Fourth, the standards at the heart of the deliverable — how a credit opportunity is described, how a capital provider's requirements are expressed — would be authored and versioned by parties whose own commercial products sit at the layers immediately around them, with no stewardship terms and no disclosure in the proposal of that relationship.
None of these is an accusation, and none needs a different team or a smaller ambition. The external fiduciary instrument this DRep uses reaches No independently, on the immutability of the material terms, on the disclosure of related parties, and on continuity after the term; two instruments on unrelated foundations arriving at the same verdict is worth naming as what it is. I would expect to vote for a corrected version of this proposal, and this rationale is written to be useful to one.
1.2 Description of Governance Action
This Treasury Withdrawal requests ₳940,000 to fund approximately five months of work by Fairway Oy as lead implementer, with Sundial Protocol as technical collaborator and Fallen Icarus (Rusty) as technical advisor, to build open infrastructure for discovering, filtering and verifying individual credit opportunities on Cardano. The premise is that the extended UTxO model lets each loan request exist as its own on-chain object, and that what is missing is a shared market layer around those objects. The proposal names the deliverables as a versioned Metadata Standard for describing such "Loan Request UTxOs", a Verification Framework for attaching proofs and attestations to them, an open-source indexer it calls the Discovery Engine, open APIs and filtering tooling, a Capital Provider Profile Standard and Reference Query Library contributed with Sundial, developer tooling and a reference implementation, documentation, and independent security and legal review, culminating in an end-to-end testnet demonstration. Everything Treasury-funded is to be released under the Apache License 2.0. The proposal is explicit that AURORA does not originate loans, hold lending capital or decide what gets funded.
The budget allocates ₳800,000 as a fixed implementation fee to Fairway and ₳140,000 for supporting costs, itemised as about ₳60,000 for security and legal review, ₳20,000 for an independent audit of Treasury use, ₳30,000 for hosting and ₳30,000 for contingency. The fee is paid in instalments that are advances for the next stage of work rather than reimbursements, and is not reconciled against Fairway's internal costs; Fairway decides staffing, subcontracting and contributor compensation. Delivery runs across four milestones — specifications and architecture (month one), core build on testnet (months two and three), integration and demonstration (month four), and independent review and public release (month five) — against cumulative disbursement ceilings of ₳140,000 at commencement, ₳460,000 after the first milestone, ₳750,000 after the second and the full ₳940,000 after the third.
On-chain, the withdrawal is paid to a script credential, consistent with the proposal's statement that the full amount is received into a 3-of-5 multisignature held by five named "AURORA Treasury Administrators" — James "Blockjock" Meidinger, Christian Taylor, Elder Millennial, Wilco USDM and Eddie D — none of whom, the proposal says, is part of the implementation consortium. The administrators review milestone evidence, authorize installments, may suspend disbursement, and may approve reallocations between the supporting lines and implementation, including additional payments to Fairway, within the total. If the project terminates, ada still under administrator custody returns to the Treasury. The proposal discloses that Fairway has received Treasury-derived ada through Project Catalyst within the last twenty-four months, naming a Fund 12 identity project, and that it has received no prior Treasury Withdrawal for this scope. It commits to compliance with the Net Change Limit; at about ₳42.6 million of headroom remaining under the ₳500 million limit for epochs 613 to 713 on the public count of 16 October, this request is about two per cent of what is left.
2.0 Discussion
2.1 Method
Every governance action gets read; not every action earns the same reading. This DRep runs each one first through an intake that assigns depth before any merits are read, then reads the merits, and selects the vote last, under a discipline whose question is not whether a vote helps something pass but whether a warrant has been derived to deploy delegated stake against it. The full machinery is published in the appendix so that a reader who disagrees can locate whether the disagreement is with how deeply this was read or with what the reading found.
This action earned the deeper reading, and it is worth saying why, because it is not the amount. Most of what could go wrong here is contained: if the work were simply not delivered, the loss would be bounded by what had been advanced. What deepens the reading is what happens if the work succeeds. A metadata standard is valuable exactly to the extent that many independent parties publish to it and query against it, and a standard that has been adopted is a coordination point that cannot simply be forked away from, whatever its licence says. The question of who stewards that coordination point is easy to settle before anyone depends on it and progressively harder afterwards. That is the same shape this DRep read in the OpenZeppelin library proposal earlier this month — an action that would manufacture a dependency rather than service one — and the terms on which a dependency is created deserve to be read before it exists.
2.2 What this proposal gets right, stated properly
The construction of custody is better than anything this DRep has read at this size. The implementer holds no signing key. Funds that have not been released stay with five signers under a three-of-five threshold, undelegated from any pool and delegated to abstain. Conflicted signers must recuse and the threshold must still be met without them. Replacement of a signer requires public disclosure before funds move. Most proposals under a million ada send the withdrawal to the builder's wallet and ask for trust; this one separates the hand that builds from the hand that pays, which is the structural point.
The public-asset commitment is real and it is written where it binds. Apache 2.0 is permissive and patent-aware. More importantly, the acceptance criteria are written against the failure mode that usually hollows out open-source grants: the first milestone must show that the specifications do not require a single verification provider, lending implementation or hosted AURORA operator; the second that the indexer can be deployed without a Fairway-hosted API; the third and fourth that a technically capable third party can reproduce the principal workflow and then deploy and operate the infrastructure from the published materials. That is the right test of whether the commons actually holds what it paid for, and few proposals put it in the payment gates.
The value is stated in the right currency. Read for what its claim of value rests on, the proposal makes almost no appeal to quantities — no projected volumes, no market capitalisation of the opportunity, no adoption targets dressed as outcomes. It argues in terms of coordination capacity: shared descriptions instead of per-protocol ones, independent operators instead of one indexer, verification that different capital providers can evaluate against different policies, lending protocols left untouched and optional to integrate. It even declines, explicitly, to be measured by speculative adoption. That is the vocabulary this DRep's published burden asks for, and this proposal speaks it more fluently than most.
The price is not the problem. At the proposal's own reference rate, the implementation fee is about USD 160,000 for five months of a three-party consortium producing three specifications, an indexer, an API, tooling, a reference implementation and documentation. If anything the breadth is ambitious for the money, and the risk is breadth-to-budget rather than inflation. The proposal has also listened: its own revision history shows the ask falling from ₳2.9 million, including a Treasury-funded lending pilot, to ₳1 million and then to ₳940,000 for infrastructure alone, which is the posture of a proposer who expects to be corrected.
And the people are known. I know these teams from Project Catalyst, where they have been funded across several recent rounds and, as I understand it, were in line for further funding in Fund 15 before that round was paused; their milestone reporting there was in good order, though I hold that process to be a low bar and I give it weight accordingly. The consortium also includes a principal contributor to the open-source cardano-loans protocol, whose peer-to-peer lending design is directly relevant here and, on its own terms, unusually careful about discovery and reputation. That is not a credential I discount.
2.3 The strongest case, and the seam inside it
There is a case for this proposal that the proposal itself does not make, and it is stronger than the one it does make, so it is stated here before the findings.
This DRep's account of money treats it as a coordination protocol — a shared symbolic system for recording and settling the claims that productive exchange generates — rather than a store of value held in a vessel. On that account, a loan made to a working business is not an investment product. It is the most literal instance of the thing the unit indexes: a claim arising from productive activity, with a counterparty, a term and a settlement. Much of what passes for credit in on-chain finance is the opposite — collateral loops in which the claim points back at the token rather than outward at production. A proposal that makes individual productive claims legible on Cardano, one by one, with their histories intact and without pooling them into an opaque facility, is aiming at the relation this DRep's whole framework is built to protect.
That is a description, and from it I want to draw a conclusion — that the Treasury should fund the infrastructure that makes such claims legible. The step between the two is a crossing from what the commons is to what it ought to buy, and it is not deductive. A description of credit as productive claims does not by itself say who should hold the pen on the format in which those claims are written, nor that the commons should pay for that format before anyone has committed to publish in it. Everything that follows in this rationale lives on the far side of that seam. The relation is worth serving; the questions are about the terms on which this action would serve it.
2.4 A document that can still be moved
The first finding is procedural, and it would carry a No by itself.
The Constitution requires a governance action to point to a document whose content is fixed: the hosting location must be immutable and incapable of being altered after submission. This action's anchor is a raw file on the main branch of a public GitHub repository. Its hash on-chain matches the file today, which this DRep checked, so nothing has been altered; but the location is one that can be, and the Constitution's requirement is about the location, not about whether anyone has yet changed it. Inside that anchor, the reference labelled as the immutable full proposal is a GitHub release tag — a name that can be moved to a different commit or deleted — given without any hash. The abstract says that this full proposal forms part of the funding request and defines the architecture, deliverables, budget, milestones and funding terms. The material terms of the withdrawal therefore live in a document whose identity is guaranteed by nothing on-chain.
The proposal's own submission section commits to exactly the opposite: a canonical version on IPFS or equivalent content-addressed storage, referenced with a cryptographic hash, so that the version on-chain can be verified against the version the community reviewed. That commitment was the right one. It was not carried out, and I read it as an oversight in a submission finalized in its last hours rather than as anything else. This DRep reached the same finding on the copper reserve action this week and treated it there as sufficient on its own, and consistency is owed. The repair is mechanical: pin the anchor and the full proposal to content-addressed storage and reference both by hash.
2.5 Who holds the keys, and to whom they answer
The custody design is the strongest thing in this proposal, which is why the second finding matters more than its size suggests.
The proposal states that the five administrators are independent of the implementation consortium, and on the narrow reading that is true: none of them is Fairway, Sundial or Rusty, and none holds an implementation role. But Fairway's own website lists, on its advisory board, James Meidinger is described as business development lead for USDM, and the proposal names James "Blockjock" Meidinger as one of the five independent governance signers. This suggests that one of the people who will decide whether Fairway's milestones are accepted and its next advance released is Fairway's adviser. The table of signers also presents a second administrator with a USDM affiliation, so that two of five may share an outside employer; that is not a conflict with the recipient, but it is the kind of correlated exposure a three-of-five threshold is meant to avoid.
I want to be careful about what this finding is. An advisory role is often unpaid and nominal, and nothing here suggests any signer would act other than in good faith. The proposal's own conflict rule would also require a conflicted signer to abstain on a conflicted payment. But that rule is self-declared and per-transaction, and it does not cure the statement the electorate is asked to rely on, which is that the custody body is independent of the recipient. A reader weighing this proposal's safeguards would reasonably read that sentence as the one doing the most work. Who checks the checker is the question this DRep asks of every oversight structure, and the answer here has to be accurate on its face rather than accurate under a narrow construction. The repair is to disclose every relationship between the administrators and the consortium, including advisory and commercial ones, and either replace a signer who has one or state in advance that they are excluded from every decision touching Fairway's payments — with the threshold arithmetic shown to survive it.
2.6 A fixed fee, paid forward, with the last gate in the wrong place
The third finding is about where the payment gates sit, and it is the one that most changed between the version of this proposal that circulated for review and the version submitted.
A fixed-price contract is a legitimate instrument and in many ways a better one than reimbursement. It puts the risk of overrun on the vendor, it spares a small team the overhead of accounting to the Treasury for every invoice, and it lets the buyer judge outputs rather than inputs. The question with a fixed price is never whether the vendor's costs are reconciled; it is whether payment is tied to delivery tightly enough that the buyer keeps leverage until the thing bought exists. Here it is not. The instalments are advances for the next stage of work. After the third milestone is accepted, the cumulative ceiling reaches the full ₳940,000, so that Fairway's whole fee can be released before the fourth milestone begins. The fourth milestone is where the independent security review, the legal review, the final Treasury-use audit, the public release under Apache 2.0 and the demonstration that a third party can deploy the system all sit. Those are the deliverables that turn testnet software into a public asset, and they are the only ones with no payment attached to them.
Once ada leaves the multisignature, the proposal provides no route back. Refund on termination applies to funds still under administrator custody; advances are expressly not recalculated against cost, and release of an advance is said not to constitute acceptance of the work, but nothing says what happens to an advance for work that is never done. There is no agreement, no jurisdiction and no clawback. The administrators may also reallocate the supporting lines, including to additional payments to Fairway, which sits uneasily with the fee being fixed: a fixed fee that can be increased by the people who review the vendor is a ceiling, not a price, and the criterion on which it would be increased is not stated.
The earlier public version of this proposal held all funds in the multisignature until spent, reconciled Treasury transactions against reported expenditure, tied an interim review to the second milestone, required written justification for contingency and returned all unspent ada on termination. The submitted version replaced that with the fixed-fee advance model on the day of submission. I do not read that as a retreat. Reconciling a small consortium's spend is costly and arguably disproportionate at this size, and the change may well have been made to give the builders operating room they need. But the lighter instrument needed its own controls, and they did not come with it. The repair is narrow: hold back a meaningful part of Fairway's final instalment until the fourth milestone is accepted, write a recovery clause for advances against work not delivered, and say on what basis, if any, the fee may be increased.
2.7 An open standard and the company around it
The fourth finding is the one this DRep is best placed to see, and it is about stewardship.
The most durable thing this proposal would produce is not the indexer, which anyone can rewrite, but the standards: the Metadata Standard that says how a credit opportunity is described, the Verification Framework that says how evidence attaches to it, and the Capital Provider Profile Standard that says how a lender's requirements are expressed. Open standards practice treats the writing of a specification as one phase among several. Before it, the affected implementers are brought into scoping; after it, there is a launch and adoption effort and a standing process for review and change — someone who holds the editorial pen, a way to propose amendments, a record of objections. This proposal funds the writing phase and stops. There is no reference to the Cardano Improvement Proposal process, through which metadata conventions on Cardano are normally established, no named change-control process, no maintainer after month five, and no public comment period on the first milestone's specifications before they are accepted. The specifications would be reviewed by the administrators, who are not asked to judge them as standards.
That gap would matter for any author. It matters more here because of where the authors stand. The project website the governance action itself links to describes AURORA in terms the proposal does not: as the first stage of a venture whose economics at the infrastructure stage rest on issuance, verification, transactions and settlement services, followed after a Seed round by a regulated product layer for portfolios and asset management under the name AURORA Capital, with its funding plan for the current stage put as "get the AURORA infrastructure funded." Fairway's own website presents AURORA as one product in a line that also includes an identity and credential layer, a credit-intelligence layer offering risk models and attestations, a verified credit marketplace for loan-request discovery — the proposal's original working name — and a structured-credit layer for tokenisation and securitisation, with Sundial presented as its partner for institutional liquidity. The Treasury would fund the open core; the recipient's commercial products sit at exactly the layers that plug into it — as verification providers to the Verification Framework, as a marketplace on the Discovery Engine, as the capital side described by the Capital Provider Profile Standard.
Open core is how a great deal of good open-source infrastructure gets built, and none of this is improper. A for-profit firm maintaining a non-rival good the ecosystem depends on presents a commons-derived claim, and this DRep's burden is a test of claim structure, not of the recipient. But held against the standard this DRep applies wherever one party acquires the power to set terms that others will build on — is that power matched by an obligation running the same direction — the reading is a partial inversion. The power to define how credit objects and capital-provider requirements are described on Cardano would pass to parties whose products are positioned around those descriptions; no obligation of neutral stewardship, external change control or disclosure passes with it. The licence makes the code forkable. It does not make the coordination point forkable once publishers and capital providers have converged on it. The repair is to scope that discretion before the vote: say where the standards will live and how they will change after delivery, put at least one editor or maintainer from outside the consortium on them, open the first milestone's specifications to public comment before acceptance, and disclose in the proposal itself how the recipient's commercial products relate to the layers being funded, together with a commitment that the reference implementation privileges none of them.
2.8 What is already there, and what gets remembered about borrowers
Two shorter readings belong beside the four findings. Neither carries the vote.
The proposal's problem statement says that without shared standards every lending protocol and capital provider must build its own discovery and verification. That is true across protocols, and the cross-protocol layer is genuinely missing. But the ground is not empty, and the proposal does not map it. Rusty's own cardano-loans protocol already makes loan requests, offers and active loans discoverable by any indexer through beacon tokens, already treats an optional verifiable-credential layer as additive to on-chain identity, and is the evident source of the proposal's "Loan Request UTxO" model. Real-world credit is arriving on Cardano through other routes — a credit-backed dollar token whose backers report servicing loans in East Africa launched this month, and a private-credit tokenisation proposal from a Brazilian team sat in the Fund 15 round that did not run. A standard meant to be adopted across implementations should say which implementations it was designed against, which it has spoken to, and how it relates to what they already do. Without that account, "protocol-independent" is a design intention rather than a demonstrated property, and the testnet demonstration does not name the lending infrastructure it will run on.
The second reading is about records. Both the proposal and its website treat repayment, default and recovery histories as one of AURORA's long-run contributions — portable track records for borrowers, originators and markets. Those are durable records about real businesses and the people behind them, published to a ledger that does not forget. The proposal's privacy commitments are sound in intent, and the specifications that would give them force are not yet written. What I notice is an asymmetry in what is proposed to be remembered: histories accrue to borrowers and originators, while capital providers appear only as profiles of requirements. The advisor's own protocol is better on this point — it records lender track records alongside borrower histories, so that the party extending credit is legible on the same terms as the party receiving it. I would like to see that symmetry, a minimisation rule for anything identifying, and a correction path for an erroneous default written into the first milestone's specifications. Integration of Midnight tooling or protocol primitives, along with the privacy standards they align to, is likely, but not clearly stated here. This is a design question for a standard that does not yet exist, so it is carried to the trajectory record rather than into the vote.
2.9 What the commons retains
Treasury funds may maintain commons relations; they may not transfer a private surplus. The test is the structure of the claim, and here it is mostly met.
The relation is stated, and stated well: coordination capacity that no single protocol provides, independent operators able to route around any one indexer, forkable infrastructure the commons keeps, verification that serves many policies instead of imposing one. Those claims are relational, and the acceptance criteria are written to make several of them checkable. There is a private surplus, and it should be named without color: a firm building a product line around credit infrastructure would have the open core of that line funded by the Treasury, would author the standards its other products plug into, and would carry the name of the standard as the name of its venture. That is ordinary commercial logic. It is also exactly the circumstance in which the proposal owes an account of what keeps the relation from being captured by the surplus, and that account is the stewardship and disclosure set out in section 2.7.
I do not read this as an honest disagreement at the margin over whether a well-stated relation is genuinely served — the kind of two-frame dispute on which this DRep would stand aside. The relation is stated; what is missing is a set of terms that would make it hold, and those terms are nameable and within the proposer's gift. That places it where a No that specifies is owed.
2.10 Why this is a No and not an abstention
Four grounds for abstaining were live and each is foreclosed.
The first is whether the ballot cannot carry the findings. Some of what this reading surfaced cannot be carried by any single vote, and section 2.13 records it. But the four findings that carry this token — a mutable anchor, an independence statement that does not match the recipient's own account, a final gate that releases payment before the public asset exists, and standards without stewardship — are properties of this action, stated on its face and fixable in it.
The second is whether this falls outside what this DRep's framework reads. It does not: the framework has a good deal to say about custody, verification and stewardship without needing an opinion on indexer design.
The third is whether this is a margin (private-surplus) dispute, and of all the proposals this DRep has read this year it comes closest, because its relational vocabulary is unusually good. Section 2.9 sets out why it is not. Withholding stake is not neutral — it lowers the bar an action must clear — and a good vocabulary is not evidence about the terms it leaves unwritten.
The fourth is interest. I hold ada and use the chain, which disqualifies no one. I know these teams through Catalyst and the ecosystem, which is familiarity rather than interest. This DRep has no commercial, advisory or financial relationship with Fairway, Sundial, Rusty or any of the five proposed administrators, and no shared role with any administrator beyond ordinary participation in DRep forums. One adjacent interest is declared rather than left to be found: this DRep works on open standards for Cardano governance including proposal standards, and several repairs proposed here — immutable references, related-party disclosure, stewardship terms for funded standards — are the kind of clause such a standard would carry. That is an interest in the remedy, not in the action, and readers should weigh the specification with it in view.
What pulled hardest the other way should be said, because this vote was close. The proposal is small, cheap for what it offers, structurally more careful than most, and aimed at a relation this DRep cares about. Catalyst, the instrument that used to fund work of exactly this size, is off in its own little discretionary well, and this consortium was, as I understand it, in line for funding in the round that did not run; a direct Treasury withdrawal is now the only route open to them, and holding a ₳940,000 ask to standards written for asks ten times larger raises the cost of entry most for the builders least able to carry it. That is a real cost and I do not dismiss it. It is why the findings are written as a short list of repairs rather than as objections, and why every one of them is, hopefully, cheaper to fix than the proposal was to write.
2.11 Fiduciary verification (external instrument)
This DRep's own framework reads the relational and structural question and by design does not read the capital-allocation one. Leaving that region unexamined would raise vigilance rather than lower it, so the proposal was run through the DRep Treasury Rule Book v17 as a subordinate gate, one that can lower a merits-Yes but cannot raise a merits-No.
By economic substance this is open-source infrastructure and standards delivered by a firm with an adjacent commercial strategy, which the rulebook reads on its infrastructure scorecard with hybrid treatment — the public asset as the principal return, with the higher return and neutrality bars that apply when the recipient keeps the commercial upside. Nominally it is a medium request; as a share of the Net Change Limit it is small; and the rulebook's instruction to move a request up a band for weak recovery rights would, on this DRep's judgment, take it to the large band, since advances cannot be recovered. The conclusion does not turn on that judgment.
The gate does not clear, and it stops before scoring. The rulebook treats mutable material content as a preflight failure, and the material terms here are reached through a mutable anchor and a movable tag. It treats an undisclosed related party as a hard failure on integrity, and an advisory relationship between the recipient and a custodian is one. It finds continuity absent where nothing is said about who maintains, operates or stewards the outputs after the term, which is the case for the standards. Budget clarity is partial — the supporting costs are itemized; the fee is a lump sum with no roles, rates or allocation between the three parties — and independent verification is thin: milestone evidence is reviewed by five lay signers, one of them technical, and the independent security review comes only after the whole fee can have been advanced. Against that, custody and segregation score exceptionally, the public asset and third-party operability score strongly, the price is modest and the opportunity cost low.
So this is convergence at the conclusion. A rights-derived reading and a capital-stewardship rulebook reach No from opposite directions and meet at three points — the immutability of the terms, the disclosure of related parties, and what happens after the term. Had the fiduciary gate come back clean, the relational No would have stood; had the relational reading passed and the gate failed, the allocation defect would have been dispositive. Its function here is to sharpen the specification.
2.12 What would make this a Yes
The specification is short, and every item is cheaper before the vote than after it.
Anchor the governance action and the full proposal on content-addressed storage and reference both by hash, as the proposal's own submission section already promises.
Disclose every relationship between the five administrators and the consortium, including advisory, commercial and employment ties, and replace any signer who has one or exclude them in advance from every decision touching Fairway's payments, showing that the three-of-five threshold still works.
Move the last gate. Hold back a meaningful share of Fairway's final instalment until the fourth milestone — independent review, legal review, public release and third-party deployability — is accepted; add a recovery clause for advances against undelivered work; and state the basis, if any, on which reallocation may increase the fixed fee.
Give the standards a steward. Say where the Metadata Standard, Verification Framework and Capital Provider Profile Standard will live after month five and how they change, whether through the CIP process or a named open process with an editor from outside the consortium; open the first milestone's specifications to public comment before acceptance; and name the lending implementations the standard has been designed against and consulted with.
Disclose the commercial context in the proposal itself: how Fairway's identity, credit-intelligence, marketplace and structured-credit products and Sundial's liquidity role relate to the funded layers, and a commitment that the reference implementation and APIs privilege none of them. Disclose the Catalyst funding of each consortium party within the last twenty-four months, not only the recipient's.
Do those, and this becomes a proposal this DRep would expect to vote for. The recommendation on borrower records in section 2.8 — symmetric track records, minimisation, a correction path — is not a condition, but I would read a resubmission more warmly for it.
2.13 What the vote does not reach
A vote is a snapshot; the log is the trajectory. Several tensions this proposal makes visible are held here rather than converted into this vote, because none of them has a solution so much as a position the ecosystem occupies and can be watched moving along.
The first is between the instrument and the builder. With Catalyst paused, small and medium builders now come to the Treasury through the same instrument as eleven-million-ada infrastructure contracts, and are rightly held to the same constitutional requirements — immutable documents, audit allocation, custody — which cost proportionally far more at this size. This proposal's custody design is evidence that a small team can meet the heavier bar well; its anchor is evidence of how easy it is to miss a step under that weight. The ecosystem needs a recognized instrument for mid-sized public work, and until it has one, every such proposal carries overhead built for something else.
The second is between proportionate oversight and accountability. As this proposal shrank, its oversight became lighter: reconciliation gave way to a fixed fee, custody to advances, an interim review tied to a milestone to one that is not. Each step can be defended as proportion. Taken together, the commons' leverage moved from the end of the project to its middle. Lighter is not the problem; lighter without the controls that make lightness safe is, and those controls — retention, recovery — are themselves cheap. I will be watching whether this becomes the template for small infrastructure asks.
The third is between open core and the commons. Treasury funding of the open layer of a commercial product line is likely to become common, and it is not wrong. What the ecosystem has not settled is what a funded standard owes its non-funded adopters: who holds the pen, how dissent is recorded, how a standard's steward is changed. This is the stewardship question in general form, and it is a candidate for a future proposal rather than a future vote — a common clause, attached to any Treasury-funded specification, setting out its home, its editor and its change process.
The fourth is between legibility and memory. Making credit legible is the point of this proposal and the reason it is worth funding in principle. A ledger that records defaults does not forgive them. Whether Cardano's credit infrastructure remembers the lender as carefully as the borrower, and gives either a way to correct the record, is a choice that will be made in the first specifications anyone writes, and once made will be expensive to revisit.
Three smaller readings belong beside these. The proposal's title promises real credit markets and its funded scope is a testnet demonstration with no named lending implementation or capital provider committed to it; the gap is not misleading so much as aspirational, but it is the kind of distance between name and scope that this DRep tracks across proposals. The name AURORA belongs at once to an open standard and to a venture; whether independent adopters will treat a standard bearing a company's product name as neutral ground is an adoption question the proposal does not raise. And the questions this DRep's intake asks that no proposal template yet does — what reverses this if it is wrong in eighteen months, what reads through it, what would register its degradation — went unanswered because they were never put. That is a reading of the ecosystem's vocabulary, not a defect in the submission.
3.0 Conclusion
We are voting NO (remediable).
The idea is sound, the price is modest, the custody design is a model, and the relation the proposal aims at — productive claims made legible one by one — is one this DRep's framework exists to protect. The refusal is of four structures: terms anchored where they can still move; a custody body whose independence is stated more strongly than the recipient's own account supports; a payment schedule whose last gate releases the whole fee before the public asset exists, with no way to recover an advance; and standards that would be authored and versioned by parties whose commercial products surround them, without stewardship terms or disclosure. Run separately, the external capital-allocation instrument reaches the same conclusion against the same structures.
Each is repairable by the proposer in days rather than months, and the proposal's history shows a team that revises when asked. Pin the documents, disclose the relationships, move the last gate, give the standards a steward, and say plainly what the company around the standard does. That is the whole specification.
Beyond this action, I will carry forward what it makes visible: a funding landscape in which small builders now meet the Treasury's heaviest instrument, oversight that lightens as asks shrink without the cheap controls that make lightness safe, and an ecosystem about to fund open cores without having settled what a funded standard owes those who adopt it. This DRep will continue to maintain a state of inquiry around them and will bring the stewardship question into proposal form.
DRep ID: drep1yfaq8dsam...3nq50q DRep Profile: https://styg-drep.github.io/coordination-commons/
My thanks to the delegators who make this reading possible, and to Fairway, Sundial and Rusty for bringing a careful, open and honestly sized proposal to the commons, and for a revision history that suggests they will read this as it is meant.
Stay in touch. X: https://x.com/styg50
Sources
External pages were read on 18 October 2026 and should be re-verified at submission; the project and company websites are mutable.
- Governance action record, anchor URL and hash, recipient credential, epochs: Koios proposal_list query. Anchor hash verified locally against
data.jsonldat commit0b12716. - Proposal text and revision history: fairway-global/aurora-proposal (tag
proposal-snapshot-2026-10-18→ commitcfc866c); implementation repository: fairway-global/cardano-aurora. - Project website (economics, AURORA Capital, phases): aurora.fairway.global. Slide deck: canva.link/cardano-aurora
- Recipient's products, team and advisory board: fairway.global.
- Net Change Limit count at 16 October https://dreptalk.com/treasury/.
- Catalyst pause and stewardship transfer: CryptoSlate.
- Existing work: fallen-icarus/cardano-loans; RealFi launch coverage; Cardano Private Credit Emerging Markets (Catalyst F15).
- Sundial project listing: Cardano Cube.
- 1.0 Introduction
- No65.5K ₳No rationale
- Yes12K ₳No rationale
- No7.2K ₳No rationale
- No85.8 ₳Rationale
Voting NO on AURORA: Open infrastructure for bringing real credit markets to Cardano (₳940,000).
As an elected Cardano Civics Committee member, Unified Cardano Student Club President in Nigeria, and a DRep focused on transparency and sustainable treasury use, I recognise the potential value of shared credit-market infrastructure that could reduce duplication and help builders.
However, I cannot support this withdrawal. There is no clear proven track record or sufficient evidence of previous work from the team that gives me confidence in delivery at this stage. With the treasury under pressure and remaining withdrawal capacity limited, I prioritise proposals with demonstrated capability, stronger accountability signals, and clearer sustainability before committing funds.
I remain open to future versions that show concrete prior results, tighter evidence of execution capacity, and stronger transparency around past delivery. For now, fiscal discipline and the need for proven performance lead me to vote No.