Everything we built, and why it works that way.

A smart account that the person owns through their passkey. Our servers prepare operations and pay the gas; they never hold a key that could sign one.

/pay @nova 5 lunch resolves the handle, checks the live balance, and settles on-chain inside the sender's mandate — or hands the approval back to their device.

Every account gets one automatically, generated from the email prefix and kept unique. Handles clean to 3–20 letters, numbers and underscores.

When a chat links, the account adopts that Telegram username as its handle if it is still free, so the name people already tag is the name in the ledger.

A WebAuthn P-256 key created on the user's device. We store its public key, the credential id, and the hostname it was made on — enough to prompt for it, never enough to sign.

There is no master seed. Nobody at Tagpay can move a user's USDG.

The smart account address is derived from the passkey's public key by the account factory, so it is reproducible from the key alone and identical every time it is asked for.

Gas fields are fixed in the operation itself, which keeps a signed operation byte-for-byte reproducible later.

An existing passkey wallet can be attached to a signed-in account by naming its address or its handle. It only restores visibility — every movement still needs the passkey signature.

Replacing a passkey is refused while the current wallet still holds USDG, so funds can never be stranded behind a key that is about to be replaced.

Inside the user's mandate, the relay calls USDG transferFrom from their address — an allowance they approved, not a key they gave away.

Above it, no signature exists, so the server builds a user operation and hands it to the browser for the passkey to approve.

A signed operation comes back with its nonce and signature. The server rebuilds it from the same inputs and relays that, so what lands on-chain is what the user meant to approve.

A stale or tampered approval simply fails to match, and nothing is sent.

handleOps can succeed while the inner transfer reverts. The relay decodes the UserOperationEvent and only marks a transfer settled when that event reports success.

The handle must exist, both accounts must have an address, the amount must be above zero and the live on-chain balance must cover it. Amounts are kept to two decimals end to end.

You can't pay your own handle.

An account below 0.00025 ETH is funded to 0.0005 ETH — roughly three operations' worth. Anything more would simply park the user's ETH.

Estimates are fixed: 150k call, 550k verification and 80k pre-verification gas, with a 0.2 gwei fee cap against a base fee around 0.02 gwei.

That prefunds about 0.000156 ETH up front. The EntryPoint refunds what the operation did not spend, straight into the account's own deposit.

ETH at the account's address, plus the deposit the EntryPoint still holds for it. Both are the account's money, so the balance page adds them together instead of showing a balance that looks short.

One passkey-approved operation moves both: the wallet's ETH, and the deposit via withdrawTo to the saved payout address. A small reserve stays behind so the operation itself can be paid for.

The challenge endpoint is public and read-only: it quotes terms or reports that the challenge is already settled. It never moves money.

On the payer's standing mandate, by sending /settle with the short code shown in the chat, or by approving it in the app when it is above the mandate.

Statuses are pending, paid, declined and expired. A closed or expired challenge answers 410, and an unknown id answers 404.

Turning it on is an approve call signed by the user's passkey. Turning it off approves zero, which revokes it on-chain.

A limit of zero is rejected, so enabling it always names a real ceiling.

The stored per-transfer limit and the live on-chain allowance must both cover the amount. Either one alone is not enough to spend.

That is why tampering with a stored limit still cannot pull funds — the allowance is enforced by the USDG contract.

Transfers, cash-outs and x402 requests under the limit run without a prompt. Above it, the operation is prepared for the passkey instead and the person finishes it in the app.

New accounts start with agent pay off and a zero limit. Nothing signs for a handle until its owner has approved the allowance themselves.

The app shows a one-time code. Sending /link TAGPAY… binds that chat to the handle the code belongs to, and the code is cleared so it cannot be reused.

A fresh code on another chat moves the link rather than making people hunt for /unlink first.

Telegram delivers updates to a single server route. When a webhook secret is configured, the header Telegram echoes back must match it, otherwise the request is rejected before anything is parsed.

In a group the bot is addressed by mention — @tagpaybot pay @alex 5 lunch — so the command still routes with the right context.

Each successful payment replies with the amount and the transaction hash. When the other side has a linked chat, they are notified that the USDG arrived or that a request is waiting.

The only private key the app holds is the relay wallet's, which pays gas and fees. It can sponsor an operation; it cannot sign for an account.

Prepared operations, key checks, allowance checks and record writes all run on the server behind a verified caller. The browser never sees a secret and never decides an outcome.

EntryPoint errors are translated — missing relay ETH, expired approval, mismatched signature, an account that couldn't be deployed — instead of surfacing a raw revert.

A payment is recorded as settled only after the receipt confirms and the operation event reports success. Otherwise it stays pending and can be reconciled.