Token Standards

Every token you deploy through the engine follows a familiar Ethereum standard with one addition: a gasless meta-transaction path. The owner signs an action in their own wallet, the XKOVA Relayer submits it and pays gas, and the chain settles. That is what the X suffix marks.

The three standards

The engine supports the three common token shapes. Pick the one that matches what you are issuing.

Standard	Shape	Typical use
`ERC20X`	Fungible. One supply, divisible into units.	A stablecoin, a points balance, a fungible share class.
`ERC721X`	Non-fungible (NFT). Each token id is unique.	A one of one asset, a deed, a unique instrument.
`ERC1155X`	Multi-token. Many ids in one contract, each with its own supply.	A fund with several share classes, a fractional asset, batched instruments.

What the X suffix means

The X variant is the XKOVA gasless meta-transaction model. A standard ERC-20 or ERC-721 requires the caller to hold native gas and sign and broadcast its own transaction. The X variant instead accepts a signed instruction relayed by a trusted forwarder (the ERC-2771 pattern). The owner never needs native gas and never broadcasts a transaction directly.

The owner authorizes an action by signing typed data in their own wallet. The private key never leaves the owner.
The XKOVA Relayer submits the signed instruction on chain and pays the gas.
The contract recovers the original signer and acts on their behalf.

This is the same non-custodial pattern the rails use. See the Non-custodial Model for the mechanics that apply across both pillars.

The X variant is interface-compatible with the base standard. A wallet, explorer, or marketplace that reads ERC-20, ERC-721, or ERC-1155 sees an ordinary token. The gasless path is additive, not a different interface.

Owner controls are part of the contract

An X token is programmable. Access lists, named roles, and a global pause are built into the contract, not bolted on off chain. The contract's admin authority is a multisig Safe you provide, so high impact actions (minting, pausing, granting roles) require the Safe's signer quorum. Those controls are covered on Access and Policy.

Where each standard fits

Deploy and Mint walks the lifecycle: deploy a token, then mint, burn, and manage supply.
Real-World Assets adds a configurable metadata plane on top of ERC721X and ERC1155X for assets that carry rich, structured data.
Cap Tables and Distributions reconstructs holders and positions and pays them pro rata.

For the deploy request shapes and every token operation, see the interactive reference or the operations list under the tokenization tag.

Was this helpful?