Two days ago, a Discord user named @test17 received $838 USDT on Celo. They had no account on our platform. Someone typed a command in a Discord server and the money appeared, waiting on-chain for whenever they were ready.

That is MagicPay. This post is about how we built it.

The problem we were solving

The standard flow for sending someone crypto is: they give you a wallet address, you paste it somewhere, you approve a transaction, you pay gas. That is four steps before a single dollar moves. If the recipient does not have a wallet yet, add three more steps before they even get to step one.

For a social payment primitive to work at scale, the recipient side had to be zero friction. We needed to lock funds to a social identity rather than a wallet address, and we needed that identity to be provable without putting it on-chain in plaintext.

The identity model

Every major social platform assigns users a permanent numeric ID. Discord's is stable across username changes. X's does not change when someone edits their handle. Telegram's is persistent for the life of the account.

We treat this ID as the identity anchor. When a MagicPay payment is sent, MoniBot resolves the recipient's platform user ID and hashes it:

bytes32 recipientId = keccak256(abi.encodePacked("discord:", userId));

This recipientId is what gets written to the chain. The social identity never appears in plaintext on the ledger. The hash is one-way: anyone can verify that a given user ID maps to a given recipientId, but the ID cannot be recovered from the hash alone.

The IOURegistry contract

Funds are held in our IOURegistry smart contract. The core storage looks like this:

struct IOU {
    address token;
    uint256 amount;
    address sender;
    uint40  expiry;
    bool    claimed;
}

mapping(bytes32 => IOU[]) public ious;

When a payment is sent, the contract records the recipientId, token, amount, sender, and a 180-day expiry timestamp. Nothing else. No name, no platform, no social handle.

When the recipient is ready to claim, they create a Monipay account, authenticate their social profile via OAuth, and our edge function verifies that the requesting wallet controls the social identity tied to the recipientId. The contract then calls batchClaim, which sweeps all pending IOUs for that identity in one transaction.

function batchClaim(bytes32 recipientId, address to) external onlyRelayer {
    IOU[] storage pending = ious[recipientId];
    for (uint i = 0; i < pending.length; i++) {
        if (!pending[i].claimed && block.timestamp < pending[i].expiry) {
            pending[i].claimed = true;
            IERC20(pending[i].token).transfer(to, pending[i].amount);
        }
    }
}

The onlyRelayer modifier means only our verified hot wallet can call this function, and that wallet only fires after the OAuth verification passes at the edge. Monipay cannot redirect funds to an arbitrary address. The contract does not expose that surface.

If the recipient never claims within 180 days, the sender can call refund() and the contract returns the funds. No admin intervention. No support ticket.

Gas abstraction

The claim is gasless for the recipient. We sponsor it through a relayer that calls batchClaim on their behalf after OAuth verification. The sender also pays no gas on Base, BSC, and Celo thanks to our EIP-712 gasless relayer, which processes signed permit messages rather than requiring the sender to hold native token.

The relayer architecture is a custom implementation. We evaluated ERC-4337 and decided against it. The added complexity of bundlers and paymasters was not worth it for our use case, where we control both the relayer and the contract and can enforce our own trust model at the edge rather than on-chain.

Multi-chain deployment

MagicPay launched simultaneously on Base, BSC, Celo, and Ink. The contract is identical across all four. The token differs per chain: USDT on Celo and BSC, USDT0 on Base and Ink.

The sender does not choose a chain. MoniBot checks the sender's configured chain and routes accordingly. The recipient claims on whatever chain the payment settled on. The claim screen shows the chain, token, amount, originating platform, and expiry date. On Ink, multiple payments to the same recipientId are batched into a single claimable entry.

Solana support is in progress. The identity model is the same but the program architecture is different since Solana does not have the EVM's mapping primitives.

The commands

The full sender experience on each platform is one natural language line.

On Discord:

!monibot bless @gogorama with $5

On X (Twitter):

@monibot send $10 to @alice

On Telegram:

@monipaybot tip $20 to @alice

MoniBot uses LLM inference to parse intent. There is no rigid command syntax. "Slide 10 bucks to jade" resolves identically to "send $10 to @jade". The parsed intent gets structured, validated, and passed to the on-chain execution layer.

On-chain deduplication is enforced via a nonce stored per payment. The tweet ID or message ID is included in the nonce derivation so the same social action cannot trigger two on-chain writes.

What we chose not to do

We did not build a custodial escrow. Monipay never holds funds in a company wallet. The IOURegistry contract holds everything. The code is public and verified on Basescan.

We did not build a wallet-creation flow for recipients until they are ready to claim their funds. The temptation was to generate a wallet on their behalf and hand them the key. We rejected this because key custody is a support burden we do not want and a security surface we do not need. The 180-day window is long enough for a curious recipient to make a deliberate choice about whether to claim.

We did not require the recipient to be on the same platform as the sender. The userrecipientId is platform-scoped, but the sender on Discord can pay someone whose only presence is on Telegram, as long as MoniBot can resolve their user ID on one of the three supported platforms.

What is coming next

The next feature built on top of this identity layer is subscription management for Discord and Telegram. An admin sets a fee, token, chain, and billing period. MoniBot registers subscriptions on-chain, assigns roles, sends DM warnings at seven days, three days, and twenty-four hours before expiry, and handles auto-removal after a configurable grace period. The contract enforces payment state so the admin does not have to.

The same recipientId model powers it. A subscriber's on-chain subscription record is tied to their platform identity, not their wallet address. They can rotate wallets without losing their subscription status.

If you want to dig into the full product writeup, the original announcement is on the Monipay blog. This post covers the technical decisions. That one covers the user-facing behaviour and chain-by-chain specifics.

You can add MoniBot to your Discord server here, mention @monibot on X, or start it on Telegram. The full MoniBot feature set lives at monipay.xyz/monibot.