over budget

Continuous Finance Building Blocks

$75,000.00 Requested
Ideascale logo View on ideascale
Community Review Results (1 reviewers)
Addresses Challenge
Feasibility
Auditability
Problem:

<p>DApp developers want to use financial Smart Contracts in projects, but that requires Plutus engineering expertise, slowing time-to-market.</p>

Yes Votes:
₳ 117,384,364
No Votes:
₳ 48,235,432
Votes Cast:
608

  • download
  • download
  • download

Detailed Plan

DApp developers working on market opportunities need to move fast and test their market, iterating quickly on designs and approaches. These DApps often require market mechanisms that help fund projects and incentivise user activity.

These underlying Smart Contracts will carry significant value and require customer trust. Customers need to know that the protocols are well engineered and of high assurance. However, developing robust, scalable, modular and composable Plutus Smart Contracts requires formal analysis, design and engineering across many disciplines including software engineering, finance, economics, and complexity science. Many DApp development teams lack these skills.

Team & Experience

The team has experience in financial markets software engineering, cryptocurrency payments, tech start-ups, Data & Govtech, impact investing. We are also active in organising a legal-tech community and the Eastern Townhall.

Robert O'Brien: Distributed Systems Software Engineer (Financial Systems) and Entrepreneur. Co-Founded three start-ups in Financial Data Analytics, International Trade Payments, and Impact Investing. Co-organises LegalHackers New Zealand, and advises a Social Entrepreneurship Incubator. Co-Initiator of the Eastern Town Hall.

Andrew Walker: Distributed Systems Software Engineer, mostly in the financial sector in the City of London. Worked at Barclays Capital (credit risk) and LIFFE (derivatives exchange). Working on cryptocurrency payments infrastructure and also experienced with the hospitality sector.

We are Plutus Pioneers (Cohort 1). The team (and our extended network) has experience in User Experience design, used formal methods, and developed high-performance systems in financial settings. Over the last thirty years, we've worked on highly concurrent distributed systems using C/C++ and functional languages OCaml, Erlang, Scala, and Haskell. We have experience in Blockchains and cryptocurrency projects.

Our Solution

A Bonding Curve Plutus Software Development Kit (SDK). We will design and engineer a module of baseline Smart Contracts for implementing Automated Market Makers (AMM) and more.

We will build an open-source, reusable module in Plutus utilising the Extended Unspent Transaction Output (EUTxO) architecture. It will be general enough for use in many applications and will be reliably incorporated into more complex Plutus designs. Layered over that will be a Software Developers Kit (SDK) to enable easy integration with DApps.

Bonding Curves[1] are one of the most useful and widely used components in DeFi. They are used in AMMs that underpin many of the Decentralised Exchanges (DEX), Loan, and Insurance protocols popular in DeFi. Their applicability extends beyond the limited scope of DeFi, including many different scenarios for Decentralized Autonomous Organization (DAO) governance, project funding, fractional ownership of NFTs etc.

An EUTXO Specific Architecture

The module and Smart Contract design will be engineered specifically for the EUTXO architecture of the Cardano Blockchain. The core design will utilise a batch auction mechanism to maximise throughput and prevent resource contention on the underlying reserve (liquidity pool). The design is based on the Treynor Dealer model[13]. A design that combines an order book (Dealer) as a periodic combinatorial auction with an AMM liquidity pool.

The combinatorial auction is not your typical English Auction! It is an off-chain optimising algorithm designed to maximise welfare (a fair price for all participants). A single Plutus-Backend node can execute it, or run as an Oracle Pool when more complex higher-throughput matching requirements are needed.

Bonding Curves can be parameterised to suit specific periodic settlement windows (per-slot, epoch, or other), throughput requirements, shared reserve pool, and transaction matching using metadata. A simple bidding language for more complex matching scenarios is envisaged; Allowing a form of token-based if-then-that logic which is particularly relevant to the composition of bonding curves.

Please refer to our Catalyst Fund 2 Proposal for more details about Combinatorial Auctions and Oracle Pools[2], and our Catalyst Fund 5 proposal[3] for more details on Bonding Curves and their use.

To design and build the Bonding Curve module and SDK, we are using as a reference the Comos Bond Module[4]; leveraging the economic and system dynamics work already done by Blockscience[5], the Token Engineering[6] community, and Shruti Appiah[7]. As the project gets underway, we will welcome other interested contributors from the community to help build and maintain the project.

Impact on Challenge Metrics

DApps for DeFi, SoFi (Social Finance), and RealFi can be built from these standard building blocks. Many aspects of project funding, team accounting and compensation systems are similar. There is no need to keep reinventing the same components.

The bonding-curve module aims to be an essential toolkit for software developers that don't want to dive into learning Haskell, EUTXO, PlutusTx or the Plutus Application Backend. An essential toolkit for technology start-ups that don't have the skills in complexity-science and engineering talent to develop great economic protocols.

