SafePay

SafePay

SafePay is an on-chain mandate payment. A protocol to swiftly manage customarily periodical transactions both in ETH & in ERC20.

SafePay

SafePay

SafePay is an on-chain mandate payment. A protocol to swiftly manage customarily periodical transactions both in ETH & in ERC20.

The problem SafePay solves

Akin to the mandate and credit payments in banks, safe pay provides automated micropayment functionality to gnosis accounts to make periodical transactions of cryptos and tokens. The dapp can be used to make micropayments for subscription-based models used by all types of service-providing traditional companies like Netflix, google services, eCommerce subscriptions etc. as well as the other web3 applications like budgeting and accounting subdao funds or any other enactments additionally providing the authority to the payer to seize the micropayments and withdraw in case of unsatisfactory services or for the payee to stop the service in case if the payer is unable to pay for the further subscription.

The dapp developed during the hackathon serves as a POC to build an easily integrable component to manage micropayments. Currently, it supports eth and erc20 transfers. As future extensions, it would include multiple chains and token transfers. The ideal vision is to unify payments & wallet recover all the wallets. Apart from solving all kinds of crypto payment hassle this module can also be used as a DCA module as described here. I believe this too also a cool perspective to look at because it perpetuate the possibility of non-custodial DSA.

Challenges I ran into

Oh, this project was a hell of a ride, from the team being unable to show up to being confused about the idea itself, the struggles were not stopping. But the time came and I got on with the

SafePay

since then it's been smooth except for only technical issues and design choices. Here are some of the tough ones that I faced:

  • Choosing between allowing any safe owner to call

    acceptRequest

    function or doing it conventionally by first multiple people signing the transaction, then confirming it and then executing like a normal multi-sig. I chose to go forward with the latter one, which is multiple people signing transactions as I did not want to compromise on security.

  • The second issue came when I thought about supporting sending ETH as well as ERC20 to the payee expecting money. Even tho technically it was not a wild difference, mentally it was a blocker due to the fast-paced environment and little to no planning. But nothing to worry this feature does exist in the current version now.

  • Third & Last was the UI, I recognised that to be a good utility project it will need a UI as it's very problematic to go the etherscan or some other explorer to interact with smart contract. But with little experience in the front end, the idea felt daunting and demotivating at first but with help from the mentors, it did end up being a good enough UI to complement the project's utility.

Tracks Applied (1)

Safe

Safe

Discussion