Token Utility
What $XNY does in the protocol today — it is a BNB Smart Chain token, the protocol runs on Base, and no contract requires it.
This page describes what the deployed contracts do with $XNY today, and
today is the only thing it is good for. The position here is not a
commitment: a bridge, a second deployment or a contract that charges would
each change it, and none of them would announce itself on this page first.
Check the date on anything you rely on, and read
Future Directions
for what is intended rather than built.
The short answer
$XNY is a BEP-20 token on BNB Smart Chain. The XnY Protocol contracts run on Base. No protocol contract requires $XNY, charges it, or grants anything in exchange for holding it.
For the token itself — supply, the live contract address, the lock — see Token Info. For how the supply is divided, see Tokenomics, which describes allocation intent rather than deployed mechanism.
Why the two are on different chains
The token launched on BNB Smart Chain and the protocol was built on Base. Token Info lists Base and Ethereum as "Coming soon" with no contract address, which is the accurate position: there is no $XNY on Base, so no Base contract could require it even if one were written to.
This is the fact everything below follows from. A utility spanning the two would need a bridged token or a protocol deployment on BNB Smart Chain, and neither exists.
What the contracts do with tokens
Only two places in the protocol contracts move a currency: a royalty distribution, and a DID-bound account spending what it holds. Registering an identity, creating a frontier, campaign or task, anchoring a fingerprint, assembling a dataset version, claiming shares and anchoring a grant move no tokens at all. Ownership shares are themselves transferable — that moves value, in the sense that it moves a claim on future royalty — but it moves no currency and costs nothing to do. Creating frontiers, campaigns and tasks is authorised by an issuer allowlist or by the owner of the DID being named — not by a payment.
Royalty distribution does not hardcode $XNY. RoyaltyEngine.distribute takes a token address, with the zero address denoting native ETH. The current implementation requires explicit owner admission for every deposit currency, including ETH; earlier deployments lacked that gate. Check the deployed version and allowlist before paying. Each admitted currency is accounted separately, and the platform fee is charged in that currency. See Royalty Engine for the deployment and accounting limitations.
Standard is doing work in that sentence: the engine credits the amount the caller declares, so a token that delivers less than it says — one taking a fee on transfer, or rebasing — would leave the ledger claiming more than the contract holds. Claiming is also open to any caller while the payee is derived from a DID rather than from whoever holds the share, so who can collect is a narrower question than who is owed — a share transferred to an address with no DID behind it accrues revenue nobody can withdraw. Both belong to Royalty Engine; they are noted here only so "any ERC-20" is not read as a support guarantee.
Anchoring a contribution fingerprint costs no $XNY. The registry carries a configurable fee token and fee amount, and a fee token is recorded for both deployed networks — but neither is the $XNY contract, no code path transfers the fee, and the amount is an owner-set value that the deploy scripts default to zero. Submitting a fingerprint costs the Base transaction fee and nothing else.
Transaction fees on Base are paid in ETH, as on any EVM chain. $XNY is not gas for anything.
Ownership is an ERC-1155 balance, not a purchase. Shares in a dataset version are claimed by the contributors whose work went into it, against a commitment fixed at assembly — see Tokenized Ownership Proofs.
What is not there
| Utility | Status in the deployed protocol |
|---|---|
| Staking, and slashing of stake | No staking mechanism of any kind |
| Task launch deposits | Campaigns and tasks are on-chain records created without payment |
| Paid promotion or priority routing | No such path |
| Purchasable data or API access tiers | The public API has one fixed per-caller rate limit, the same for everyone. It cannot be raised by paying, in $XNY or anything else, and there are no tiers |
| Governance voting weighted by stake | No on-chain governance. No contract holds a proposal, counts a vote, or reads a stake weight; the parameters an owner can change are changed by the owner |
| Compliance or privacy-proof fees | No fee of any kind is collected in $XNY |
Access to a dataset is granted by an on-chain grant naming a consumer, not bought — see Access Control.
Where the intended utilities live
$XNY utilities are on the plan, and this site documents the protocol. Future Directions states them as intentions without a schedule, which is where they belong.
It separates them by what each would first require, because that is not the same obstacle in each case. Deposits, metered access, and marketplace listing and settlement need a contract that charges, meters or settles — and then the token on that contract's chain. Gas needs a chain whose native token is $XNY, and no bridge produces one.
Last updated