By focusing on baseline primitives and engineering for reuse across the Cardano Ecosystem, we can make it faster to deploy reliable market-focused DApps. DApp developers can easily integrate and interoperate modular Smart Contract mechanisms that we develop, giving customers confidence that their wealth is secure and value streams are fair.

Key Performance Indicators

  • Key Metric: Project Velocity[8], defined as a combination of base activity metrics of commits pulled from Github.
  • Activity Metrics: captured as project activity in Github and cadence of deliverables and engineering milestones achieved.
  • Community Metrics: engagement behaviours broken down into four categories[9] for the Bond Module, to measure how our work is being spread and used in the Cardano ecosystem. These Metrics derive mostly from Github.

What Success Looks Like

Our proposal will contribute to Cardano's developer ecosystem a module of bonding curve primitives explicitly designed for the EUTXO architecture. They are intended for integration into other higher-level protocols and DApps.

After One Month:

  • Initial specifications and scope for bonding curve module completed.
  • Nix-based Jupyter notes infrastructure established integrating Nix, Python, and OCaml into a reproducible data science/simulation pipeline.
  • Engagement with individuals interested in contributing to the work via a DAO.

After Three Months:

  • Developed simulations for the system dynamics of the combinatorial auction design.
  • A draft formal specification and tested using Bigrapher[10], a Bigraphical Reactive System (BRS) simulator.
  • Pre-Alpha implementation of the core protocols running on testnets.

After Six Months:

  • Completed design for the module(s) and implementation of the core protocols running on testnets.
  • Documentation published that both explains the design and use of the bonding curve primitives.
  • DAO trusted seed established and plans to hatch the DAO using Bonding Curves for future funding are developed. The primary purpose of the DAO is to ensure long-term, cost-effective support of the module and continued development.

After Twelve Months:

  • Formal specification published
  • Production-ready core protocols fully engineered, tested and audited.
  • An SDK for one development environment developed (most likely Haskell, with PAB).
  • Five projects use the bonding-curve module in their implementation; A mix of DeFi, SoFi protocols, DApps, and DAO.

The project will evolve over time including the extension of bonding curves to bonding surfaces (see Balancer[11]) and incorporate a bidding language. We are making a commitment to ensure there is long-term support that will be managed and funded by a DAO (using bonding curves to fund and govern it!).

Licensing

All our source code will be licensed under a free and open-source (OSI) license e.g. MIT, and contributions must be contributed patent-free. Contributors will be required to agree to a Contributor Covernant[12].

Published content will be licensed under the Creative Attribution-Non-Commercial-ShareAlike International (CC BY-NC-SA) License v4.0. The specification will be published under a Creative Commons Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0) license.

Code, documentation, project activity and Jupyter notebooks will be made available on Github or similar service.

Budget Breakdown

The requested Fund 6 budget is for wages and expenses for six months of the project. We will deliver the initial bonding curve module code and related documentation. Further funds will be requested to continue the work beyond this period, either through Catalyst or direct funding of the yümi DAO.

  • Software Specification & Engineering: $53,250 USD (71%)
  • Technical Writing: $7,500USD (10%)
  • Community Engagement: $3,750USD (5%)
  • Project Management: $7,500USD (10%)
  • Software Services & Server Fees: $500 x 6 months = $3,000 (%4)

Budget based on a pro-rata hourly rate spread over up to three team members. FTE hourly rate of USD$100 includes all overheads; Adjusted for experience, nature of work, and short term intermittent nature of project funding.

References

[1] Bonding Curves: <https://medium.com/giveth/deep-dive-augmented-bonding-curves-3f1f7c1fa751>

[2] A Smart Market Toolkit for Cardano. <https://cardano.ideascale.com/a/dtd/A-Smart-Market-prototype-for-NFTs/323408-48088>

[3] AMM for Continuous Financing: <https://cardano.ideascale.com/a/dtd/AMM-for-Continuous-Financing/350654-48088>

[4] Comos Bond Module: <https://github.com/ixoworld/bonds>

[5] Blockscience cadCAD: <https://cadcad.org/>

[6] Token Engineering Community: <https://tecommons.org/>

[7] Shruti Appiah: <https://iohk.io/en/team/shruti-appiah>

[8] Project Velocity: <https://chaoss.community/metric-project-velocity/>

[9] Community Metrics: <https://communityroundtable.com/best-practices/thecrs-work-out-loud-framework/>

[10] Bigrapher: <http://www.dcs.gla.ac.uk/~michele/bigrapher.html>

[11] Bonding Surfaces: <https://medium.com/balancer-protocol/bonding-surfaces-balancer-protocol-ff6d3d05d577>

[12] Contributor Covernant: <https://www.contributor-covenant.org/>

[13] Treynor Dealer model: https://en.wikipedia.org/wiki/Treynor_dealer_model

コミュニティ・アドバイザー・レビュー (1)

Comments

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3分 24秒
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4分 3秒
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3分 48秒
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2分 16秒
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3分 14秒
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3分 19秒
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4分 59秒
    Darlington Kofa
0:00
/
~0:00