Project details
This RFP will be delivered in a collaboration between GenWealth and BroClan.
GenWealth is a Crypto Inheritance and Crypto Recovery Dapp Building on Cardano. Leveraging GenWealth users can create their own unique self-custodial vaults. Vault owners can use the vault similarly to a wallet, but in addition, they are able to set rules to recover their own crypto in case they lose the seed phrase, as well as define beneficiaries and allocate assets. Once you're no longer here, your beneficiaries will be able to connect to the Dapp and claim the specific assets you left for them. No more lost tokens or lost NFTs, no more sharing seedphrases or trusting intermediaries. Now you have a safe way to leave your crypto and your wealth to the next generation.
GenWealth leverages Cardano Smart Contracts to deliver this solution.
BSP Tech is responsible for the development of several different solutions on Cardano.
While hired by other companies in the Cardano Ecosystem, BSP Tech played a crucial role in developing Aneta BTC, a protocol that wraps BTC onto Cardano and Ergo, allowing Bitcoin holders to have access to DeFi opportunities on Cardano Leveraging Bitcoin.
On an Internal level, BSP Tech was responsible for the development of the Bro Clan Wallet, a user-friendly Multi-sig wallet that makes multisig functionalities accessible to less technical users and companies.
Together GenWealth and BSP Tech are exploring a collaboration effort to develop a flexible and empowering platform for companies to manage funds. This platform leveraging smart contracts, would allow companies to issue and manage permissions, as well as create rules for who can manage the funds, or how to recover funds in case one or several of the leaders of the organization pass away.
Our focus is on Building secure solutions, that empower users to have more control over their funds, and consequently their life. Having control, security, and being prepared and empowered in any eventuality is the key to providing our users with peace of mind.
As part of that Collaboration, we decided to apply together to this RFP, as it fits in well within our broader collaboration efforts, having a lot of overlap with our expertise and with our area of development, related to smart wallets, and leveraging smart contracts for added functionalities when managing funds.
Taking into consideration the RFP, with our proposed solution we are confident we can deliver the core functionalities requested:
-
Token deposits with concurrent channel creation,
-
Claiming funds from payment channels with appropriate signatures that are generated on off-chain by client or daemon service,
-
Management of channel expiration, allowing clients to claim unspent funds from channel after channel expiration,
-
Extension options for channels, allowing customers to add funds or extend expiration as needed,
-
Secure handling of token transactions without relying on a global state,
-
Flexibility for service providers to have multiple concurrent payment channels.
Additionally, our proposed RFP will also deliver the following Functional Requirements:
-
Fraud prevention via secure signature validation,
-
Support for only one type of token or asset class,
-
On-chain and corresponding off-chain code with implemented functionality:
-
Open channel, tied with token deposit
-
Extend channel expiration
-
Add funds to channel
-
Extend channel expiration & add funds to channel
-
Claim funds from payment channel
-
Claim funds from payment channel & close channel
-
Close channel, when channel is expired
-
Return remaining funds to client, when channel is closed
-
Generate signature for AI service payment (off-chain)
-
Verify signature for AI service payment
-
Multi-channel claims in a single transaction,
-
Token transfer logic external to the MPE script, managed off-chain,
-
Channel identification through unique Channel Tokens.
As for the Extended multi-channel operations, allowing for complex service provider interactions with clients, a new script would have to be written to accommodate new functionality, with it a new deposit address and policyId will be created.
As far as we understand, this would mean our solution to this RFP would be able to deliver and meet all the required functionalities.
Considering the clear need from the RFP, to have a solution that can be upgraded, we will also invest considerable focus into comprehensive documentation of the solution we built, to ensure it would be an easy process to understand and interact with the solution we have delivered, as well as build on top of this solution.
From our plan, we stand available to deliver Typescript library to be able to interact with smart contracts, as well as an API in case you prefer other sources of integration. Developing both solutions will provide you with more flexibility moving forward in the future, while fulfilling the requirement of delivering the offchain components necessary to interact with the smart contracts.
Typescript was chosen because it is the most common off-chain language to build on Cardano, which will be positive for future RFPs to upgrade this solution, as it would allow you to be able to access a larger pool of developers for those endeavors.
Following this same reasoning, we will leverage Aiken, a DSL for Smart Contract Development on Cardano, as it is the most used language to build on Cardano, and the language with the largest pool of developers on Cardano. It is also an extremely performant language, which allows us to fulfill the non-functional requirements, such as reliability, performance, and maintainability.
For the Development of this proposal, we explored two different solutions
Using Native Scripts:
Using Native scripts we can create a dedicated script for each payment Chanel. Ensuring that the payment is accessible and secure and fulfills the requirements of our channel.
We can handle creating a custom Typescript library and API service that creates and operates payment channels based on native scripts.
Benefits:
-
Cheaper: Since native scripts are deterministic and have limited logic the executing of transactions using them is much cheaper and does not require collateral.
-
Safer: The limited logic of simple scrips almost eliminates the risk of any unforeseen bugs in the contract that could lead to a loss of funds
-
Cheaper implementation: Native scripts are already widely used in the Cardano ecosystem making popular libraries like lucid and lucid-evolution support them natively.
Drawbacks:
-
Multi Address: Using native scripts for this solution would mean that each payment path will have its own unique address, making indexing and tracking all the channels significantly harder
-
Cannot enforce some requirements: Specifically the requirements “ Channel identification through unique Channel Tokens”[can be implemented but not enforced], “Extend channel expiration”[cannot be implemented/script migration required].
*Native scripts are a form of contract native to the Cardano ecosystem, they have 6 commands(All, Any, AtLeast, KeyHash, Before, After) and allow nesting.
Creating a new Plutus Script:
Plutus scripts are Turing complete and can facilitate any logic we require, by implementing a plutus script we can fulfill the requirements for an MPE system native to Cardano.
We can handle creating a bespoke Aiken script that:
-
Creates a new payment channel and mints a corresponding token to be locked in the payment channel UTxO
-
Allows the payment of the provider (full or partial) if the corresponding signature in present
-
Allows the extension of the expiry date (if the client's signature is present)
-
Allows the closing of the channel and withdrawal of funds after expiration
-
Ensures the burning of the channel token on channel closure
-
Allows the withdrawal of malformed UTxOs by an admin
Additionally, we can create a custom Typescript library and/or API service that creates and operates payment channels utilizing the aforementioned Plutus script
Benefits:
-
Fully compliant: Using Plutus we can ensure compliance with all the MPE requirements
-
Single Address: Using Plutus we can put all payment channels under the same address, this will make indexing much cheaper and simpler.
Drawbacks:
-
Cost: Plutus scripts are significantly more expensive to execute than a simple/native script.
-
Smart contract risks: Even though Cardano Contracts are much more resilient to faults that could cause the loss of funds they are not invulnerable, a bug in the contracts implementation or the underlying stack [Aiken/UPLC] could lead to the loss of funds, BSP tech services can provide auditing services in house and with external partners to minimize that risk if required.
-
Added complexity to operation: The bachelor that executes the contracts on the backend will need to own a set of keys that hold a small amount of ADA and use that as collateral during the executing transactions.
-
Implementation Cost: Implementing the Contract and performing the audits required will increase the cost of delivering this solution.
In order, to ensure compliance with all the requirements, as well, as give more flexibility and more capacity to this MPE solution, we opted for the second option for this proposal. In addition, the development of this solution leveraging smart contracts, will allow for a higher future potential of upgrading and building on top of this solution.
Join the Discussion (0)
Please create account or login to post comments.