Skip to content
LogoLogo

Register an account

Makechain V2 is address-native.

Accounts are address-native, and signer management is submitted directly to consensus.

Try it interactively

Set up an accountdemo

The generated Ed25519 key stays active in this browser and becomes the Makechain signer used by later write guides.

Next step
Create a project
→

What an account means in V2

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.

Basic setup flow

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

What SIGNER_ADD does

SIGNER_ADD is the first key-management step in V2.

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

There is no relay-era fallback. 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.

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

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

  1. connect the wallet or passkey that will own the account
  2. generate an Ed25519 keypair and authorize it with SIGNER_ADD
  3. rent storage on Tempo with rentStorage()
  4. wait for Makechain to show the relayer-backed claim with waitForStorageClaim()
  5. claim the canonical username with usernameCreate()

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

CLI shape

The exact Rust CLI migration is still in progress, but the normative V2 model is:

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

Use protocol/SPECIFICATION.md as the source of truth for field names and signing payloads.

Learn more

Next steps

Edit this page on GitHub