Trust & transparency

X1ID handles hold identity and route payments, so trust matters. Everything below is built in, and the final section gives you the on-chain address to check it all yourself.

Your handle is permanently yours

Once you register a handle the standard way — the default — it's yours: there's no renewal to miss and no expiry that could quietly transfer it to someone else. A name people send money to must never change owners through inaction, so ownership doesn't lapse. It only moves when you choose to transfer or sell it.

X1ID also offers an optional lease-to-own path (pay a fraction up front, build equity toward the same permanent price over time) for whoever would rather spread the cost out. It keeps the same anti-inaction protection at its core: a 30-day grace period after a missed payment, so a leased handle can't be silently swooped in on the moment a payment is late — see the FAQ.

Built to resist impersonation

Handles use letters, numbers, and simple characters only — no emoji and no lookalike letters borrowed from other alphabets.

This closes a real trap. In many systems, an attacker can register a name that looks identical to yours using a lookalike character from another alphabet — for example a Cyrillic "а" in place of a Latin "a" in @alice. To the eye they're the same; to a computer they're different names. By allowing only one, plain character set, X1ID removes that whole class of attack instead of trying to spot it after the fact.

Verified vs. unverified records

Anyone can type an address into a name. X1ID lets you prove you control your addresses, and it shows the result honestly: a proven address appears as verified, and an unproven one is shown as unverified. Nothing unproven is ever dressed up as trusted, so people know what they're relying on before they send.

Recovery, if you lose access

For a name-only handle (lease-to-own or a plain un-minted registration), set up recovery in advance so that a lost or inaccessible wallet doesn't mean a lost handle. Once a handle is tokenized (the default for a standard registration), control is whoever holds the NFT, so on-chain recovery no longer applies — keep the holder wallet in a hardware wallet or multisig instead. Either way, a Lock is the emergency brake if you fear your key is compromised. See What you can do.

You can audit it yourself

X1ID runs as a public on-chain program. You don't have to take our word for anything — you can inspect it directly on the FortiBlox explorer.

Registry program address

8JgnNWi24bq9uzfnT9XmkWxvaWMVgoEs9bu8QsHhLe1P

This program is deployed on X1 mainnet (RPC https://rpc.mainnet.x1.xyz). You don't have to trust that the deployed binary is what we say it is — dump it from the chain and hash it yourself:

terminal

solana program dump 8JgnNWi24bq9uzfnT9XmkWxvaWMVgoEs9bu8QsHhLe1P x1id.so \
  --url https://rpc.mainnet.x1.xyz
# 1. the whole file, exactly as dumped (no trimming)
sha256sum x1id.so
# → 155c4f8e91e6ad5032f03310dc6c8fecf78936438790ad7c3c30270ccbccc69a  (1,709,040 bytes)
# 2. the program ELF only: the first 1,704,560 bytes
head -c 1704560 x1id.so | sha256sum
# → bfc230cdbfaf4910ab78c9d4f83408b69d100a621fe3e37956a692bd358e91ca
# 3. confirm the rest is zero padding
tail -c +1704561 x1id.so | tr -d '\0' | wc -c
# → 0

solana program dump writes the ProgramData account's bytes after its 45-byte header (the slot and upgrade authority), so the first hash is sha256(programdata[45..]), all 1,709,040 bytes. The account is larger than the program it currently holds: the ELF is 1,704,560 bytes and the remaining 4,480 bytes are zeros. The second hash covers only the ELF, and it matches the canonical build of source commit 5fb1e772, so it's the one to compare against a binary you build yourself. The third command proves nothing else is hiding in the padding.

These values are as of the upgrade executed by the treasury multisig at slot 85461348 on 2026-10-12 (transaction). They change with each program upgrade: solana program show prints the "Last Deployed In Slot", and if that is later than slot 85461348 the program has been upgraded since this page was written and different hashes are expected.

A few more facts you can check on-chain rather than take on faith:

Treasury — the program's Config.treasury is immutable (there is no instruction that can change it) and is set to E2cELMtby3YYYbDdxamuGKWCyte3kwLywv19pEk2iUq6, a 2-of-5 multisig PDA. No single key can move registration proceeds.
Upgrade authority — the program's upgrade authority is the same 2-of-5 treasury multisig (E2cELMtby3YYYbDdxamuGKWCyte3kwLywv19pEk2iUq6), so an upgrade needs two of five guardian approvals; no single key can change the program. The program remains upgradeable, and burning the upgrade authority is an option for later rather than a scheduled step. solana program show reports the current authority at any time, so you never have to take our word for its status.

For developers

If you're building an app and want to resolve @handles to addresses, there's a public package, @x1id/resolve, on npm. Start at app.x1id.io.