ArcaniumPaying an X account
A launch can send its creator fees to an X account instead of a wallet. The fees accumulate at a fixed address on Arc and wait there until whoever controls that account proves it and withdraws them.
Why this needs a mechanism at all
An X handle is not an address. Fees have to go somewhere the moment a token launches, which may be long before anyone knows which wallet the account's owner uses — or before its owner knows the token exists.
So each X account gets a vault: a contract address derived from its identity, computable before the contract is deployed. A launch names that address as its fee recipient, USDC accrues there like it would in any wallet, and the vault itself is only deployed when somebody first claims.
The handle addresses the vault, the first claim owns it
A vault is derived from the handle, lowercased. That is what makes it nameable at launch: the address can be computed from a string somebody types, before the account's owner has ever visited this site or knows the token exists.
Handles change hands, though, and a fee stream that followed the name would quietly follow it to a stranger. So the first X account to claim a vault is recorded against it, and every later claim must come from that same account. Rename yourself afterwards and the fees still reach you; someone who registers your old handle gets nothing.
The gap this leaves. If a handle is abandoned before its owner has ever claimed, whoever registers it next can claim first and keep it. Nothing on our side can tell those two people apart — that is the honest cost of not requiring X's paid API tier. If a launch has routed fees to your account, claim once, early. After that the handle is yours regardless of what happens to the name.
Claiming
- Connect the Arc wallet you want paid.
- Verify with X. This is a standard OAuth sign-in with PKCE.
- Arcanium's signer produces a short-lived, single-use authorisation naming your X identity, the vault, the asset, your wallet, a nonce and an expiry.
- You submit it. The vault checks the signature and pays out.
You can claim repeatedly as fees accrue, and to a different wallet each time — verify again and name the new one. Changing wallets does not require anything to be migrated.
What you are trusting
This is not trustless, and it cannot be. No blockchain can check who controls an X account. The vault verifies a signature from a signer Arcanium operates, and that signer decides which wallet a given X identity maps to. A dishonest or compromised signer could authorise a wallet it controls.
What the design does guarantee:
- The signer cannot move funds alone. A claim must be sent by the wallet named in the authorisation, so a leaked signature cannot be redirected to someone else.
- Every payout emits an event naming the identity and the recipient. Misuse would be visible on chain rather than silent.
- An authorisation is single-use, expires quickly, and is valid only for one vault on one chain. It cannot be replayed anywhere else.
- The signer is read from the factory at claim time, so a compromised key can be rotated without redeploying vaults or moving anyone's funds.
- A handle already claimed by one X account cannot be claimed by another, whatever happens to the name afterwards.
- Arcanium never holds the money. It sits in the vault contract until claimed.
Not the same as the token's X link
The X account under a token's social links is a label. This is the fee recipient. They are set separately and can be different accounts.
Contracts
- Vault factory
0xae74c38757558C63BD1489056e436dc06F74DFd6 - Vault implementation
0x416F3dc785e0B6715e1629630c6F99f57de1FAb6 - Attestation signer
0x74E6853252D79608054c71bb6c90BF1D381932E5
vaultFor(keccak256(handle)) returns the address for any handle, deployed or not — lowercased, because X treats @Alice and @alice as one account and two vaults would split its fees.