Why are you participating for Based SEA?

Inspired by Jesse's vision of an onchain economy, I felt that building a product that I will use financially everyday resonates deeply with Jesse's vision. I came to realise recently that 99% of the transactions that I make today aren't onchain and I thought to myself: "Why am I not moving the way I transact everyday in TradFi onto the Onchain Economy?". The Onchain Economy has a ton of reasons as to why being onchain is better, but there isn't enough reasons for a person to commit to moving onchain. Hence the reason why I built Cube - a solution that brings a payment system that I use everyday in my life ONCHAIN.

By building a product in Based SEA, my goal is to make this product an actual solution to encourage people to come onchain and stay onchain. I hope that with the help of Coinbase (for onramps and offramps) and Base (robust, fast and cheap network), I can create a product that I would personally use everyday in my life for payments / transactions.

What challenges are you focusing on?

I have 3 main challenges that I am focusing on:

1. Onchain Users to be able to stay onchain, with access to real world food / goods / services
2. Onboard millions of merchants onchain to form The Merchant Network. The Merchant Network will be the main reason why normies would want to come onchain - which is to use onchain money to get food / goods / services from merchants that are onchain.
3. Expose the onchain economy to yields that they could've been earning if they stayed onchain.

Singapore ranking as the 2nd Highest Population of crypto-owners (24.4%) screams to me that we need an onchain solution to serve the people's needs. With today's payments solution, this would mean that approximately 1.38 million crypto-owners in Singapore will have to off-ramp some of their onchain assets just to access TradFi good/services. However, with Cube, these crypto-owners can STAY ONCHAIN and pay onchain.

SGQR (which is Singapore's Unified QR Payments System) has over 1.9 million unique merchants within their database. Tapping into this would mean that 1.9 million unique merchant services would be available onchain, hence creating the demand for normies to want to come onchain.

Yield-generating opportunities onchain is something that isn't widely adopted because of the complexities. Removing that complexity for onboarded normies by packaging the yields in a service can bring more capital efficiency to the onchain economy and to the normies.

How does your submission address this challenge?

Cube being a Seamless Interoperable QR Payments Solution is starting off by creating a Merchants Registry Contract containing the UENs of merchants (Unique IDs that SGQR uses to identify merchants). This Merchants Registry will expand into The Merchant Network, which is an immutable list of UENs tagged to Merchant's wallet addresses. (Registry.sol)

The Merchant Network will essentially bring millions of unique food / goods / services onto the onchain economy, for crypto-owners to transact on without having to off-ramp, while onboarding normies and merchants to use onchain solutions. In Cube, I added an ERC 4626 strategy that essentially maps the USDC spent by users to the merchant's vault, allowing merchants to earn USDC yields from Aave V3 market on Base. This process is essentially streamlined on the frontend to negate the complexities faced for the end-merchant. Merchant can choose to withdraw whenver they want to (whenever they do their monthly accounts / annual accounts etc.)

Therefore, bringing Merchants onchain = Food / Goods / Services are brought onchain = Crypto-owners will stay onchain.
Yield strategies are always a fun one to build especially when an onchain economy have thousands of choices to choose from :D

Challenges I ran into

There were a few blockers I faced, particularly with integrating Basenames with Paymaster into my dApp. I was trying to integrate Paymaster with Basenames to sponsor user's name creation, but there was a function in the RegistrarController that requires a user's wallet to have onchain funds first before being able to get their Basenames. This means that dApps aren't able to properly provide a smooth gasless experience to onboard new users on Base with a Basename if they wanted to. Here is the snippet of the code in RegistrarController.sol that caused this error.

    /// @notice Enables a caller to register a name.
    ///
    /// @dev Validates the registration details via the `validRegistration` modifier.
    ///     This `payable` method must receive appropriate `msg.value` to pass `_validatePayment()`.
    ///
    /// @param request The `RegisterRequest` struct containing the details for the registration.
    function register(RegisterRequest calldata request) public payable validRegistration(request) {
        uint256 price = registerPrice(request.name, request.duration);

        _validatePayment(price);

        _register(request);

        _refundExcessEth(price);
    }

Another blocker I faced was with Coinbase Smart Wallet, whenever I use wagmi + viem to call writeContracts, even though I have added the ChainId into the function call, Coinbase Smart Wallet will always default to Ethereum mainnet network. I have raised this to Tina and on Base Discord :D so hoping that that could be solved! I have a video of this bug as well, just ping me on warpcast to see the bug! :D

Additional Features

This project is new and was built from scratch during the Buildathon period. :D