AEX Standards

AEX ("æternity expansion") proposals are æternity's application-layer standards, the equivalent of Ethereum's ERCs. Superhero depends heavily on one of them, AEX-9, the fungible token standard, and touches a few others through its wallet stack.

AEX-9: fungible tokens

Every Superhero community token and the ProtocolDAO token is an AEX-9 contract. That is why a token you mint on Superhero shows up in any æternity wallet and on æScan (opens in a new tab) without Superhero having to integrate with them.

AEX-9 is inspired by ERC-20 but deliberately smaller: the base interface is the read functions plus transfer, and everything else (allowances, minting, burning, swapping) is an optional extension. A contract advertises which extensions it implements through aex9_extensions().

The interface

Non-stateful entrypoints can be dry-run for free; stateful ones need a signed transaction.

Reads

Entrypoint	Returns	Notes
`aex9_extensions()`	`list(string)`	Which optional extensions this contract implements
`meta_info()`	record	`name`, `symbol`, `decimals`
`total_supply()`	`int`	In token-decimals, not whole tokens
`owner()`	`address`	The minting authority
`balance(account)`	`option(int)`	An option, not an int; see below
`balances()`	map	Every holder at once
`allowance(accounts)`	`option(int)`	Keyed on a from/for pair
`allowance_for_caller(from)`	`option(int)`	Convenience for the common case
`allowances()`	map	Every allowance at once
`swapped()`	map of address to int	Migration bookkeeping

Writes (all stateful)

Entrypoint	Extension	Purpose
`transfer(to, value)`	base	Move your own tokens
`create_allowance(for, value)`	allowance	Authorise a spender
`change_allowance(for, delta)`	allowance	Adjust by a delta
`reset_allowance(for)`	allowance	Revoke
`transfer_allowance(from, to, value)`	allowance	Spend someone else's authorised balance
`mint(account, value)`	mintable	Owner only
`burn(value)`	burnable	Destroy your own
`swap()`	swappable	Migrate a legacy balance
`check_swap(account)`	swappable	Inspect a migration

init(name, decimals, symbol, initial_owner_balance) is the deploy-time constructor; initial_owner_balance is an option(int).

Coming from ERC-20

balance returns an option. An address that has never held the token returns None, not Some(0). Handle the empty case explicitly.
Allowances are three calls, not one. ERC-20's approve is split into create_allowance (for an allowance that does not exist yet), change_allowance (relative) and reset_allowance. There is no single idempotent setter, so check whether an allowance exists before you write one.
transfer_allowance is transferFrom. Same withdraw pattern, different name.
Extensions are declared, not assumed. Call aex9_extensions() before assuming mint or burn exists. A minimal AEX-9 token has neither. A Superhero community token returns four extensions; the DEX's WAE contract and every liquidity-pool token return ["allowances"] only, because their supply changes through deposit, withdraw, mint and burn paths that are not AEX-9 entrypoints.

Amounts are integers scaled by the token's own decimals from meta_info(), which is not necessarily 18. See AE & Gas.

What a Superhero community token implements

Every community token is created by the sale contract as a FungibleTokenFull, the "full" variant of the reference implementation (aeternity/aeternity-fungible-token v2.2.0), and the ProtocolDAO token the same way. aex9_extensions() on any of them returns:

["allowances", "mintable", "burnable", "swappable"]

Extension	Where Superhero depends on it
`mintable`	`buy` on the sale contract calls `mint(Call.caller, count)`
`burnable`	`sell` calls `burn(count)`
`allowances`	`sell` calls `transfer_allowance`; `DAOVote.vote` locks tokens the same way
`swappable`	Not used by Superhero; it comes with the reference variant

decimals is 18 for every community token: the factory's decimals() returns 18 and the sale contract's init requires decimals == bonding_curve.supported_decimals(), which is also 18.

Read AEX-9 balances without a contract call

The middleware indexes AEX-9 holdings, so a wallet view needs one paged request rather than one contract call per token:

GET  <MIDDLEWARE_URL>/v2/aex9/account-balances/ak_...?limit=100

Note the v2: the AEX-9 balance route is on middleware v2, while transaction lookups use v3. See Networks & Endpoints.

The other AEX standards

Standard	Subject	Status	Superhero's relationship to it
AEX-2	Wallet-to-æpp communication	Withdrawn, but still the js-sdk's reference implementation	Used: connecting a wallet runs the AEX-2 RPC flow (`walletDetector` over a `BrowserWindowMessageConnection`, then `connectToWallet`)
AEX-3	Encrypted secret storage (keystore JSON)	Active	Relevant if you import a keystore file
AEX-8	Message signing	Draft	Relevant to any off-chain signature, including the tipping contract's signed messages
AEX-9	Fungible tokens	Review	Used everywhere
AEX-10	BIP32 derivation path for deterministic wallets	Final	Applies to any mnemonic-based æternity wallet; see Accounts & Keys
AEX-130	æpp meta-information format	Draft	Not used
AEX-141	Non-fungible tokens	Review	Not used; Superhero has no NFT feature

AEX-9's status is Review and nothing supersedes it. Every æternity wallet, explorer and the middleware's AEX-9 indexing are built against it as written.

AEX-9 contract reference: the Superhero-side view of the same contract.
AEX-9 tokens in your wallet: what these balances look like to a user.
Sophia & FATE: how to read an ACI.
Token sale contract: what mints and burns these tokens.
AEX-9 specification (opens in a new tab): the normative standard.
Token standards overview (opens in a new tab): æternity's own summary.

Sophia & FATE Networks & Endpoints