Budal

This project implements a budget allocating system like we can find in traditional banking system such as Qonto with their Digital Card features. This is super useful to control the company's cash flow and set precise rules regarding spending policies.

BudAl is a Web3 implementation of this system, giving a seamless experience to allocate cryptocurrency for buying goods and services. Using a simple UI, you can create an organisation managing different groups with specific budget allocation, permissions and spending limits. Using Circle API gives a simple abstraction around wallets so you can perform secure and verified actions on the blockchain in few clicks. Budal manage wallets for the user but also ENS domains to simplify the tree structure inside the organisation. For example, an organisation named "acme" will have an ENS "acme.budal.eth" and its group will be prefix by the organisation ENS (e.g., "marketing.acme.budal.eth"). This also allow users to validate action performed on a smart contract using a simple PIN code.

Then you can interact with your organisation following a graph view and add different people to it. Each member of the organisation can be include into a group to be able to claim part of the budget. As we said before, when you create a group, you can define different settings such as the amount of token allocated, the spending rate and limits. To ensure the respect of the limits, everything is defined in a smart contrain on chain that we developed and the Budal backend serves as a proxy to hide complexity.

When a member of a group want to use the money, he can simply apply for a claim and he'll receive the money on its registered address (an user managed account of Circle API) after approval.

The BudAl WebApp also use the Nouns DAO to display member's profile picture, we planned to add an evolution process depending on the role and budget used but we didn't had time unfortunately.

In short, Budal is an accessible solution to democratize cryptocurrency usage around businesses and mostly target B2B customers.

The project is composed of 3 different part:

• The WebApp: a simple React frontend to manage budget allocation.
• The Backend: an Express TypeScript application to handle the logic.
• The Smart Contract: an ERC 20 contract to store allocation on chain.

The WebApp uses the Tailwind component library to display elegant components and Next to run the application. For request caching we use RTK. We also used the Circle Web SDK to setup user controlled wallet pin creation, providing a nice and secure way to create a wallet without directly dealing with web3.

The Backend is done in TypeScript and runs on Node using tsx. It exposes a REST API that handle the logic inside its endpoints (user creation, authentication, organisation and groups management, operations on chain...). We use redis to store user sessions, prisma/sqlite to store permanent data that we don't want to store on chain and zod for input validation. The backend also implements a wrapper around the Circle User SDK to perform create the user, initializes its wallet and get user's related information stored by Circle. On top of that, we extended the existing Circle SDK to perform contract execution, unfortunately, this feature wasn't implement in the SDK so we create our own called ContractSDK. This is in charge of the interaction with our deployed smart contract that store and manage an organisation. We also added a wrapper around the ENS client to verify and create subdomains for organisation and group. It uses the viem library and @ensdomain to interact with the ens contract.

The Smart contract is responsible of the management and allocation of the differents groups and budget inside an organisation. It stores datas sent by the Budal backend (ENS, wallet address...). There are multiples methods such as budget allocation, the spending rate and its limits (e.g a budget of 1ETH with a spending rate of 0.1ETH by day).

Some hacky things we did to make things works:

• We had to some type of the Circle User SDK that were not exported (specially enumerations like ContractType and Blockchain)
• We needed to implement our own ENS registration logic that directly interact with the contract and we met big difficulties dealing with permissions and ownership. That's why we actually create a domain budal.eth and then added organisation and groups as subdomain of this domain because it didn't required to wait 60 seconds for the domain approval and deals with complex permission issue.
• Some methods and logic were missing in the Circle API so we grouped some calls and extended the API when needed using fetch. We also needed to use fetch and not axios because it brokes for an unknown reason.
• We had an issue when registering sub ENS domain (mygroup.orga.budal.eth), it seems we needed to wait a certain amount of time (3-5 minutes) before being able to create them. During that time, we were hitting a unknown error thrown by the contract without more details.
• We struggle finding what we should store on chain and what we should store in our database, it was hard to make an efficient mapping. Having a sort of SQL store on chain would have been perfect!
• Because every operation on chain processed with a Circle user controlled wallet requires a signature with a pincode, we couldn't create unit test nor integration tests on the backend side. That would have been much better if we had a way to bypass the verification for testing the logic of the backend automatically.