[IMPACT] Please describe your proposed solution.

Problem

CIP-30 is a universally accepted web-based wallet standard for Cardano. It provides a minimalistic interface that, in principle, can be used to build almost any kind of Cardano dApp. However, the way dApp<->wallet interaction is defined leads to suboptimal dApp architecture due to CIP-30 limits.

Consider the following problems:

Use of CBOR representations

CIP-30 standard uses CBOR encoding for all data passed from the wallet, e.g. addresses and UTxOs. Interpreting this data within the app requires CBOR decoding functionality that is tedious to implement manually, and so users resort to using cardano-serialization-lib or its close alternative, cardano-multiplatform-lib, which both require loading a WebAssembly blob of >1M size.

For comparison, to start a new Web3 app on Ethereum there is no need to use a library for data serialization. It’s possible to interact with the provider object that is given by the wallet directly, although there are libraries to further simplify this. Using CBOR looks unnecessary, given that JSON is a de-facto standard for web data serialization.

Manual Transaction Building

When comparing developer experience for Cardano dApps and Web3 apps on Ethereum, the thing that is usually noticed first is that Ethereum developers operate on a higher level of abstraction than Cardano wallets.

On Ethereum, a smart contract transaction can be triggered by a simple function call on a Contract object, but when CIP-30 is used, the whole process of constructing transactions is delegated to the developer. This process includes:

• Fetching the data from the blockchain, using either CIP-30 interface, custom backend, or, most commonly, both
• Determining the parameters (or constraints) the transaction should have using internal dApp logic
• Constructing a skeleton of the transaction given data from the previous steps
• Making the transaction structure valid for stage1 and stage2 of the validation process - balancing (making sum of outputs plus fees equal to sum of inputs), estimating execution units, and attaching script data (“datums”) and redeemers.
• Serializing the transaction to CBOR format (commonly via cardano-serialization-lib)
• Passing the serialized transaction for signature and submission

The complexity of this process vastly exceeds that of the Ethereum analogue.

Limits of available queries

Most dApps require interacting with scripts, which implies the need to query for available UTxOs locked at script addresses. CIP-30 does not contain a query call that allows that - the only UTxOs that are visible are those owned by the wallet itself.

Some other useful queries, like getting delegation and reward info, stake pool info, transaction metadata or contents, and epoch data, are also outside of scope.

As a result, dApp developers are forced to implement their own query layers on the backend side - which leads to one more problem - inconsistency between states of multiple query layers:

Query Layer State Inconsistency

On Cardano, every running node has its own opinion on the set of currently unspent transaction outputs. Only eventual consistency is guaranteed.

Any dApp that interacts with a CIP-30 wallet has to deal with the inconsistency between the local cardano-node-based query layer and the light wallet query layer, especially when dApp workflow involves sending multiple transactions with the wallet in quick succession.

Thus, the goal of the developers is to ensure that the set of UTxOs available to the wallet and the set of UTxOs the backend cardano-node knows about are synchronized enough to not cause errors when a wallet or backend operations are performed. To give a few examples of potential issues, consider the following scenarios:

• A dApp tries to balance a transaction with UTxOs from the wallet that is not yet available in dApp backend's cardano node, causing an error response during execution units evaluation
• A transaction is passed for signing, but the wallet does not yet know about the UTxOs it spends, and thus refuses to sign it (this happens with Eternl)
• A transaction is sent to the network via the dApp backend (bypassing CIP-30 submit method) and is confirmed there, but the wallet still does not know about its consumed inputs, and thus returns outdated data.

Solution

We propose creating an extension standard on top of CIP-30 that addresses all these problems.

Use of JSON instead of CBOR representations

The standard should specify a new set of API methods, or a non-breaking extension of CIP-30 methods, that would allow specifying a preference for human-readable JSON format instead of CBOR for all CIP-30 data types.

