The problem Tipping Point solves

Moving money around these days is easy, but coordinating social consensus around projects or events is hard:

-Sometimes the price of attendance depends on how many people opt in, but most people won't opt in until they know the price.

-Sometimes people only want to participate if they know other people are participating too.

-People frequently back out or have to cancel at the last minute.

-Many ideas can only come to life if a particular threshold of participation is reached.

Tipping Point solves these problems by helping users first plan and coordinate their projects with their network, based on the number of contributors or attendees they want and the amount of money they need to raise.

Then, if the fundraiser hits their targets, the project "tips" and they receive precisely the funding they need.

Creating an event on the platform is simple: after connecting their wallet users just add the details, define their goals, set a deadline, and invite their network. Once enough people participate, the project tips — and the funds are immediately sent to the creator's wallet.

By building on Base and cutting out the financial middlemen like payment processors and banks, Tipping Point can charge fees 50-90% lower than any other crowdfunding platform other there. And due to the decentralized nature of the Ethereum network, Tipping Point can never seize users' funds, censor their activities, or deplatform them from the app.

There's no personal or financial data required - all users need to do is connect their wallet and set a display name to get started. Because we never collect that data in the first place, there's no chance of it getting stolen or abused. And of course Tipping Point never has access to user funds, which are always self-custodied in users' wallets.

Finally, Tipping Point has no token: users can try as many fundraisers as they like for free, and only pay a small fee (1.5%) of the money raised if their crowdfund is successful. No risk, all reward!

Challenges I ran into

Escrow dApp vs Bank Teller smart contract implementation: One of the first challenges we ran into was how to implement the web3 aspect of our app: the coordinated payment function, when an event successfully tips and funds are to be transferred to an event creator.

The first idea we had was an escrow mechanism, which would require all invitees sending funds to an escrow contract beforehand, and if an event is successful they transfer to the creator at the deadline, else they refund to invitees.

The were drawbacks though: we'd incur gas fees for transferring funds (& refunding them) regardless of success; increased security risk holding user funds (larger attack surface); implementation is immutable since the contract would hold the bulk of app logic on the blockchain as a dApp.

We weren’t satisfied with a dApp implementation that escrowed funds and held most logic to transfer funds, so we settled on a more narrowly scoped smart contract, called the Bank Teller. This smart contract focuses on safely transferring funds from users A thru Y (invitees) to user Z (creator) without escrowing funds.

This was a big improvement: no escrow; less responsibility & thus code; and it allows more app code to reside in web2 domains (node, AWS, etc) to allow upgrades and extensibility of features/changes.

Another challenging aspect of a Bank Teller contract (a money-transfer approval/signature based gating contract) was keeping the UX simple, yet comprehensive enough to protect user funds during the most significant step in the process.

To sum up how that was accomplished, we consolidated all the data an invitee would sign off on (who gets their $, how much, deadline, nonce, compensation to TP for executing their gasless-USDC allowance call [paymaster backup]) into one eip-712 structured typed data message that they sign with their wallet which can be executed in the BankTeller smart contract. This lowered the wallet signatures needed from 3 to 2 to opt-in to an event.