{"data":{"tx_hash":"14d6a48df8b9099a3e727e1bf6a9ac6c911341a9601e91c7d3ac799bfd89b01b","index":"0","bech32":"gov_action1znt2fr0chyye50nj0cdld2dvdjg3xsdfvq0fr37n43uehlvfkqdsqjnuq3n","type":"TreasuryWithdrawals","deposit":"100000000000","stake_address":"stake1uyj67ee245gdks6swa8syq2u7glywh2pwh6tnwlxehk233clnk4zk","submission_epoch":662,"expiry_epoch":669,"ratified_epoch":null,"enacted_epoch":null,"dropped_epoch":null,"expired_epoch":null,"bootstrap_period":false,"submission_time":1792358089,"description":{"tag":"TreasuryWithdrawals","contents":[[[{"network":"Mainnet","credential":{"scriptHash":"78bb8e425be25a6f960617c3178a162e45da81256e3799a5b77d25b4"}},940000000000]],"fa24fb305126805cf2164c161d852a0e7330cf988f1fe558cf7d4a64"]},"title":"AURORA: Open infrastructure for bringing real credit markets to Cardano.","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.\n\nAURORA 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.\n\nThe 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.\n\nThe 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.\n\nImplementation 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.\n","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.\n\nThis 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.\n\nWithout 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.\n\nAURORA 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.\n\nThe result is shared infrastructure through which otherwise independent Cardano credit opportunities can function as a coherent and accessible market.\n","rationale":"AURORA addresses the market-infrastructure gap described above through a set of shared components that work together around compatible Cardano lending implementations.\n\nEach 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.\n\n\n1. Metadata Standard: give credit opportunities a common language\n\nAURORA will develop a versioned Metadata Standard for associating consistent, machine-readable market information with Loan Request UTxOs.\n\nThe 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.\n\nThis provides the shared language on which discovery, filtering, verification and future integrations can operate.\n\n\n2. Verification Framework: support different forms of verifiable evidence\n\nInstitutional 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.\n\nAURORA will build an open Verification Framework for associating and evaluating this proof-based information with credit opportunities.\n\nThe 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.\n\n\n3. AURORA Discovery Engine: turn independent opportunities into a searchable market\n\nThe AURORA Discovery Engine will identify and index compatible Loan Request UTxOs and their associated metadata, making otherwise independent credit opportunities searchable across Cardano.\n\nThe 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.\n\nInstead 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.\n\n\n4. Filtering & Query Tooling: find the opportunities that meet specific requirements\n\nDifferent applications and capital providers need to search the same market according to different criteria.\n\nAURORA will provide common filtering and query capabilities for attributes such as jurisdiction, duration, asset, ticket size, verification requirements and other standardized information.\n\nThis 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.\n\n\n5. Open APIs: make the market accessible to other applications\n\nAURORA will expose its market infrastructure through open APIs that applications can integrate directly.\n\nThese 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.\n\nPublished interfaces and operating documentation will allow the infrastructure to support multiple applications rather than functioning as a closed AURORA front end.\n\n\n6. Capital Provider Profile + Reference Query Library: translate capital requirements into reusable market queries\n\nAURORA will provide a Capital Provider Profile Standard for representing requirements such as jurisdiction, ticket size, duration, asset, verification requirements and risk preferences.\n\nThe 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.\n\nThese 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.\n\n\n7. Developer Tooling + Reference Implementation: make AURORA practical for other builders\n\nOpen standards are useful only if other builders can implement them.\n\nAURORA 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.\n\nThe reference implementation will bring the individual components together into a working blueprint for integrating the AURORA lifecycle.\n\n\n8. Documentation + Independent Review: make the infrastructure deployable and independently assessable\n\nThe 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.\n\nThe 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.\n\n\nDelivery culminates in an end-to-end testnet demonstration validating the complete infrastructure flow:\nLoan Request UTxO → standardized metadata → indexing → discovery → filtering → verification → application-level consumption.\n\nAll 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.\n\nThe 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.\n\n","references":[{"uri":"https://github.com/fairway-global/aurora-proposal/releases/tag/proposal-snapshot-2026-10-18","label":"Full Treasury Proposal (Immutable Markdown)"},{"uri":"https://github.com/fairway-global/cardano-aurora","label":"Implementation Repository"},{"uri":"https://aurora.fairway.global","label":"Project Website"},{"uri":"https://canva.link/cardano-aurora","label":"Presentation / Slide Deck"},{"uri":"https://x.com/fairway_global","label":"Contact Project Lead X"},{"uri":"https://x.com/Henrik_Met","label":"Contact Lead proposer X"}],"anchor_url":"https://raw.githubusercontent.com/fairway-global/aurora-proposal/refs/heads/main/data.jsonld","anchor_data_hash":"2791bc5d48adfdb1d56b072891cfe0cd1e7235941e157d3c45774ea29b468fb1","cc_members":{"7c34e0240b84029e0932f5e8d81af42a63f55de6da31f16e19b1f5b4":{"hash":"7c34e0240b84029e0932f5e8d81af42a63f55de6da31f16e19b1f5b4","vote":null,"json":null,"name":"Leandros BSP","image":"https://avatars.githubusercontent.com/u/4371293"},"0af99047bc90e0d9073467548a19a85089b766e73eb807748a2ad361":{"hash":"0af99047bc90e0d9073467548a19a85089b766e73eb807748a2ad361","vote":null,"json":null,"name":"Marek Mahut","image":"https://avatars.githubusercontent.com/u/104795"},"16feefc225e06f75a3c917f4aa50acffde7631ea0355721f2ac12542":{"hash":"16feefc225e06f75a3c917f4aa50acffde7631ea0355721f2ac12542","vote":null,"json":null,"name":"Cardano Curia","image":"https://avatars.githubusercontent.com/u/252379635"},"1980dbf1ad624b0cb5410359b5ab14d008561994a6c2b6c53fabec00":{"hash":"1980dbf1ad624b0cb5410359b5ab14d008561994a6c2b6c53fabec00","vote":"No","json":{"body":{"summary":"Tingvard judges the “AURORA: Open infrastructure for bringing real credit markets to Cardano.” Treasury Withdrawal governance action unconstitutional.","conclusion":"Tingvard finds the “AURORA: Open infrastructure for bringing real credit markets to Cardano.” Treasury Withdrawal governance action unconstitutional.\n\nThe action has a clear purpose and delivery period, fits within the applicable Net Change Limit, provides for independent audits, places the funds under an independent 3-of-5 multisignature from the point of withdrawal, and satisfies the custody requirements. However, it does not satisfy Article II, Section 6, §1, because the anchored document is hosted at a GitHub branch URL whose content can be altered after submission. It does not satisfy Article II, Section 7, §1, because its metadata does not specify the relevant costs and expenses or the circumstances under which the withdrawal might be refunded to the Cardano Treasury. It does not satisfy Article II, Section 7, §2, because its metadata does not disclose whether the recipient has received ada from the Cardano Treasury within the last 24 months. Each of these defects is sufficient on its own.\n\nTingvard therefore judges this governance action unconstitutional.","references":[{"uri":"ipfs://bafkreieyuknozbtewyurfqoagvplvykadn6a4u6wglupavdz46bbsnnl6e","@type":"RelevantArticles","label":"Cardano Blockchain Ecosystem Constitution"}],"govActionId":"gov_action1znt2fr0chyye50nj0cdld2dvdjg3xsdfvq0fr37n43uehlvfkqdsqjnuq3n","internalVote":{"abstain":0,"didNotVote":1,"againstVote":0,"constitutional":0,"unconstitutional":4},"rationaleStatement":"This governance action requests 940,000 ADA from the Cardano Treasury to fund approximately five months of delivery, across four milestones, of open credit-market infrastructure for Cardano. The infrastructure comprises a Metadata Standard, a Verification Framework, the AURORA Discovery Engine, open APIs, filtering and query tooling, a Capital Provider Profile Standard, developer tooling and a reference implementation. Fairway is the Treasury Withdrawal Recipient and lead implementer.\n\nThis action is properly framed as a Treasury Withdrawals action and must therefore be assessed under Article II, Section 6 and Article II, Section 7 of the Constitution, together with the applicable treasury guardrails in Appendix I.\n\nTingvard’s assessment is based on the governance action metadata anchored on-chain, whose content is verified by its on-chain hash. The anchored metadata states that the full AURORA Treasury Proposal “forms part of this funding request”, and that “Sections 5, 7, 9 and 11 specify budget reallocations, implementation payments, independent administration, audits, prior funding disclosure, refund conditions and Net Change Limit compliance.” The full proposal is referenced as a GitHub release page. No hash for it is given in the metadata, and its owner can still edit or replace the release or move its tag. Tingvard has reviewed the version of the full proposal published before submission (blake2b-256 be2a64ee64c7990e9cc77aa165f083a41b0bf3e4e36a2d59ac9612afcb0f7cbc) and has used it to corroborate the anchored metadata.\n\nThe proposal satisfies Article II, Section 6, §2. It includes a title, abstract, motivation, rationale and references to supporting material.\n\nThe proposal satisfies Article II, Section 7, §1 as to the purpose of the withdrawal and the period for delivery. The anchored metadata identifies the infrastructure to be funded and a delivery period of approximately five months across four milestones.\n\nThe action satisfies Article II, Section 7, §3 and TREASURY-01a and TREASURY-02a. The applicable Net Change Limit of 500,000,000 ADA covering epochs 613 to 713 has been agreed on-chain, and the enacted withdrawals in that period leave sufficient remaining capacity for this request. The withdrawal is denominated in ada, satisfying TREASURY-03a.\n\nThe proposal satisfies Article II, Section 7, §4, with a concern. The anchored metadata provides for independent Treasury-use audits following publication of the M2 technical outputs and during M4 before project closure, and includes independent Treasury-use oversight within the funded scope. However, the amount allocated and the oversight metrics appear only in the unhashed full proposal, and the auditor is not yet named.\n\nThe proposal satisfies Article II, Section 7, §5, with a concern. The anchored metadata states that funds are “initially received into an independent 3-of-5 AURORA Treasury multisignature” and that “Implementation contributors hold no signing keys to the administrator-controlled Treasury multisignature”. Tingvard has verified on-chain that the withdrawal destination is a script credential requiring at least three of five distinct signing keys. Unlike the action assessed in the “Governance Incentives Framework 2026” ruling, this action therefore fixes an administrator structure, independent of the recipient, in its hashed metadata and on-chain, and that structure is in place at the point of withdrawal. The identities of the five administrators, however, appear only in the unhashed full proposal, under the heading “Proposed AURORA Treasury Administrators”.\n\nThe action satisfies Article II, Section 7, §6. Tingvard has verified on-chain that the destination account is a dedicated multisignature script account, is not delegated to an SPO, and is delegated to the predefined abstain voting option.\n\nThe constitutional defects are found under Article II, Section 6, §1, and under Article II, Section 7, §1 and §2. Each is sufficient on its own to render the action unconstitutional.\n\nArticle II, Section 6, §1 requires a URL hosting a document that outlines the proposed governance action, and the hash of that document. It further requires that “The document hosted by such a URL shall be immutable and incapable of being altered after submission”.\n\nThe anchor is hosted at a GitHub branch URL (refs/heads/main), whose content can be changed after submission by a single commit to that branch. The anchor file still matches its on-chain hash, the repository shows no changes after submission, and Tingvard does not find that its content has changed. Article II, Section 6, §1, however, requires the hosted document to be immutable and incapable of being altered after submission, not merely unaltered. A matching hash shows whether a document has changed; it does not make it incapable of change. If a matching hash were sufficient, the requirement of immutability would add nothing to the requirement to provide the hash. The full proposal’s own Section 11 stated that the final governance action would reference an immutable canonical version “hosted through IPFS or an equivalent content-addressed storage system … through the applicable URI and cryptographic hash”. That was not done.\n\nTingvard therefore finds that the action fails to satisfy Article II, Section 6, §1.\n\nArticle II, Section 7 places its requirements on the “Treasury Withdrawals” action itself. Article II, Section 7, §1 requires the action to specify the terms of the withdrawal, including “the relevant costs and expenses of the proposed activities” and the “circumstances under which the withdrawal might be refunded to the Cardano Treasury”. Article II, Section 7, §2 requires the action to “disclose whether the prospective recipient … has received ada from the Cardano Treasury within the last 24 months”.\n\nThe anchored metadata states the total request of 940,000 ADA but does not set out the relevant costs and expenses of the proposed activities. It does not state any circumstances under which the withdrawal might be refunded to the Cardano Treasury. It does not state whether Fairway has received ada from the Cardano Treasury within the last 24 months. In each case it states only that these terms are specified in another document.\n\nThat document is not fixed by the action. It is not hashed in the metadata, and the release through which it is referenced can be edited, replaced or re-tagged by its owner. Off-chain content becomes part of a governance action by being fixed by a hash, as Article II, Section 6, §1 provides. This document was not.\n\nThis is not a minor drafting issue. The terms in question operate after enactment: they determine what the funds may be spent on, when unspent funds must be returned to the Treasury, and what prior funding the voters were told about. A term that the proposer can still change after the vote is not a term specified by the action.\n\nIn the earlier Treasury Withdrawal actions Tingvard has checked, such as the IO and Tweag treasury withdrawals, the anchored metadata stated the required terms itself, including prior treasury receipts. Referenced documents supplemented terms the action already contained. This action instead delegates the required terms to a document outside the action.\n\nTingvard therefore finds that the action fails to satisfy Article II, Section 7, §1 as to costs and refund circumstances, and Article II, Section 7, §2.\n\nTingvard has considered Article I, Section 1, Tenets 3, 6, 8 and 9. Open, Apache-licensed infrastructure for credit-market discovery is consistent with the Tenets, and Tingvard does not find a clear, objective failure under any of them.","precedentDiscussion":"This decision applies the position Tingvard has stated on the hosting of governance action documents under Article II, Section 6, §1. The requirement that the hosted document be “immutable and incapable of being altered after submission” is met only where the URL cannot serve different content after submission. That is the case for content-addressed storage, such as IPFS, and for a URL pinned to a full commit hash. It is not met by a branch URL, a tag or release URL, or an ordinary website, even where the document currently matches its on-chain hash. Tingvard voted constitutional on the “Cardano Defi Liquidity Budget - Withdrawal 1” action of March 2026, which was hosted on GitHub at a URL pinned to a commit hash. That form of hosting satisfies the requirement; a branch URL does not. As Tingvard held in the January 2026 “Cardano DeFi Liquidity Budget - Withdrawal 1” ruling, the Constitutional Committee has no authority to apply grandfathering or transition rules.\n\nThis decision also clarifies that the terms required by Article II, Section 7 must be stated in the governance action itself. They must appear either in the anchored metadata or in a document the action references by hash. Unhashed supporting documents may corroborate or add detail to terms the action states, but they cannot supply terms the action itself omits.\n\nThis decision does not cast doubt on earlier Treasury Withdrawals that referenced supporting documents without a hash, where the anchored metadata itself stated the required terms. In “Rare Evo and Dev Gov Day 2026: Cardano Title Sponsorship”, Tingvard accepted a disclosure section that did not expressly state the recipient’s prior treasury receipts. Tingvard does not extend that approach to an action whose metadata contains no disclosure at all, only a reference to one in another document.\n\nThis decision is also consistent with the reasoning in “Eternl: Path to Sustainability - v2” and “Strike Finance Liquidity Deployment”. An independent multisignature administrator that holds the funds from the point of withdrawal, with no implementer holding a signing key, gives the administrator role real substance. Tingvard does not, however, treat an on-chain key structure alone as a sufficient designation of administrators in general. The administrators responsible should be identified in the action.\n\nThis decision also preserves the distinction between constitutional review and policy review. Whether Cardano should fund credit-market infrastructure, whether 800,000 ADA is an appropriate fixed implementation fee, whether up to 140,000 ADA should be released before the first milestone, whether the full amount should become releasable before the final independent review and audit, whether the audit budget is sufficient, and whether the administrators can assess technical milestones are questions for DReps and ada owners. The CC assessment is limited to whether the action conflicts with the Constitution.","counterargumentDiscussion":"One possible counterargument is that the anchor file matches its on-chain hash and the repository shows no changes after submission, so nothing has been altered and the hosting objection is a technicality.\n\nTingvard does not accept this. The hash is already required by Article II, Section 6, §1. The further requirement that the hosted document be immutable and incapable of being altered must therefore mean something more. A hash allows a change to be detected; it does not prevent the document at the URL from being replaced. Tingvard’s finding does not depend on any alteration having occurred, and it implies no bad faith.\n\nAnother possible counterargument is that the anchored metadata expressly incorporates the full proposal by section number, and that the version reviewed is demonstrably the version that existed at submission.\n\nTingvard acknowledges that this is the strongest argument on the Article II, Section 7 question. The full proposal was published before submission, it matches its published digest, and the repository shows no later changes. However, this evidence only shows that the document has not changed so far. It does not fix the document for the period after enactment, when the refund, reallocation and disbursement terms actually operate. Article II, Section 6, §1 provides the means of fixing off-chain content, and the action did not use it for the document on which its required terms depend.\n\nA further counterargument is that Tingvard has previously voted constitutional on Treasury Withdrawals that referenced supporting documents without a hash, and that applying these standards now gives proposers no notice.\n\nTingvard has considered this. Tingvard has not voted constitutional on any action whose anchor could be altered after submission. In the earlier actions Tingvard has checked, the required terms were stated in the anchored metadata itself. The requirements applied here come from the text of Article II, Section 6, §1 and Article II, Section 7, §1 and §2, and the Constitutional Committee cannot create transition rules. Moreover, the proposer’s own full proposal recognised that the final action should reference the canonical proposal through content-addressed storage and a cryptographic hash.\n\nA final counterargument is that the substance of the proposal is sound. It has a clear purpose, a costed budget, an independent 3-of-5 multisignature administrator, two independent audits, refund conditions and compliant custody.\n\nTingvard agrees that the proposal’s substance addresses the constitutional safeguards, and nothing in this finding suggests bad faith. The defects lie in how the action was anchored and in what the action itself specifies. They are readily curable. A resubmitted action would need to be anchored on content-addressed storage or at a commit-pinned URL. It would also need to state the costs, refund circumstances and prior funding disclosure in its anchored metadata, or reference the full proposal as a file by hash. It could reuse the existing multisignature account."},"authors":[{"name":"Tingvard","imageUrl":"ipfs://QmPkHXdK6GLtDNyyKFBWRwARFEy9TPFcbpDganixmRXwWJ"}],"@context":{"body":{"@id":"CIP136:body","@context":{"summary":"CIP136:summary","conclusion":"CIP136:conclusion","references":{"@id":"CIP100:references","@context":{"uri":"CIP100:reference-uri","Other":"CIP100:OtherReference","label":"CIP100:reference-label","RelevantArticles":"CIP136:RelevantArticles","GovernanceMetadata":"CIP100:GovernanceMetadataReference"},"@container":"@set"},"internalVote":{"@id":"CIP136:internalVote","@context":{"abstain":"CIP136:abstain","didNotVote":"CIP136:didNotVote","againstVote":"CIP136:againstVote","constitutional":"CIP136:constitutional","unconstitutional":"CIP136:unconstitutional"},"@container":"@set"},"rationaleStatement":"CIP136:rationaleStatement","precedentDiscussion":"CIP136:precedentDiscussion","counterargumentDiscussion":"CIP136:counterargumentDiscussion"}},"CIP100":"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#","CIP136":"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#","authors":{"@id":"CIP100:authors","@context":{"did":"@id","name":"http://xmlns.com/foaf/0.1/name","witness":{"@id":"CIP100:witness","@context":{"publicKey":"CIP100:publicKey","signature":"CIP100:signature","witnessAlgorithm":"CIP100:witnessAlgorithm"}}},"@container":"@set"},"@language":"en-us","hashAlgorithm":"CIP100:hashAlgorithm"},"hashAlgorithm":"blake2b-256"},"name":"Tingvard","image":"https://avatars.githubusercontent.com/u/212053216"},"84aebcfd3e00d0f87af918fc4b5e00135f407e379893df7e7d392c6a":{"hash":"84aebcfd3e00d0f87af918fc4b5e00135f407e379893df7e7d392c6a","vote":null,"json":null,"name":"Eastern Cardano Council","image":"https://avatars.githubusercontent.com/u/178256503"},"9752e4306e5ae864441d21064f791174c8b626199b8e7a45f9e03b45":{"hash":"9752e4306e5ae864441d21064f791174c8b626199b8e7a45f9e03b45","vote":"No","json":null,"name":"Ace Alliance","image":"https://avatars.githubusercontent.com/u/214127584"},"13493790d9b03483a1e1e684ea4faf1ee48a58f402574e7f2246f4d4":{"hash":"13493790d9b03483a1e1e684ea4faf1ee48a58f402574e7f2246f4d4","vote":null,"json":null,"name":"Phil_uplc","image":"https://avatars.githubusercontent.com/u/14356239"}},"new_cc_members":[],"cc_quorum_numerator":2,"cc_quorum_denominator":3,"cc_total":7,"cc_yes":0,"cc_no":2,"cc_abstain":0,"drep_threshold":0.67,"drep_total_stake":"16077531825724757","drep_yes_stake":"79813294811110","drep_no_stake":"1155440582460370","drep_abstain_stake":"282642519759308","drep_always_abstain_stake":"10583942339598525","drep_always_no_confidence_stake":"131644725389871","drep_inactive_stake":"282016966777258","drep_total":1050,"drep_yes":10,"drep_no":28,"drep_abstain":7,"drep_always_abstain":1,"drep_always_no_confidence":1,"drep_inactive":756,"pool_threshold":0,"pool_total_stake":null,"pool_yes_stake":null,"pool_no_stake":null,"pool_abstain_stake":null,"pool_always_abstain_stake":null,"pool_always_no_confidence_stake":null,"pool_total":null,"pool_yes":null,"pool_no":null,"pool_abstain":null,"pool_always_abstain":null,"pool_always_no_confidence":null,"spo_threshold":0,"protocol_major":10,"active":true,"vote_yes":10,"vote_no":30,"vote_abstain":7,"total_cc_member":7,"cc_threshold":0.6666666666666666,"cc_vote_yes":0,"cc_vote_no":2,"cc_vote_abstain":0,"total_drep_stake":"5079927793959103","non_active_drep_stake":"282016966777258","drep_vote_yes":10,"drep_vote_no":28,"drep_vote_abstain":7,"drep_stake_yes":"79813294811110","drep_stake_no":"1155440582460370","drep_stake_abstain":"282642519759308","total_spo_stake":null,"spo_vote_yes":null,"spo_vote_no":null,"spo_vote_abstain":null,"spo_stake_yes":null,"spo_stake_no":null,"spo_stake_abstain":null},"code":200}