What X Vaults does, and what it does not do.

A vault is a small contract on Robinhood Chain that holds whatever creator fees have been collected for one X account. It has three fixed facts baked in at creation and never changed: the account's numeric X id, the factory that deployed it, and the address of the Pons locker it collects from.

It has no owner. There is no admin function, no upgrade path, no rescue call. The contract exposes exactly two things that change state: collect(token), which anyone may call, and claim(c, sig), which moves funds to a payout address and only works with a voucher signed for that vault's id. Everything else is a view.

The vault address is computed before the vault exists. The factory uses CREATE2 with a salt of keccak256("x", xId), so vaultFor(xId) returns the same address before and after deployment. In this sense every X account already has a vault: an address that is final, holds nothing, and is waiting for the first token to be routed to it. The first route deploys it; the call is permissionless.

An X handle is a label. It can be renamed by its owner, abandoned, and later registered by somebody else. The numeric id behind it is assigned once and never reused. If a vault were bound to a handle, a rename would move somebody's money to a stranger. So the contract is told the id, and only the id.

We resolve handles to ids with the X API (GET /2/users/by/username) and cache the pair. The cache is a convenience for the explorer and the deploy form. It is not part of the trust path: the contract does not know handles exist, and a wrong cache entry cannot move funds, because a claim requires the signed-in account's id to match the vault's immutable id.

A consequence: if you rename your account, your vault does not move. If you delete your account, the vault remains at its address, and there is no longer any way to prove control of that id. Funds inside would be unreachable. The contract cannot help with this, and neither can we.

There are two ways to dedicate a Pons token to an account.

Launch. The deploy form calls the Pons v2 factory with creatorFeeRecipient set to the vault address inside the launch transaction. The token is dedicated from the block it is created in. There is no second signature and no window where the token exists with fees pointing at the deployer.

Route. An existing Pons v2 token can have its fee recipient set to the vault. Only the token's deployer can do this, from the wallet that deployed it. Before showing the button, we read the current recipient from the live Pons locker, not from our database. If it already points at the vault, the form says so and does nothing.

Routing is one-way. On Pons v2 the redirect follows the recipient, so once fees point at a vault they stay there. The vault cannot pass them on, and nobody, the deployer included, can point them anywhere else afterwards. Read that sentence twice before you sign.

At the time of writing, launches are switched off in the UI until the Pons v2 factory interface has been pinned against verified source. The review step is exact; the transaction is not yet wired.

Trading fees do not arrive at the vault by themselves. They accrue inside the Pons launch locker at 0x10F2756e373bAb14999fdC9177587D51D30a1Cf5, credited to the fee recipient. Somebody has to pull them.

collect(token) on the vault does that. It calls the locker's collectFees(token) for the vault itself, and whatever the locker releases lands in the vault. The call is open to anyone because the money can only move to the vault: there is no argument that names a destination. A bot, the deployer, the owner or a stranger can trigger it, and the outcome is the same.

Collection pulls ERC-20 only: the launch token and the quote asset, WETH or USDG. The vault also accepts native ETH pushed to it directly, and a claim sweeps native along with the listed tokens.

One trust line to keep in view: fees still inside the Pons locker are under Pons' control until collected; the locker is upgradeable by Pons. Once collected they are in the vault, which is not. If that matters to you, collect early and often. It costs gas and nothing else.

Claiming is the only way funds leave a vault. It takes a voucher and a signature. The voucher is an EIP-712 struct:

Claim {
  uint64    xId;      // must equal the vault's immutable id
  address   vault;    // must equal address(this)
  address   payout;   // where everything goes; cannot be zero
  address[] tokens;   // ERC-20s to sweep; native ETH is always included
  uint256   nonce;    // single use, tracked in a bitmap
  uint256   expiry;   // unix seconds; 30 minutes from issue
}
domain: { name: "XVaults", version: "1", chainId: 4663, verifyingContract: vault }

The flow: you sign in with X using OAuth 2.0 PKCE, which proves to our server that you control the account with a given id. You name a payout address. Our claim signer signs a voucher for that id, that vault, that payout. Your wallet sends claim(voucher, sig) to the vault and pays the gas. The contract checks the vault matches, the id matches, the voucher has not expired, the nonce is unused, and the signature recovers to factory.claimSigner(). Then it sends the full native balance and the full balance of each listed token to the payout, and marks the nonce spent.

Things the contract does not check, because they do not matter to it: whether the payout wallet has ever touched the token, the chain or the deployer; whether you have claimed before; how long the funds sat there. There is no lockup, no window and no service fee.

Things we cannot do: move funds to an address you did not name. The voucher is bound to the payout, and the only key we hold signs vouchers. It cannot call claim for you, and it cannot change the payout after the fact. If our signer key were stolen, the thief could issue vouchers for any id, but only after choosing a payout that the on-chain event would record. The factory owner can rotate the signer in two steps. That is the entire blast radius, and it is not zero.

The deployer of a Pons token is the wallet that created it. Here is the full list of what that wallet can do to a vault dedicated to somebody else's account.

• Point the token's fees at the vault, once. After that the recipient cannot be changed by anyone.
• Call collect, like anybody else.
• Deploy the vault contract by being the first to route to it, like anybody else.

And what it cannot do:

• Withdraw anything. There is no function for that without a voucher for the vault's id.
• Redirect fees away from the vault after routing. Routing is one-way.
• Change the vault's id, factory or locker. They are immutable.
• Speak for the account. No ownership proof is asked for at launch, and none is granted by it.

The deployer's incentive is the attention that comes from dedicating a token to an account, and whatever they do with the token supply. The fees are not theirs. That is the whole point.

Three contracts and one key are involved. Addresses are on the Check it yourself block and repeated here.

• XVaultFactory 0x0000000000000000000000000000000000000000. Deploys vaults with CREATE2, exposes vaultFor and ensureVault, and holds the claimSigner address. Owned, with a two-step ownership transfer. The owner's only powers are rotating the signer and handing over ownership. The owner cannot touch any vault.
• XVault, one per id. No owner, no imports on the money path, no upgrade.
• PonsLaunchLocker 0x10F2756e373bAb14999fdC9177587D51D30a1Cf5. Pons' contract, not ours. Holds fees before collection. Upgradeable by Pons.
• Claim signer 0x0000000000000000000000000000000000000000. A hot key on the server that signs vouchers. Rotatable by the factory owner.

Our web server holds: the signer key, the X API credentials, and a database of handle-to-id pairs, routes and issued vouchers. It does not hold any user keys and never can. If the server disappears tomorrow, funds already in vaults remain in vaults; what is lost is the ability to issue new vouchers until somebody with the factory owner key sets a new signer.

Nothing here promises a return. Creator fees are a fraction of trading volume on a token somebody else launched. Most tokens trade for a few days and then do not. A vault with a balance of zero is the expected case, not an error.

• Not audited. The contracts are short and tested, and the source will be verified on Blockscout before any token is launched. That is not an audit. Read the code or treat it as unreviewed.
• Signer compromise. Discussed above. A stolen signer key can issue vouchers for any id until rotated.
• Pons locker risk. Fees not yet collected are inside a contract we do not control and which can be upgraded.
• X account risk. Lose the account, lose the vault. A suspension does not delete the id, but it may block OAuth for as long as it lasts.
• Address confusion. The explorer shows addresses derived from ids. Do not send funds to a vault manually expecting anything but the id's owner to be able to take them out.
• Chain risk. Robinhood Chain is new. Its sequencer, bridge and explorer are outside anything described here.

If any statement on this page turns out to be false, the correct response is to stop using the site and say so publicly. We would rather be corrected than trusted.