To address the well-known Cardano-related CBOR definite-length vs. indefinite-length problem, the standard should refer to CIP-21 (<u>https://cips.cardano.org/cips/cip21/</u>) and require the implementations to follow it.

Automatic Transaction Building

Another set of API calls should be specified, with the goal of abstracting away tedious parts of transaction building.

Declarative transaction building is hard, but we have some experience we can apply. At MLabs, we created a library named cardano-transaction-lib (CTL) (<u>https://github.com/Plutonomicon/cardano-transaction-lib/</u>) (thanks to Catalyst Funds 8 & 9) that facilitates transaction building in JavaScript environments. The main feature of the library is a declarative constraints interface similar to that of plutus-tx-constraints package (<u>https://input-output-hk.github.io/plutus-apps/main/plutus-tx-constraints/html/index.html</u>).

We could standardize an interface similar conceptually, but using JSON instead of PureScript function calls.

For example, to spend a certain UTxO, the client would just call:

walletAPI.buildTransaction({

mustSpend: [{ utxo: “0x123467890ABCDEF…….12345#0”, redeemer: 42 }]

})

The result would be a JSON-serialized transaction built by the wallet, containing the provided UTxO as one of its inputs.

The transaction could later be modified manually before signing, but we can assume most dApps would not need to do that.

Adding new queries

The wallet query layer should be extended with new methods. We propose making a combination of existing query layer implementations into a standard with minimal changes.

We could take these specs as inspiration:

• Blockfrost: <u>https://docs.blockfrost.io/</u>
• Ogmios: <u>https://ogmios.dev/mini-protocols/local-state-query/</u>

The goal is to make it possible to retrieve the following data without the need to deploy own cardano-node:

• any existing UTxO: by address, by transaction ID
• block metadata and contents
• epoch info
• protocol parameters
• transaction data
• rewards and reward history
• stake pool info
• era summaries

Market

All dApp developers targeting browsers could benefit from this proposal.

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

Challenge statement: Development & Infrastructure. What research, tools or software can improve the developer ecosystem or infrastructure to make it easier to build and scale on the Cardano blockchain?

Current wallet API usability on Cardano is limited in comparison to Ethereum due to the aforementioned problems. Resolving these problems could significantly reduce the time-to-market metric for new Cardano projects and cut development costs, while also providing a way to build more lightweight dApps.

What does this proposal entail?

This proposal entails creating a new CIP with the aim to get new APIs standardized.

However, it does not necessarily follow that wallet developers will agree to adopt and implement the new standard.

In the best-case scenario, the CIP will revolutionize Cardano dApp development. In the worst case, it will be left unnoticed by wallet developers.

[IMPACT] How do you intend to measure the success of your project?

Success can be measured subjectively: by perceived approval of the new CIP.

The goal of this project is to get the CIP adopted by wallet developers, which is the ultimate indicator of success.

[IMPACT] Please describe your plans to share the outputs and results of your project?

MLabs maintains a social presence on Twitter and in Plutonomicon Discord, where updates could be posted. Additionally, the release could be announced on IOG technical Discord.

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

MLabs has proven itself as a company employing dozens of Haskell and PureScript software developers and delivering a number of Catalyst-funded projects in the past.

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

The main goal of the project is to create a new CIP for in-browser wallet interface that is approved and adopted by wallet developers, as an extension of CIP-30.

Feasibility of our approaches to achieve the goal will be evaluated by project managers and technical leadership of the project, based on time and budget constraints.

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

1st-2nd month

• Open a new CIP pull request with an initial version of the draft, notify popular wallet developers

3rd-4th month

• Collect CIP feedback, establish a working group containing users willing to contribute and interested parties
• Come up with specifications for all the required new API methods. The specifications should include written descriptions of all methods alongside json-schema specs.

5th-12th month

• Promote the CIP, facilitate onboarding wallet developers, adjust the CIP according to feedback

  [CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

1st-2nd month

A new CIP pull request that attempts to address the problems should be made available

3rd-4th month

Attract a considerable amount of contributions to the CIP from other participants. Cover the entire API surface with specifications

5th-12th month

Facilitate creating a working prototype for the canonical implementation.

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

• 50 hours Specifying CIP-30 call alternatives with JSON as encoding instead of CBOR
• 200 hours Specifying injected constraints-like API for transaction building, including json-schema
• 150 hours Specifying injected query API for blockchain data, including json-schema
• 200 hours Discussions around the CIP

Subtotal: 600 hours @95/hour = $57,000 USD

Total (@ rate $0.21 USD / ADA): 271430 ADA

**In the interest of full transparency, please note we have applied a conservative USD/ADA exchange rate in pricing this proposal. This is to ensure our operations remain stable regardless of market conditions. Although we firmly believe the future of Cardano is bright, we recognize the price of ADA and all cryptocurrencies is inherently volatile. Our financial obligations are denominated in fiat. Most importantly, this includes the salary of our engineers whose hard work makes projects like this possible.

In the unlikely scenario of severe negative price movement beyond our forecasted rate, it is possible that MLabs may need to temporarily suspend work on this proposal until the market recovers. Rest assured, this decision would be made solely to protect our business's long-term viability and never taken lightly.

We appreciate your understanding and support, and we are excited to see what we can achieve together.

[RESOURCES & VALUE FOR MONEY] Who is in the project team and what are their roles?

MLabs

MLabs has quickly become one of the premier development firms in the Cardano Ecosystem. We are an IOG Plutus Partner and work regularly with IOG to develop the Cardano blockchain and ecosystem. Our team is composed of talented developers who have helped build community projects such as:

• Liqwid
• SundaeSwap
• Minswap
• Optim
• Many others

Through our work with early-stage projects, we have one of the largest groups of Haskell/Plutus developers in the community.

Website: <u>https://mlabs.city/</u>

The team

Vladimir Kalnitsky - developer

Vladimir is a software developer with a number of contributions to the PureScript ecosystem and solid experience with Haskell. During his undergraduate years, Vladimir focused on functional programming and type theory. Vladimir is more of a 'hacker' than a scientist, but he still values formal reasoning about code and well-founded software development practices.

Dzmitry Shuiski - developer

Dzmitry is an experienced software engineer, currently developing solutions using functional programming techniques, mostly using PureScript and Haskell. Coming from a background in iOS App Development, he is well-versed in various aspects of developing robust and user-centric systems. Dzmitry has made considerable contributions to CTL in the past and is now primarily focused on Cardano dApp development. He is currently pursuing a degree in Software Engineering and Management at the Graz University of Technology to deepen his knowledge in more fundamental disciplines.

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

This project, if successful, could bring a lot of value to practically everyone in the Cardano ecosystem:

dApp developers would receive the following benefits:

• ability to run a dApp without setting up expensive infrastructure for cardano-node and the query layer
• ability to receive reliable data from a single source of truth - the wallet - instead of dealing with Cardano query layer inconsistencies between the backend and the wallet

dApp users:

• dApps will become smaller in size: there wouldn't be a need for CBOR serialization, and hence the need for downloading WASM blobs like compiled cardano-serialization-lib or cardano-multiplatform-lib.
• dApps will become more reliable due to the “single source of truth” approach