Addresses and planned names
Monolythium address payloads are 20 bytes and user-facing strings use typed bech32m HRPs. Use the exact released SDK helpers rather than reproducing derivation or checksum logic from prose.
Verified display types
Section titled “Verified display types”| HRP | SDK address type |
|---|---|
mono |
user |
monos |
smart account |
monoc |
contract |
monok |
cluster |
monom |
multisig |
monox |
system module |
An illustrative string is not a funding destination. Parse and validate the complete address, expected type, chain identity, and user intent before any future wallet action. See the continuously compiled address-helper examples.
Names are not an active contract
Section titled “Names are not an active contract”A hierarchical human-readable name registry remains a planned design. These docs do not certify namespaces, pricing, registration, renewal, transfer, reserve, reverse lookup, wallet resolution, or transaction-submission behavior against the active runtime.
Do not treat a *.mono string as an address, identity proof, agent grant, or payment destination. An SDK name-related constant, encoder, or read type does not establish node activation. A future wallet must show and revalidate the resolved typed address at the approval seam, but that is a design requirement rather than a currently supported flow.