Tippin' Dots by the BigTippers

This is the source repository for the April 2025 Harvard EasyA Hackathon submission of the Tippin' Dots project by the Bigtippers.

Tippin' Dots brings tipping token functionality to any social media supporting decentralized identities (DIDs). Tipping tokens allow users to send small "tips" in the token currency to their favorite creators, allowing for micropayments and providing monetization options for creators beyond those provided by the traditional advertising model. Tipping creates a more rich and interactive experience for audiences by creating direct financial connections and incentives with creators.

Unlike platform-specific solutions, Tippin' Dots works across the growing ecosystem of decentralized social networks, including Bluesky and Frequency. Inspired by the innovative open tipping tokens protocol, our implementation extends these capabilities to create a unified tipping experience regardless of where content appears.

Tippin' Dots keeps users inside of their own ecosystem, using replies and direct messages inside of the apps they already know and love to send tips and run tipping campaigns. Our approach avoids the "activation energy" problem entirely for users to participate. They only need to use specialized interfaces to fund and withdraw from their tipping accounts.

DIDs are the linchpin that makes our approach viable. They enable a trust model where verification does not depend on centralized authorities - instead, a cryptographic proof can be independently verified by anyone. This independent verification is extended directly to a smart contract in our model. Allowing users to control ownership and secure their tipping pools even without a pre-established cryptographic wallet.

In our implementation, we used Polkadot's smart contract functionality to integrate with Bluesky, with additional plans for Frequency. The demo shows the entire UX from tipping someone to registering a wallet and withdrawing funds, with additional UX (tipping pools, automated rewards distributions, etc) being relatively straightforward to implement in the current model without changing the underlying smart contract as currently implemented.

Our smart contract is designed to be extended to work with different types of DIDs by adding a registration function for each different type of DID. The contract lazily maps those DIDs to crypto wallets when users if users choose to deposit or withdraw funds. Because both Bluesky and Frequency have similar DID functionalities, the path to complete full signature verification is similarly direct.

We believe that Tippin' Dots can help creators build sustainable income streams directly from their most engaged fans that eliminate all middlement, while audiences gain new ways to recognize and reward exceptional content. Tippin' Dots builds a more connected, creator-friendly web where value flows to those who truly deserve it.

Demo Video

https://www.youtube.com/watch?v=9gQXEzlPyBc

Screenshots

Tipping!

The Monitor Bot Seeing and Recording the Tip

WebUI View for Manager on app.bigtippers.net

Deposit Workflow

Technical Details

Users primarily interact through social media interactions. To withdraw or deposit, they need to use the Web UI. All User social media interactions are processed by the Monitor Bot, and all financial transactions and wallet associations are handled by the smart contract.

Layout:

• src the Web UI.
• bot the bot code.
• solidity smart contract code.

app.bigtippers.net UI

The Web UI is a Vite app using react-router and tailwindcss. The app has two main pages:

1. src/pages/HomePage.tsx: Handles wallet connection and initial user interaction
2. src/pages/AccountPage.tsx: Manages account operations with modals for deposit, withdraw, register, and tip actions. There is also an admin panel visible by managers.

To interact with the Asset Hub blockchain smart contract, we use ethers.js with the following configuration:

{
            chainId: chainIdHex,
            chainName: "Asset-Hub Westend Testnet",
            nativeCurrency: {
              name: "Westend",
              symbol: "WND",
              decimals: 18
            },
            rpcUrls: ["https://westend-asset-hub-eth-rpc.polkadot.io"],
            blockExplorerUrls: ["https://blockscout-asset-hub.parity-chains-scw.parity.io"]
}

Special care is taken to ensure the user's Metamask-compatible wallet is on the right network. We also use a responsive design with both light/dark mode support, but have only tested the dark mode version extensively.

To deploy this app, we use Netlify with automatic build processes. Because we use a smart contract, we include compiling the smart contracts before building the frontend in that process using a prebuild command. The rest of the build process follows the standard build -> deploy strategy.

Layout:

• src/lib, Library code.
• src/pages, main pages.
• src/components, modals and other UI widgets.

The overall design of the WebUI is a simple wallet with Withdraw, Deposit, and Tip functions. We had planned to permit login via OAUTH on Frequency and Bluesky, but they required a lot of extra infrastructure that was not feasible to set up. This exposed a hole in our expectations that the web apps themselves would forward any proofs of identity to us and NOT our infrastructure. We were surprised to discover that both Frequency and Bluesky have webhooks that appear to require server-side processing first, and both included language that implied exposing that to the client was a security or privacy concern!

Monitor Bot

The monitor is a Bluesky bot that monitors mentions for tip commands. It's key functionalities include:

