Stellar Assets & AMM
Stellar has no equivalent of the ERC-20 token contracts or the deployed Uniswap V2 contracts documented elsewhere in this Reference section — there is no deployed bytecode on Stellar at all. Assets are issued by an account via ordinary payment operations, and liquidity pools are a protocol-level primitive (CAP-38), not a contract. This page is the Stellar-side equivalent of those two pages: what actually backs a Stellar asset here, since there's no address to look up on a block explorer's "contract" tab.
How an asset "exists" on Stellar
There's no deploy step. Any Stellar account can issue a credit asset — a (code, issuer) pair — simply by paying it to another account; that account must first establish a trustline (ChangeTrust) to receive it. Comet Engine's AssetConfig.Contract field is repurposed to carry this pair as a single string: "<issuer address>:<asset code>", in place of the EVM contract address that field normally holds.
The relayer is the issuer (phase 1)
Comet Engine's Stellar relayer account — configured via STELLAR_RELAYER_SEED (see Configuration →) — doubles as the issuer for every asset it mints through this engine. The engine holds every key it signs with, so one relayer keypair issuing what it also funds is the natural starting point, the same way an EVM relayer key must already hold minter rights on the ERC-20 contract it mints through.
| Testnet Relayer Address | Role |
|---|---|
GCWA2L4KX52SYNIAO4BAX4FPAX62F3FHPIFAVJXERVRNBFNUW2KP36XN | Funds every new Stellar wallet on creation; issuer for every relayer-issued asset below |
This means one specific limitation
MintAsset explicitly checks that the relayer's own address matches the asset's issuer, and refuses otherwise: "asset %s's issuer %s is not this engine's relayer %s (phase 1 only mints assets the relayer itself issues)". A third party's Stellar asset can be registered and traded through this engine (see the Stellar AMM's PTEST example below), but the engine can never mint it — only its actual issuer can.
Example registered assets (testnet)
Registered at runtime via POST /admin/assets/:symbol/register?chain=stellar — there's no env-var-based registry file to point to, since these live in the same dynamic asset registry every chain uses.
| Symbol | Contract (issuer:code) | Decimals | Mintable via this engine? |
|---|---|---|---|
CTEST | GCWA2L4KX52SYNIAO4BAX4FPAX62F3FHPIFAVJXERVRNBFNUW2KP36XN:CTEST | 7 | Yes — relayer is the issuer |
PTEST | GBUQZ7LZC7F42FFGR7JFKVV4WTAK7IKSSUQMGMUFYLPVIDCYAZYJB4Z2:PTEST | 7 | No — issued by a separate testnet account, used to seed the Stellar AMM pool example since the relayer can't hold a trustline to an asset it issues itself |
Liquidity pools: CAP-38, not a factory contract
Where Celo's AMM is a deployed UniswapV2Factory/Router pair you can look up on an explorer, a Stellar pool is a network-level object: its ID is deterministically derived from the ordered pair of assets it holds (txnbuild.NewLiquidityPoolId), and it comes into existence the moment the first deposit lands — there's no separate "create pool" transaction type on Stellar itself (this engine's POST /admin/stellar/pools/create step is purely about opting the relayer into the pool-share trustline first).
| Example Pool | Pool ID | Fee |
|---|---|---|
| PTEST / native (XLM) | d4b757960775b71542a966f674c84c3ddabae7fa9089803bcb6514f06246d6b0 | 0.3% (30 bps) |
Full endpoint reference: Stellar AMM API →.
Verifying any of this yourself
Every address and transaction on this page is real testnet state — check it directly:
- Relayer/issuer account:
https://stellar.expert/explorer/testnet/account/GCWA2L4KX52SYNIAO4BAX4FPAX62F3FHPIFAVJXERVRNBFNUW2KP36XN - Any transaction hash referenced across this docs site:
https://stellar.expert/explorer/testnet/tx/<hash> - Raw Horizon API (no explorer UI):
https://horizon-testnet.stellar.org/accounts/<address>