Register an account

Makechain accounts are address-native — your owner_address is the 20-byte address of your wallet or passkey. Signer management goes directly to consensus.

Try it interactively

Set up an account
1
Connect a passkey or wallet
2
Generate Ed25519 keypair
3
Authorize your delegated key with SIGNER_ADD
4
Rent storage
5
Claim username

The SIGNER_ADD step is live: your passkey signs the AccountKeychain custody authorization and the SIGNER_REQUEST attribution, then the message is submitted to testnet. The generated Ed25519 key stays in this browser. Once authorized, it can sign ordinary Makechain messages in the later write guides.

Next step
Create a project
→

What an account means

Your account identity is your owner_address.

  • It is the 20-byte address of your wallet or passkey-derived account.
  • It is valid even before any state row exists.
  • Missing account state means default-zero bookkeeping.

Setup flow

In app clients, the registration sequence is lifted above the raw protocol messages:

  1. Connect the wallet or passkey that will be your owner_address.
  2. Generate an Ed25519 protocol keypair for fast message signing.
  3. Authorize that key with SIGNER_ADD.
  4. Rent storage on Tempo with rentStorage().
  5. Wait for the relayer-backed STORAGE_CLAIM with waitForStorageClaim().
  6. Claim your canonical username with USERNAME_CREATE (usernameCreate()).

This keeps STORAGE_CLAIM as the protocol primitive while avoiding direct claim submission in the normal user flow.

What SIGNER_ADD does

SIGNER_ADD is the first key-management step.

  • The message envelope is signed by an Ed25519 key for transport integrity.
  • Authorization comes from an AccountKeychain custody signature for owner_address.
  • The message also includes app attribution through request_owner_address and request_signature.

SIGNER_ADD and SIGNER_REMOVE are the only signer-management paths.

Account lifecycle notes

  • ACCOUNT_DATA writes profile fields such as display name, avatar, bio, and website.
  • VERIFICATION_ADD links external ETH or SOL identities to the same owner_address.
  • Storage expansion happens only through STORAGE_CLAIM settlement verification.
  • STORAGE_CLAIM funds raw storage only. Claim the canonical username separately with USERNAME_CREATE, and replace it later with USERNAME_UPDATE.

The first successful STORAGE_CLAIM is settlement-verified and does not require delegated-key authorization. Delegated-key scope SIGNING is required for username messages and other ordinary user messages.

CLI shape

The Rust CLI migration is in progress. The normative model is:

  1. generate an Ed25519 keypair
  2. sign the native AccountKeychain SIGNER_ADD digest with the custody wallet
  3. submit the signed Makechain message
  4. rent storage and claim the username

Use these protocol docs for field names and signing payloads. The canonical protocol reference is protocol/SPECIFICATION.md.

Learn more

Next steps