SuperheroID

SuperheroID is Superhero's identity layer: an æternity address with a set of independently signed, independently revocable links attached to it. The links live in the AddressLink contract. You authorise every link with your wallet signature, and only you can remove one.

What it links

Link	Provider id	On-chain call	Proof required
X handle	`x`	`link`	An OAuth session the backend observes, sealed into a 5-minute HMAC token
Nostr key	`nostr`	`link`	A kind-22242 event signed by the npub, under 5 minutes old
Preferred `.chain` name	`prefaens`	`link_principal`	AENS ownership, checked on chain with `AENSv2.lookup`
Bio	`bio`	`link`	Ownership of the address only
Website	`site`	`link`	Ownership of the address only

Every link also needs your æternity signature over the claim message; the proof column is what the provider checks on top of that. Each link is removed by its own unlink, which needs nothing but your signature.

The transaction itself is submitted and paid for by Superhero's provider wallet, which is the only account permitted to write the x, nostr, bio, site and prefaens namespaces. See AddressLink for the provider-ownership model.

What is on chain and what is not

Data	Authority
Every provider link, its value, and the per-address nonce	`AddressLink` contract state
The reverse index: which address owns a given provider value	`AddressLink` contract state
Which account may write a provider namespace	`AddressLink` `providers` map
AENS name registration, pointers, expiry	æternity AENS; the `prefaens` link references it but does not own it
Posts, comments, tip totals	`Tipping` v3 plus the API index
Avatar, fullname, legacy username, follow counts, leaderboard stats	Superhero API
Chain name shown on a profile	Resolved hourly from the middleware, not from a contract link

Reading an identity

GET /api/profile/{address} returns the merged aggregate: address, a profile object (fullname, bio, site, avatarurl, username, prefered_aens_name, x_username, chain_name, chain_expires_at, plus follow counts when the social-graph feature is on) and a resolved public_name. Profiles are served entirely from indexed data; the includeOnChain query flag is deprecated.

public_name is the first non-empty value of:

prefered_aens_name   (links.prefaens — the AENS name you explicitly linked)
chain_name           (from the middleware, refreshed hourly)
username             (the legacy profile field)
address              (the ak_… itself)

GET /api/accounts/{address} returns the raw side of the same data, including a links object keyed by provider id. That is the authoritative view; the client reads it first and treats the flat profile fields as fallbacks for older records.

How a third party verifies a link

In order of how much can be checked independently:

Preferred .chain name. link_principal calls AENSv2.lookup inside the contract and aborts with PRINCIPAL_MISMATCH if the signer does not own the name. You can independently resolve the name through AENS on any node and compare its account_pubkey pointer. Both checks are protocol state.
Nostr key. The backend verifies a Schnorr signature from the npub over the exact claim message before submitting, but only the æternity signature is recorded on chain. A reader of the chain sees the address's consent to an npub string.
X handle. The chain records that the address consented to a handle string and that the provider owner submitted it. The OAuth evidence lives only inside the backend. See Verifying Your X Account.
Bio and website. Nothing to verify beyond ownership of the address.
Posts. Independent of the identity layer. A post's sender is whichever address signed the transaction, recorded by the Tipping contract.

The verified badge on a profile means an x link exists for that account.

Where you manage it

Open your own profile at https://superhero.com/users/ plus your address and choose Edit SuperheroID. The editor covers the .chain name selection and preferred-name link, the bio, the website and the X connection. Each change is a separate claim-sign-submit round trip, and the editor reloads its state after each one.

Fullname, avatar and the legacy username are read-only.

AddressLink: the contract, its entrypoints and its provider-ownership model.
Names: the name types and how a public name is resolved.
Verifying Your X Account: the x provider's flow in full.
Profiles & Accounts: where each linked value appears on screen.
Identity and DIDs: how the model maps onto W3C DID Core.

Overview AddressLink