Universal Social Tipping

Universal Social Tipping lets anyone tip a creator by platform + handle (e.g. twitter / @somehandle) without that creator having done anything on-chain in advance, and without the tipper ever authenticating with the platform at all. The creator only needs to log in once — at claim time — to prove ownership of the handle and sweep everything that's accumulated for them.

The deterministic escrow key

Every tip is filed under a creatorKey — a bytes32 computed on-chain, deterministically, from the platform and handle alone:

function creatorKey(string memory platform, string memory handle)
    public
    pure
    returns (bytes32)
{
    return keccak256(abi.encodePacked(_toLower(platform), ":", _toLower(handle)));
}

Both platform and handle are ASCII-lowercased before hashing, so X / x and SomeHandle / somehandle land in the exact same escrow bucket — tippers don't need to know or match a creator's exact casing. Because the key is a pure function of two strings, anyone can compute it and deposit into it — via tipCreator directly, or via OmniTokenomicsEngine.collectFee auto-streaming a token's configured creator-royalty share into the same bucket on every trade (see Holder Yield & Creator Royalties). Organic tips and streamed trading-fee royalties both settle into one ledger per creator, claimable in one call.

Zero-OAuth for the tipper, OAuth-gated for the claimer

Depositing a tip (tipCreator) is deliberately permissionless and requires no identity check at all — crediting *more* into a creator's escrow bucket can't harm them, so there's no reason to gate who's allowed to do it. Claiming (claimTips), which sweeps that entire bucket to a wallet of the claimer's choosing, is the sensitive operation, and that's exactly where the OAuth check lives — enforced by LFG Pad's backend, not by the tipper.

The claim flow

1. 1

   Creator logs into the LFG Pad backend via OAuth

   The creator authenticates with the platform they're claiming on (X, YouTube, etc.), and the backend independently verifies the resulting access token against that platform's own identity endpoint — never trusting a client-supplied handle outright.
2. 2

   Backend computes the digest and signs it

   Once the handle is verified, an oracle signer key signs the exact attestation digest claimTips expects on-chain — see Oracle Signing for the byte-for-byte digest layout.
3. 3

   Claimer submits `claimTips` with the signature

   Anyone can submit this call — typically the creator's own wallet, or a backend relayer paying gas on their behalf. OmniTippingEscrow verifies the signature came from the configured verifier, then sweeps every token ever tipped to that creatorKey straight to the claimer's chosen address.