TipRouter

Demo

About

Decentralized social networks such as Mastodon and Misskey solve an important identity problem: users do not have to depend on a single centralized platform. But the economic layer is still missing. Server operators pay infrastructure and moderation costs, creators have no interoperable way to receive value, and payment destinations exposed by a server still require trusting that server. TipRouter is a thin Web3 payment-routing protocol designed for existing decentralized and federated social services. A service host publishes its supported payment destinations and routing fee at `/.well-known/tip-router`, while users publish their own payment destinations in their profiles. A TipRouter client discovers both sides, finds a blockchain supported by both the user and the host, and routes a tip between them. Our first demo shows that this can work with existing services such as Mastodon and Misskey without moving the social network itself onchain. Entering a profile URL is enough to discover the user’s payment destination and the payment destination of the server hosting them. Concrnt, our existing decentralized social network, demonstrates a stronger version of the same protocol. Concrnt users already hold their own identity keys and cryptographically sign their posts and reactions. TipRouter payment destinations can therefore be published through the same signed mechanism, allowing clients to verify that a destination was actually authorized by the user instead of simply trusting the server. On top of this, we built Super Reactions: a fast tipping experience where a user selects an amount, authenticates with Face ID, and sends a visually prominent paid reaction to a post. Underneath the simple UX, TipRouter discovers, verifies, routes, and settles the payment between the creator and the service host. Before ETHGlobal Tokyo, Concrnt already existed as a decentralized social network but had no Ethereum integration or payment layer. During the hackathon, we built TipRouter, added blockchain key derivation to Concrnt, deployed the payment contracts, implemented signed payment destinations, created the Super Reaction UX, and built the Mastodon/Misskey interoperability demo.

How it's made

TipRouter is intentionally designed to keep the Web3 layer as thin as possible. Each participating service exposes a small JSON document at `/.well-known/tip-router`. For example, it contains a protocol version, a host fee in basis points, and payment destinations for supported networks: `{"feeBps":500,"tipjars":{"ethereum":"0x...","sui":"0x..."},"version":1}` Users expose their own per-chain payment destinations through their social profile or, in Concrnt, through a signed document. The client takes the intersection of the networks supported by the user and the host and selects a compatible chain. Settlement is handled by deliberately small TipRouter contracts, roughly 100 lines each, implemented separately in Solidity and Move. The contract atomically accounts for the creator and host portions of a tip using a pull-based model, so recipients can withdraw their accumulated balance later. We deployed the Ethereum implementation to Sepolia and implemented Sui as a second-chain example to validate that the protocol itself is not tied to a single network. For the Mastodon/Misskey demo, we treat a profile URL as the user entity. Fetching arbitrary federated profiles directly from a browser frequently fails because of CORS, so we built a Cloudflare Worker that resolves the remote profile and extracts the TipRouter information for both the user and their host. This lets an existing federated social account participate without requiring a custom blockchain integration in Mastodon or Misskey itself. Concrnt provides the stronger verification model. Concrnt already has an identity key system where users cryptographically sign every post and reaction. We publish TipRouter payment destinations using the same signed-document mechanism, which means a client can verify that a payment address was authorized by the user rather than merely asserted by their server. The Concrnt desktop app is built with Tauri. Private keys never enter the WebView and exist only inside the Rust layer. When the frontend requests a signature, the Rust side invokes Face ID or the platform biometric authentication mechanism and signs only after successful authentication. A Super Reaction roughly follows this flow: Click → select amount → create a signed Concrnt document → construct a TipRouter transaction bound to that document’s hash → commit the document → settle the tip. One of the most technically important decisions was what we chose *not* to put onchain. Instead of recreating social identities, posts, reactions, or ActivityPub on a blockchain, TipRouter starts from an action that already exists in the social layer and anchors only the information required for payment and settlement. The goal is to use as little Web3 as possible while still gaining verifiable ownership and programmable payments. This is also why TipRouter can work across very different trust models: Mastodon and Misskey can use it as a lightweight payment-discovery layer today, while a self-sovereign system such as Concrnt can additionally provide cryptographic verification of the user’s payment destination. No partner SDK is required by the core protocol; the multi-chain design is part of TipRouter itself.