Manu Gunther TxPipe

Project Owner

TxPipe MultiParty Escrow

Expert Rating

n/a

Type Partner RFP
Funding Request n/a
RFP Guidelines Development of a Cardano-Based MultiParty Escrow (MPE) System

Details locked. Check back later to view.
Details locked.Check back later to view.
Details locked.Check back later to view.

Overview

TxPipe is a technology company founded in 2021, specializing in Cardano development. We develop and maintain essential open-source tools like Pallas, Aiken, Dolos, and Demeter.run, while supporting key dApps such as Metera, SundaeSwap, World Mobile, and Githoney. With 25 skilled developers, TxPipe excels in infrastructure design and end-to-end dApp development, solidifying our role in the Cardano ecosystem. We propose developing the MultiParty escrow using proven processes backed by our extensive experience.

RFP Guidelines

Development of a Cardano-Based MultiParty Escrow (MPE) System

Internal Proposal Review

Type Partner RFP
Total RFP Funding $40,000 USD
Proposals 7
Awarded Projects n/a

Oct. 15, 2024

The MultiParty Escrow (MPE) smart contract is a critical component of the SingularityNET platform's integration with the Cardano blockchain. Designed to manage payment channels within SingularityNET’s Decentralized AI Platform and AI Marketplace, this contract enables secure, decentralized transactions between clients and AI service providers. By leveraging Cardano’s Extended UTxO (EUTxO) model, this solution facilitates efficient and trustworthy interactions, ensuring streamlined payments for AI services.

Proposal Description

Proposal Details Locked…

In order to protect this proposal from being copied, all details are hidden until the end of the submission period. Please come back later to see all details.

Total Milestones
4
Total Budget
$36,000_USD
Last Updated
8 Dec 2024

Milestone 1 - Functional Analysis and Design

Description

In this milestone, we will thoroughly analyze the requirements and produce a detailed document outlining the product's use cases and functional specifications. Additionally, we will develop a technical design that defines the smart contract flow, maps the involved transactions, and provides a detailed description of the validators.

Deliverables

Requirements and design document.

Budget

$6,000 USD

Success Criterion

The delivered document specifies the MultiParty escrow use cases and the design describes precisely the transactions in the cardano network and validators involved.

Milestone 2 - Transaction building

Description

In this milestone, we will define a basic version of the on-chain code, including parameters and types (redeemers and datums), but without validations. The primary focus will be on the off-chain code, which will handle the construction of all transactions involved in the multiparty escrow and perform the necessary blockchain queries. The final output will be a functional product running on the Preview or Preprod testnet, replicating the final product's behavior but without on-chain validations.

Deliverables

Onchain source code written in Aiken defining the necessary types and validators, without any checks. Offchain source code written in typescript containing functions for building the transactions involved in the multiparty escrow use cases.

Budget

$12,000 USD

Success Criterion

Full traces of every use case run on preview or preprod testnet.

Milestone 3 - Onchain validations

Description

In this milestone, we will implement all required checks in the defined validators and minting policies using the Aiken language. These checks will ensure the safety of funds, compliance with escrow dates, and validation of necessary signatures. Additionally, we will create comprehensive Aiken unit tests to verify the functionality and reliability of the implemented logic.

Deliverables

Aiken source code with the full implementation including unit tests.

Budget

$12,000 USD

Success Criterion

All tests passing.

Milestone 4 - Integration tests and final delivery

Description

In this milestone, we will finalize the implementation and thoroughly test the product on the Preview or Preprod testnet. This will involve submitting all transactions with full validation to ensure the system operates as intended and is free from vulnerabilities.

Deliverables

Final version of the offchain and onchain source code. Video demo showing the multiparty escrow use cases.

Budget

$6,000 USD

Success Criterion

The multiparty escrow supports the following use cases: - Opening a channel with token deposit - Extending channel expiration - Adding funds to a channel - Extending channel expiration while adding funds - Claiming funds from the payment channel - Claiming funds and closing the channel - Closing the channel upon expiration - Returning remaining funds to the client after channel closure - Generating signatures for AI service payments (off-chain) - Verifying signatures for AI service payments The video demo showcases the complete smart contract flow, covering all the features listed above.

Join the Discussion (0)

Expert Ratings

Reviews & Ratings

No Reviews Avaliable

