Mastaa

Mastaa is a project around a modular paymaster.

The basic principle is to allow a decentralized application (any application) to deploy a paymaster, which will allow it to sponsor the transaction fees of a part of its users, for example for new users.

The way it works is quite simple: the deployed contract is a proxy (more details in "how it's made"), which uses a module to match the "paymaster" qualification. It is completely customizable, and the solution we propose allows teams to implement other modules (or remove existing ones).

Before continuing further reading, an important information: the project demonstration can not be done in full, we can only deploy the contract but we have no interface to test it afterwards. Indeed, even if we think that our smart-contract is functional (for the Worldcoin module, we can’t say because we have no way to test it), we didn't have enough understanding of the tools to test it (Trampoline in particular). With a bit more time, we probably would have made a more polished implementation. There was also an error fixed on trampoline quite late in the hackathon, which blocked our understanding for a while unfortunately (but we don't blame the team for that, we know how hard it is to maintain code and deploy features on very recent technologies).

After this little disclaimer, we can continue : One of the first problems with the paymaster concept is sybil: imagine you are a decentralized protocol and you want to allow new web2 people not to pay their first transaction fees on your platform. You don't want someone with bad intentions to drain the cash you've made available for this, by spamming transactions. That's why we have developed sybil protection modules, which allows you to choose several ways to make sure that no one can burn all the funds.

For this theme, we have decided, in the first instance, to offer a module using Worldcoin. Ultimately, it is possible to integrate many modules, such as a module with sismoConnect, with Gitcoin Passport, a module with Lens Protocol (based on a verified user system), ...

The application also allows you to choose different parameters to configure the sponsorship, including: whether or not to enable immutability, the number of transactions the protocol wishes to sponsor, whether or not to make the contract inspectable (this allows you to see which modules are plugged into the contract and which are not, but it costs a bit more gas) and the address of the owner. Each parameters is in fact a module, that can be added or removed, as desired. If they wish, teams can completely remove modules, or develop others based on our reference contract (even if there is only one function left). The contract really allows for extreme modularity, to be able to adapt to the needs of each protocol, which can choose the modules of its choice.

As the modules developed by the protocols will be audited, this improves security, as everyone will have access to a list of tested and audited modules for their own projects. There are many modules that can be implemented, that we could not develop during the hackathon time, but that are very interesting and that we would like to implement (or see someone do it 👀), here are two of them:

• Promocodes: you can deploy your customer acquisition funds closer to the end user, with promocodes allowing free transactions on your platform. A web2 concept, in web3 it can work too. Imagine all the possibilities with codes like this.
• The possibility to pay with other tokens than ETH (a swap feature in a way). This swap idea is not very original but here is a little twist: to reward their users, platforms that create tokens (governance, or even 👀👻 stablecoins) could reward their users by paying part of the gas fee.

Mastaa is a short but not so simple story: when we arrived for the hackathon, we had an idea about account abstraction, but on the first day, after a (very) long discussion with the Safe team, we realized that it was not at the point we wanted to bring with this hackathon, as the idea had already been developed (and well developed). As we also had another idea with this scalable paymaster, we decided to develop this one, and we found some features along the way.

As the ultimate goal is to have this paymaster used by decentralized applications, we decided not to make a backend for the hackathon, and to do all the necessary operations on-chain. We created a dashboard to allow teams to manage the paymaster once deployed, but since we can't test it now, neither can the dashboard. Eventually, we will be able to implement a more complete management on the smart contract, and everything can still work without the frontend. To enable this modularity on deployed paymasters, we are implementing the ERC-2535 (which standardizes scalable smart contracts after deployment, you can find the documentation here, for those who like technical stuff: https://eips.ethereum.org/EIPS/eip-2535). So we spent some time developing this contract which is the basis of our project.

The technical stack is : Solidity and JavaScript (with a React framework, Nexth). In terms of sponsor technologies, Worldcoin technology fit perfectly into our project, and is even essential to build serious paymasters, because as said above, sybil is a big problem that is important not to overlook. Worldcoin allows, when users connect their World ID, to be sure that the user is unique, there is no way around that.

We would have liked to build on Sismo as well, because Sismo does the same thing, with "proof of humanity" badges, but not only. It is also possible to consider a community creating a badge (a guild), and paying for the gas of its users. To verify that a user belongs to a group, we can use sismoConnect. Since we already couldn't test the module with Worldcoin, we decided not to implement a Sismo module (which couldn't be tested either).

We focused during this hackathon on the modularity side of the paymaster, but we also planned to develop a more complete application. The ecosystem around the paymasters is not mature enough and we lacked tools to properly test some of the features of our application.

With the rise of account abstraction on Ethereum and L2, partly thanks to the ERC-4337 but also thanks to the work of many teams, relayers will take a growing place in the functioning of blockchains, and we believe that paymasters are bound to develop, and that they will simplify the onboarding of new users, while allowing communities to reward their members. We are proud to have been able to propose a very modular solution, because we think it is important that each protocol/community can develop its own modules according to its specific needs. Our trials to build modules, even if we think they are interesting (otherwise we would not have developed them), are only examples of the field of possibilities offered by this solution. We deployed this solution on Polygon, because it can be useful on this chain too.