1. Watching for /tip [amount commands in mentions
2. Processing /register [wallet] commands for wallet registration

It also automatically marks notifications as read implements robust error handling and auto-recovery as a long-running process. For large numbers of notifications, it uses pagination. It connects to both the BlueSky API and the Smart Contract. It holds a private key of a manager so it can process tips and register wallets to users.

A number of additional functions were planned:

1. /pool [amount] [type] [timeout] to incentivize interaction on a thread. The type would control if payouts were based on likes by the owner, total likes, or some other system.
2. /letitrain [amount] [type] which gives out tips to anyone who interacts with a post or via other rules controlled by type.
3. /challenge [amount] [type] A payout that only happens when a certain challenge is met (e.g., # of likes).

For obvious reasons of time, we kept it simple. We think it is pretty straighforward how one might implement these given the existing functionality.

Right now the Monitor Bot validates user identities by receiving notifications of messages and the smart contracts privileges them to make wallet to DID connections (i.e., semi-trusted manager model). A full DID signature check requires additional work, which is entirely possible but did not have sufficient documentation or examples to do in the timeframe of a hackathon given the complexity of our smart contract. We also had planned to make the DID associations private but decided to punt on that for usability for now.

The bot itself was the most challenging component to build. The tooling for monitoring was not well documented and included subtle bugs, and we spent over 6 hours resolving an issue where the monitor would authenticate then tell us we no longer had a proper access token.

Smart Contract Details

We believe, except for signature checking, that the Tip.sol smart contract can be considered fully featured, with the following functionality:

1. Maps social media DIDs to wallet addresses AND reverse maps wallet address to 1 or more social media DIDs.
2. Handles deposits with a deposit fee and withdrawals with a withdrawal fee, all of which can be collected by the owner.
3. Supports tipping between users directly as well as via the owner and manager roles.
4. Role-based access control (owner and one or more managers).
5. Ability to add and remove managers and ability to transfer ownership.
6. Ability for users to transfer to new wallets. Managers lose the ability to set wallet mappings after a user asserts ownership.
7. Proper security features like reentrancy protection.
8. Comprehensive event emissions for all important transactions.

We deployed on the Westend Asset Hub (chainId: 420420421) via the REMIX client provided by polkadot.
We can implement per network DID signature checks by adding a single function, e.g., registerWithBlueSky function which performs that check. We believe it is possible to perform the check using the existing built-ins precompiles and, given the superior efficiency of the PolkaVM system, that our implementation will likely be as cheap or cheaper that most other EVM chains (and definitely cheaper than other chains of similar levels of decentralization!).

Presentation

https://youtu.be/o78nPBvRyKk

Presentation Slides on Canva

Submission requirements ✅-List

1. Be built with smart contracts on Polkadot Asset Hub

Contract Address: 0x888175972F6570894e7CA8F1cAe817047c9Ba835

Code: Tip.sol

Deployed (via REMIX): https://blockscout-asset-hub.parity-chains-scw.parity.io/address/0x888175972F6570894e7CA8F1cAe817047c9Ba835

2. Be open source (and remain available as open source)

Released under AGPLv3.0 or later.

3. Include a short summary (<150 chars)

Tippin' Dots brings token tipping to any social media supporting decentralized identities.

See Intro for more.

4. Include a full description (the problems it solves, how Polkadot was used to achieve it)

See Intro.

5. Include a technical description (what SDKs were used, and what features of Polkadot made this uniquely possible)

See Technical Details.

6. Include a link to the Canva slides used in the presentation (including a slide on your team, problem, solution etc). You must use Canva for your presentation (yes, this is a requirement).

See Presentation

7. (For coding submissions) Have a custom (not boilerplate) smart contract on Polkadot Asset Hub (and committed to your GitHub repo). All of this must be fully-functioning, as evidenced in a demo video on your README (see point 8 below).

8. (For coding submissions) Include a clear README on your GitHub repo explaining how your project works. This README must include:

   1. A demo video - See Demo Video

   2. Screenshots of your UI - See Screenshots

   3. Description of how your smart contract works - See Smart Contract Details

   4. A video with audio (e.g. a Loom video like this) explaining how your project works, how the GitHub repo is structured, a demo of everything working etc. This is vital, so that the judges can review your project properly. Make sure you explain clearly how you satisfied point 7 above. This is a great example of a winning Polkadot project’s README: https://github.com/jjjutla/melodot. Bonus points for if your video is well-edited! - See Presentation

   5. Block explorer link for deployed smart contract on Asset Hub - Deployed (via REMIX): https://blockscout-asset-hub.parity-chains-scw.parity.io/address/0x888175972F6570894e7CA8F1cAe817047c9Ba835