Check back later by refreshing the page.

The weighted average of the 4 perspectives Overall

0.0
Each RFP defines a maximum allowed budget, but teams can differentiate their proposal by offering a solution with a lower budget or a wider scope.Value for money

0.0
This rating indicates compliance to 'Must haves' but also adaptation of 'Nice to haves' and Non-functional requirements defined in the RFP.Compliance with RFP requirements

0.0
RFPs will offer varying degrees of freedom. This rating indicates the quality of the team's specific solution ideas, the provided details, and the reviewer's confidence in the team's ability to execute.Solution details and team expertise

0.0

Review Headline

0 /50 chars

Review Summary

0 /5000 chars

The weighted average of the 4 perspectives Overall

0.0
Each RFP defines a maximum allowed budget, but teams can differentiate their proposal by offering a solution with a lower budget or a wider scope.Value for money

0.0
This rating indicates compliance to 'Must haves' but also adaptation of 'Nice to haves' and Non-functional requirements defined in the RFP.Compliance with RFP requirements

0.0
RFPs will offer varying degrees of freedom. This rating indicates the quality of the team's specific solution ideas, the provided details, and the reviewer's confidence in the team's ability to execute.Solution details and team expertise

0.0

Warning: Adding final group rating for this project will prevent expert users from adding new or editing existing reviews

Review Headline

0 /50 chars

Review Summary

0 /5000 chars

Reviews and Ratings in Deep Funding are structured in 4 categories. This will ensure that the reviewer takes all these perspectives into account in their assessment and it will make it easier to compare different projects on their strengths and weaknesses.

Overall (Primary)
This is an average of the 4 perspectives. At the start of this new process, we are assigning an equal weight to all categories, but over time we might change this and make some categories more important than others in the overall score. (This may even be done retroactively).

Feasibility (secondary)

This represents the user\'s assessment of whether the proposed project is theoretically possible and if it is deemed feasible. E.g. A proposal for nuclear fission might be theoretically possible, but it doesn’t look very feasible in the context of Deep Funding.

Viability (secondary)

This category is somewhat similar to Feasibility, but it interprets the feasibility against factors such as the size and experience of the team, the budget requested, and the estimated timelines. We could frame this as: “What is your level of confidence that this team will be able to complete this project and its milestones in a reasonable time, and successfully deploy it?”
Examples:

A proposal that promises the development of a personal assistant that outperforms existing solutions might be feasible, but if there is no AI expertise in the team the viability rating might be low.
A proposal that promises a new Carbon Emission Compensation scheme might be technically feasible, but the viability could be estimated low due to challenges around market penetration and widespread adoption.

Desirability (secondary)

Even if the project team succeeds in creating a product, there is the question of market fit. Is this a project that fulfills an actual need? Is there a lot of competition already? Are the USPs of the project sufficient to make a difference?

Example:

Creating a translation service from, say Spanish to English might be possible, but it\'s questionable if such a service would be able to get a significant share of the market

Usefulness (secondary)

This is a crucial category that aligns with the main goal of the Deep Funding program. The question to be asked here is: “To what extent will this proposal help to grow the Decentralized AI Platform?”

For proposals that develop or utilize an AI service on the platform, the question could be “How many API calls do we expect it to generate” (and how important / high-valued are these calls?).
For a marketing proposal, the question could be “How large and well-aligned is the target audience?” Another question is related to how the budget is spent. Are the funds mainly used for value creation for the platform or on other things?
Examples:

A metaverse project that spends 95% of its budget on the development of the game and only 5 % on the development of an AI service for the platform might expect a low ‘usefulness’ rating here.

A marketing proposal that creates t-shirts for a local high school, would get a lower ‘usefulness’ rating than a marketing proposal that has a viable plan for targeting highly esteemed universities in a scaleable way.
An AI service that is fully dedicated to a single product, does not take advantage of the purpose of the platform. When the same service would be offered and useful for other parties, this should increase the ‘usefulness’ rating.

Manu Gunther TxPipe

Project Owner

In charge of team and project management. Definition of tasks.

View Profile

alegadea

Technical leader

Cardano engineer in charge of the implementation, with strong experience in offchain and onchain coding. In charge of other developers' work.

View Profile

Account Pending

Senior developer

Cardano engineer with strong experience in offchain and onchain coding.

Account Pending