AURORA: Open infrastructure for bringing real credit markets to Cardano.
gov_action1znt2fr0chyye50nj0cdld2dvdjg3xsdfvq0fr37n43uehlvfkqdsqjnuq3n
Submitted
epoch 662
18/10/26, 21:14:49
Expires after
epoch 669
Requested from treasury
₳940.00K
Votes recorded
2
2 DReps · 0 pools · 0 CC
Tally as of
epoch 662
DReps (by delegated stake)needs 67%not passing
Yes 0.19%
₳10.18M · 2 votes
No 99.81%
₳5.27B · 0 votes
Abstain
₳0.00 · 0 votes
Stake pools (by active stake)does not decide this action
Yes 0.00%
₳0.00 · 0 votes
No 0.00%
₳0.00 · 0 votes
Abstain
₳0.00 · 0 votes
Constitutional committee (by member)needs 67%not passing
Yes 0.00%
0 of 7 members
No or not voted 100.00%
0 voted No · 7 not voted
Abstain
0 abstained
left out of the shares
no votes cast yet (not voting counts as No)
DRep percentages exclude stake that abstains (₳10.55B is delegated to “always abstain”). Stake delegated to “always no confidence” (₳136.19M) and to DReps that have not voted counts as No.
Treasury withdrawals
| Recipient reward account | Amount |
|---|---|
| stake179uthrjzt0395mukqctux9u2zchytk5py4hr0xd9ka7jtdqa9jgyq | ₳940.00K |
Abstract
AURORA will give Cardano builders shared infrastructure for finding, comparing and verifying individual credit opportunities across compatible lending implementations. Today, each application must build much of this infrastructure separately, increasing integration costs and fragmenting market information.
AURORA provides that shared market layer. Treasury funding will deliver the Metadata Standard, Verification Framework, AURORA Discovery Engine, open APIs, filtering and query tooling, Capital Provider Profile Standard, developer tooling and reference implementation. Together, these components allow independent credit opportunities to expose standardized market information, become discoverable through common interfaces, and be evaluated according to different application and capital-provider requirements.
The infrastructure operates around compatible lending implementations while leaving loan origination, lending logic and settlement to those underlying systems. This allows different protocols and applications to share common market infrastructure without requiring adoption of a single lending protocol, verification system or commercial model.
The Treasury request is 940,000 ADA for approximately five months of delivery across four milestones. Fairway is responsible for delivery, with technical contributions from Sundial and architectural advice from Fallen Icarus. Treasury-funded implementation will begin following approval and enactment of the Treasury Withdrawal and receipt of funds. Treasury funds are initially received into an independent 3-of-5 AURORA Treasury multisignature, and all Treasury-funded software, standards and reference implementations will be released under Apache License 2.0 with public documentation and operating guidance.
Implementation contributors hold no signing keys to the administrator-controlled Treasury multisignature. Implementation installments are paid to Fairway, beginning at project commencement, with subsequent releases based on acceptance of the preceding milestone. Fairway manages implementation resources. Administrators may approve budget reallocations within the approved scope and total request. Independent Treasury-use audits take place following publication of the M2 technical outputs and during M4 before project closure, covering the funding arrangement and records defined in Section 11 of the full proposal.
Motivation
Cardano’s eUTxO architecture is well suited to credit markets built around individual financial agreements. Rather than requiring lending activity to begin in shared liquidity pools, individual credit opportunities can exist as distinct Loan Request UTxOs, each with its own terms, state and lifecycle.
This provides the foundation for a more open credit market, but individual on-chain opportunities do not by themselves create a usable market. Capital providers and applications still need consistent ways to discover opportunities across different implementations, understand and compare their terms, apply their own filtering and verification requirements, and monitor relevant information over time.
Without shared standards and market infrastructure, each lending protocol, application and capital provider must build its own metadata formats, indexing logic, discovery interfaces, verification workflows and filtering systems. As more lending models, jurisdictions, verification systems and capital-provider requirements emerge, this creates fragmented market information and repeated integration work.
AURORA addresses this missing layer. Standardized metadata provides a common way to describe credit opportunities, the AURORA Discovery Engine makes them searchable across compatible implementations, and open filtering and verification infrastructure allows different applications and capital providers to evaluate them according to their own requirements.
The result is shared infrastructure through which otherwise independent Cardano credit opportunities can function as a coherent and accessible market.
Rationale
AURORA addresses the market-infrastructure gap described above through a set of shared components that work together around compatible Cardano lending implementations.
Each component solves a different part of the problem: standardizing how credit opportunities are described, making them discoverable across implementations, supporting different verification requirements, translating capital-provider requirements into market queries, and giving future builders open interfaces and tooling they can integrate directly.
1. Metadata Standard: give credit opportunities a common language
AURORA will develop a versioned Metadata Standard for associating consistent, machine-readable market information with Loan Request UTxOs.
The standard can describe attributes such as jurisdiction, duration, asset, ticket size, verification references and other information defined by the applicable schema. Because this information is standardized through metadata rather than embedded into one lending protocol’s core contract logic, different credit implementations can retain their own architecture while exposing opportunities through a common market-information model.
This provides the shared language on which discovery, filtering, verification and future integrations can operate.
2. Verification Framework: support different forms of verifiable evidence
Institutional and professional capital providers may require information beyond the terms of the lending agreement itself, including institutional status, eligibility information, compliance-related evidence or other verifiable attributes.
AURORA will build an open Verification Framework for associating and evaluating this proof-based information with credit opportunities.
The framework will define versioned schemas and common verification interfaces through which different credential systems, attestations and proof technologies can be integrated. Applications and capital providers will determine which evidence satisfies their requirements.
3. AURORA Discovery Engine: turn independent opportunities into a searchable market
The AURORA Discovery Engine will identify and index compatible Loan Request UTxOs and their associated metadata, making otherwise independent credit opportunities searchable across Cardano.
The engine will organize standardized market information, expose associated verification information and track relevant lifecycle information made available by compatible lending implementations, including repayment events where available on-chain.
Instead of each wallet, lending application or capital provider building its own indexer and reconstructing the same market information independently, they can build against common open infrastructure. The Discovery Engine will be open-source and independently deployable rather than dependent on a single hosted service.
4. Filtering & Query Tooling: find the opportunities that meet specific requirements
Different applications and capital providers need to search the same market according to different criteria.
AURORA will provide common filtering and query capabilities for attributes such as jurisdiction, duration, asset, ticket size, verification requirements and other standardized information.
This turns indexed Loan Request UTxOs into a usable market: participants can move from seeing what opportunities exist to finding the opportunities relevant to their own requirements.
5. Open APIs: make the market accessible to other applications
AURORA will expose its market infrastructure through open APIs that applications can integrate directly.
These interfaces will allow wallets, lending applications, analytics services, capital-provider systems and other Cardano applications to query credit opportunities, standardized metadata, verification information and relevant lifecycle data without creating separate protocol-specific integrations for the same functions.
Published interfaces and operating documentation will allow the infrastructure to support multiple applications rather than functioning as a closed AURORA front end.
6. Capital Provider Profile + Reference Query Library: translate capital requirements into reusable market queries
AURORA will provide a Capital Provider Profile Standard for representing requirements such as jurisdiction, ticket size, duration, asset, verification requirements and risk preferences.
The accompanying Reference Query Library, Discovery and Filtering Specification and related integration artifacts will demonstrate how those requirements can be translated into reusable queries against AURORA-compatible credit opportunities.
These components, developed with selected technical contributions from Sundial, provide common infrastructure for connecting capital-provider requirements with market discovery. They do not make lending or capital-allocation decisions; individual capital providers continue to determine which opportunities satisfy their own requirements.
7. Developer Tooling + Reference Implementation: make AURORA practical for other builders
Open standards are useful only if other builders can implement them.
AURORA will therefore provide developer tooling and reference code demonstrating how applications can create AURORA-compatible metadata, identify and index Loan Request UTxOs, query the Discovery Engine, apply filtering criteria and evaluate verification references.
The reference implementation will bring the individual components together into a working blueprint for integrating the AURORA lifecycle.
8. Documentation + Independent Review: make the infrastructure deployable and independently assessable
The final release will include technical documentation, specifications, build instructions, API documentation and operating guidance sufficient for technically capable third parties to inspect, integrate and operate the relevant infrastructure.
The funded scope also includes independent security review of the software and relevant technical interfaces, independent legal review within the infrastructure-only scope, and independent Treasury-use oversight.
Delivery culminates in an end-to-end testnet demonstration validating the complete infrastructure flow:
Loan Request UTxO → standardized metadata → indexing → discovery → filtering → verification → application-level consumption.
All Treasury-funded software, standards and reference implementations will be publicly released under Apache License 2.0, allowing Cardano builders to use, operate, modify and extend the resulting infrastructure.
The full AURORA Treasury Proposal forms part of this funding request and defines the architecture, deliverables, budget, milestones and funding terms. Fairway is the Treasury Withdrawal Recipient and lead implementer. Sections 5, 7, 9 and 11 specify budget reallocations, implementation payments, independent administration, audits, prior funding disclosure, refund conditions and Net Change Limit compliance.
References
Vote as a DRep beta
Connect a wallet that is registered as a DRep to vote on this action. Stake-pool and committee votes are not supported here.
Built with MeshJS and checked offline; signing and submission have not been exercised on mainnet. Realtap never holds keys.
Votes
| Voter | Body | Vote | Voting power | Rationale | Time |
|---|---|---|---|---|---|
| Cheeky Crypto (CHEEK) | DRep | Yes | ₳10.16M | none | 19/10/26, 00:15:38 |
| Endubis Hub | DRep | Yes | ₳12.05K | none | 18/10/26, 21:24:06 |
The vote list is read from our own copy of the chain’s governance record, last updated 47s ago; the tallies above are the public source’s, as of epoch 662.
Source: Koios (public)updated 9m agoProposal text is the author’s own unverified document.