Skip to content
Astrolune

Wallets

How keys, addresses and signatures work on Astrolune — and what exists to hold them today.

Coming soon

The core compiles a deterministic development backend for signatures, VRF and VDF. The verified half of a signature is a hash of the public key and the message, so anyone can produce one for any key. `al_crypto_is_secure()` returns false, and that is the correct value.

Address format

An address is 32 bytes derived from a public key under a dedicated domain tag, so an address digest can never collide with any other structural hash in the protocol.

LENGTH

32 bytes

DERIVATION

SHA-256 · AL_TAG_ADDRESS

ENCODING

al1 + 40 hex

CHECKSUM

Address inspector

Decodes locally in your browser. Nothing is sent anywhere — there is no endpoint to send it to yet.

  • ENCODING: al1…
  • LENGTH: 43
  • CHECKSUM: [0-9a-f]

Wallet software

Nothing on this list is production software. The signature backend it would sign with is a stub.

Not started

alc — reference CLI

Key generation, address derivation, transaction construction and signing from the terminal.

Planned

Encrypted keystore

A file format for keys at rest, derived with HKDF over the existing hash layer.

Planned

Browser extension

Account management and transaction approval for dApps, once an RPC surface exists to talk to.

Planned

Mobile wallet

Balances, transfers and name resolution on a phone.

Deferred

Hardware signing

Blocked on the real signature scheme — a device cannot implement a stub.

Insecure stub

Before you generate a key

The core compiles a deterministic development backend for signatures, VRF and VDF. The verified half of a signature is a hash of the public key and the message, so anyone can produce one for any key. `al_crypto_is_secure()` returns false, and that is the correct value.