Munujo - secure CBDC banking

Inspiration

We’ve been brainstorming starting with CBDCs properties. These assets are crypto by nature but might repel some crypto-natives with extended scrutiny that might be coming from central banks managing the currency. So most likely the users would be those types of businesses who are already well regulated and would see CBDCs as a safer alternative to decentralised crypto assets. So the main users are, most likely, some sort of institutional players that lean towards traditional banking. But traditional banking comes with certain guarantees - namely, stricter security and no single point of failure, even if the platform is being targeted by hackers - the funds should be retrievable.

That’s how we came up with an idea to use XRP’s existing multi-signature wallets functionality to provide a platform for banks to serve as co-signers of transfers so that even storage of larger funds on-chain wouldn’t pose risks since even if the key is stolen - any large enough transfer would need to be verified by the bank’s employees off-chain.

What it does

Munujo is a multi-signature wallet solution where at least one of the co-signers is a bank which verifies the transactions off-chain to exclude potentially fraudful transactions in case the private key of the depositor was compromised. Additionally, we require a third signature that is a depositor’s trusted entity (or another bank if there is no one you can ask) - who can help with account retrieval in case the private key is lost.

How we built it

MVP: a simplified interface for XRP’s multi-signature wallet functionality. We set up multi-signing on the account (2 out of 3: depositor, bank, trusted entity - another bank or 3rd party the depositor trusts), disable the master key pair to ensure the funds can’t be stolen if the master key is compromised.

We are providing separate interfaces for prospective funds depositors and banks.

Depositors can:

See the list of participating banks
Create an application with KYC details
Create transactions
Initiate process of multisig access retrieval in case their private key got lost Banks can:
See the list of incoming wallet creation requests, start KYC process and off-chain verificaiton
See the list of upcoming transactions for all the clients
Review access retrieval request in case the user lost their private key. This requires a third trusted entity to sign a transaction, which would only be created by the bank after verifying the request with the depositor off-chain/in person Additionally there is a simplified account type for a trusted co-signer who can be added for security overrides to transfer the money without bank’s involvement, or to help restore access to the account owner if the key is lost. This account sees a simplified version of depositor’s UI that only shows the list of pending transactions

Challenges we ran into

Initially we wanted to implement the transaction thresholds in the MVP but it seems that we’d need functionality provided by XRPL Hooks or something similar, so for now we focus only on the banking and transaction interfaces that in any case provide the core values of our product.

UPD: We've dived into XRPL Hooks but the ecosystem compared to EVM development is a bit more complicated to get started, the main problem is that you can't just do everything you might need without complicated setup (as compared to Metamask+Etherscan-based explorers for EVM). We've got some prototype code for the multisig almost ready based on the Hooks example, with added tresholds for smaller transaction. But in general it seems that one of the ways everyone would actually benefit - is simplifying development on-boarding. It seems that this might be the focus of our team for the upcoming hackathons since Ripple is a very promising platform, we just need to attract more developers with easier development tools

Accomplishments that we're proud of

Previously we had exposure mostly to EVM-based chains and Solidity development, so it was interesting to dive into the XRP ecosystem and discover the inner workings of the consensus algorithm, multi-signature implementation and the sidechains setup that can potentially be used to implement the service that we are building

What we learned

Design of XRP Ledger, consensus algorithm and basic transaction types
XRPL Hooks can be used to write additional logics similar to smart contracts in EVM chains

What's next for Munujo

We are currently building an MVP of our service based on the simple multi-sig setup, starting with the user flows for both depositors and banking employees. During the Phase II we would also like to explore XRPL Hooks for potential expansion of the multi-signature wallet functionality, to allow users to set thresholds for transactions that might trigger multi-sig requirement. Infrequent small transactions should be done without the involvement of bank operators, but bigger or frequent small transfers should trigger the necessity to sign the transaction by the bank.