IDENTITY LAYER

Accounts & Identity

Shamwari recognises that real-world financial systems are populated by legally distinct actors. Ten account types, from licensed banks to autonomous AI agents, each with protocol-enforced permissions secured by NIST post-quantum cryptography. No anonymous addresses. Every participant is typed, accountable, and verifiable.

10 ACCOUNT TYPESAI AGENT TYPEDILITHIUM + KYBERON-CHAIN DOMAINSENCRYPTED IDENTITYPQC FROM GENESIS
11
Typed account categories
2
PQC algorithms: ML-DSA Dilithium + ML-KEM Kyber
1
Seed phrase derives both signing and encryption keys
SHAMWARI-XXXX-XXXX-XXXX-XXXXX
REED-SOLOMON format human friendly account addresses
01
ACCOUNT TYPE SYSTEM
Eleven account types. One platform.

Every Shamwari account has a declared type that determines its transactional capabilities at the consensus layer. Account type restrictions are enforced at gate 4 of the 7-gate transaction validation pipeline before any balance changes occur. No application-layer override is possible.

BANK
AccountType.BANK
Licensed commercial banks. Full monetary system access, CBDC issuance participation, elevated KYC requirements, and eligibility for central bank authority designation. Required to receive certain institutional payment types.
CURRENCY_ISSUANCEAll payment typesLending originationReserve management
FSP
AccountType.FSP
Financial Service Providers. Payment processing, currency exchange, Binder node participation, and cross-border settlement capabilities. Regulated access to the monetary system without full banking privileges.
Payment processingFX exchangeBinder eligibleSettlement services
MFI
AccountType.MFI
Micro-Finance Institutions. Loan origination and management, savings product administration, agricultural finance product access, and crowd-funded lending pool participation for underserved communities.
Loan originationSavings productsMFI lending poolsAgri-finance
MERCHANT
AccountType.MERCHANT
Registered merchants. Required to receive merchant-specific transactions that include sales, rewards distributions, commercial payment acceptance, and loyalty programmes and delivery management.
LIST_PRODUCTSTORE_PURCHASE receiptReward distributionMerchant ratings
BUSINESS
AccountType.BUSINESS
General businesses. Commerce, subscriptions, and asset trading with standard commercial capabilities across all product types. The default commercial participant type for organizations.
CommerceSubscriptionsAsset tradingStandard payments
SAVINGS
AccountType.SAVINGS
Savings account holders with KYC. Offers access to currency savings, vault, loans, insurance services. Also allow the receipt of payments like salaries and wages.
CBDC accessSavings goalsTime-locked vaultsLoan eligibility
PERSONAL
AccountType.PERSONAL
Individual nonconsumers. Limited to non-regulated usage of the platform.
VotingCertificatesDomainsSubscriptions
DEVELOPER
AccountType.DEVELOPER
Application developers. ContractLibrary upload, App Store registration, certificate issuance, and contract reference management. Required for publishing smart contracts and distributing applications through the protocol.
App Store listingCertificate issuanceContractLibraryEarly Access
AUTONOMOUS WORLD FIRST
AccountType.AUTONOMOUS
Autonomous AI agents. AutonomousAccountControl rule engine enforces transaction-type whitelists, per-holding spending caps, rolling window limits, recipient whitelists, and minimum balance floors at the consensus layer. Hard limits that no agent can exceed.
Tx type whitelistSpending capsRolling windowsRecipient listsBalance floors
NONE
AccountType.NONE
Default unclassified accounts. Standard transactional capabilities without special regulatory treatment or institutional privileges. The default state for all accounts before explicit type declaration via SET_ACCOUNT_INFO.
Standard transactionsBasic capabilitiesNo special roles
02
PQC KEYPAIR ARCHITECTURE
Two keys. One seed. Complete security.

Every Shamwari account is secured by two NIST-standardised post-quantum keys: a Dilithium signing key and a Kyber encryption key, both derived from a single BIP39-adapted seed phrase. This is the first blockchain wallet architecture to deploy both NIST FIPS 203 and FIPS 204 as the primary (and only) cryptographic layer.

ML-DSA Dilithium: Signing Key (NIST FIPS 204)

Every transaction submitted by the account is signed with this key. The 2420-byte Dilithium signature is included in the transaction body and verified by every network node at gate 1 of the consensus pipeline. This is also the key used by forger nodes for generating block signatures.

  • NIST standardised: FIPS 204 (finalised 2024)
  • Lattice-based: secure against Shor’s algorithm at any key size
  • 2420-byte signatures: deterministic, constant-time
  • 1312-byte public key: stored on-chain in account table
  • 0.1ms verification time: no performance impact at block production rates
  • Used for transaction signing, block signatures, and certificate issuance

ML-KEM Kyber: Encryption Key (NIST FIPS 203)

The account’s Kyber public key is stored on-chain and used by other accounts and the protocol to encrypt data destined for this account. Only the account holder with the corresponding Kyber private key can decrypt it. Used for all sensitive on-chain data.

  • NIST standardised: FIPS 203 (finalised 2024)
  • 800-byte public key: stored on-chain alongside Dilithium key
  • Encrypts AccountInfo identity metadata, purchase payloads, messages
  • Encrypts KYC permission data in BetaChainPermission records
  • Hybrid encryption: Kyber KEM + AES-256-GCM for bulk data
  • Private key (1632B) held exclusively by account holder that is never transmitted or exposed
KEY DERIVATION FLOW
SEED PHRASE
12–24 BIP39
mnemonic words
PBKDF2 ROOT
64-byte entropy
HMAC-SHA512
DILITHIUM KEYPAIR
Sign transactions &
forge blocks
KYBER KEYPAIR
Encrypt & decrypt
on-chain data
COMBINED PUBLIC KEY: 2112 BYTES ON-CHAIN

What Goes On-Chain

The 2112-byte combined public key (800B Kyber + 1312B Dilithium) is stored in the account table on activation. Account ID is derived from the Dilithium public key hash. No private key data is ever exposed or stored on the blockchain.

Single Backup Recovery

One seed phrase recovers both PQC keys on any device. Deterministic derivation means the same words always produce the same keys. No cloud backup, no second phrase, no key file required.

REED-SOLOMON ADDRESSES

Human-friendly account addresses are generated from the COMBINED PUBLIC KEY to create a : SHAMWARI-XXXX-XXXX-XXXX-XXXXX format type. These addresses are used to reference accounts across the blockchain from transaction submissions to database entry and querying.

03
ENCRYPTED IDENTITY
AccountInfo: Plain-text general information and encrypted KYC data.

Shamwari accounts can have set plain general information and also store identity metadata on-chain i.e. legal names, contact information, jurisdiction identifiers, personal identity information encrypted with the account’s Kyber public key. The encrypted data ciphertext is permanently stored on-chain; only the account holder can decrypt and read or share it.

Kyber-Encrypted at Rest
AccountInfo data is encrypted with the account's Kyber-512 public key using the hybrid KEM + AES-256 pattern. The blockchain stores ciphertext. Third parties, including node operators, cannot read the underlying identity data. Only the account holder with the Kyber private key can decrypt it.
Verifiable Without Exposure
The existence of AccountInfo and its encrypted hash are publicly verifiable and counterparties can confirm that an account's ownership or profile. The limited plain information can be used for non-sensitive interactions while the encrypted data can be used for identity-specific KYC processes.
Selective Disclosure
Account holders control what they disclose and to whom. Sharing the decrypted AccountInfo data with a specific counterparty (e.g., a bank) is a bilateral action and not a public broadcast. The blockchain holds the encrypted commitment; disclosure is off-chain and consent-based.
Immutable Record at Every Update
Every SET_ACCOUNT_INFO transaction creates a versioned record in the AccountInfoTable. Historical identity states can be queried at any block height, providing an immutable timeline of field changes for compliance and audit purposes.
Private by design
Unlike privacy chains that use zero-knowledge proofs to obscure transactions, Shamwari's approach is different: transactions themselves are public (enabling regulatory audit), but sensitive payload data within transactions is Kyber-encrypted. Regulators can verify that a transaction occurred; only authorised parties can read its contents.
ACCOUNTINFO FIELDS

Plain-text Fields (OPTIONAL)

  • Gender : for individuals
  • Date of Birth , or date of incorporation for organizations
  • Nationality : ISO 3166 country code
  • Website URL : link to website
  • Display Picture URL : link to image for wallet account display
  • ReadME : introductory information on person or organization

EncryptedData Fields (Examples)

  • Legal Name(s) — Full registered legal name or entity name
  • Addresses — ISO 3166 country code or jurisdiction identifier and physical address
  • Contact Details — Emails and phone numbers.
  • Identity Number — National identity number for individuals
  • Passport Number — National passport number for individuals
  • Licence Number — Regulatory licence reference for BANK/FSP/MFI types
  • Institution Code — BIC, routing code, or institutional identifier

KYC Permission Record

CHAIN_ADMIN accounts store Kyber-encrypted KYC attestation data in BetaChainPermission records when granting CHAIN_USER access. This creates a permanent, cryptographically-anchored on-chain record of every KYC onboarding event — including timestamp, granting institution, and encrypted evidence reference.

04
ON-CHAIN DOMAINS
.shamwari.network domain-like account addresses

Every account can register a Shamwari native domain in the .shamwari.network namespace. Domains are stored on-chain, valid for approximately 1 year (365 × ~7200 blocks), and automatically expire without renewal. All domain lifecycle events are consensus transactions.

Register Once, Use Everywhere
A domain like mybank.shamwari.network resolves to the registering account’s address on any chain. Domains are valid globally by default and once registered, resolve across all BetaChains. The registered domain can be used instead of the Solomon-Reed human-readable account address to reference a specific account with a known domain.
Automatic Expiry at Block Height
Domain validity is managed by the AFTER_BLOCK_APPLY protocol automation. When the expiration block height is reached, and no renewal transaction was submitted and confirmed, the domain is automatically released for registration by other accounts. No manual deregistration required by the issuer.
Transfer and Renewal Lifecycle
Domains support ACCOUNT_DOMAIN_TRANSFER to another account, ACCOUNT_DOMAIN_RENEWAL within the 30-day renewal window, and ACCOUNT_DOMAIN_DEREGISTER for explicit release. All lifecycle events create immutable on-chain records and are enforced at consensus.
Namespace Security
The .shamwari.network namespace is managed by the blockchain protocol preventing domain squatting and with no DNS-equivalent centralisation. Registration is first-come, first-served and enforced by the consensus rules of the blockchain.
DOMAIN TRANSACTION TYPES
DOMAIN LIFECYCLE
4
ACCOUNT_DOMAIN_REGISTER — Claim a .shamwari.network domain
ACCOUNT_DOMAIN_RENEWAL — Extend within 30-day renewal window
ACCOUNT_DOMAIN_TRANSFER — Transfer ownership to another account
ACCOUNT_DOMAIN_DEREGISTER — Explicitly release before expiry

Domain Validity Period

  • Validity: ~1 year; calculated in blocks, not calendar time
  • At ~7200 blocks/day: approximately 2,628,000 blocks per year
  • Renewal window: 30 days (216,000 blocks) before expiry
  • Expiry: AFTER_BLOCK_APPLY releases domain automatically
  • Canonical expiration: expired domains immediately available for re-registration
05
AI AGENT ACCOUNTS
The world's first on-chain AI account type

AccountType.AUTONOMOUS is purpose-built for AI agents that need to transact on-chain. Hard spending limits, transaction type whitelists, recipient restrictions, and rolling window caps are all enforced at the consensus layer and not in off-chain monitoring software that can be bypassed or overridden.

AUTONOMOUS ACCOUNT CONTROL RULES
Transaction Type Whitelist
The account owner configures a whitelist of permitted transaction types. An AI agent can be restricted to only CURRENCY_PAYMENT and SUBSCRIBE, or EXCHANGE_BUY and PURCHASES, or any permitted combination. Any transaction type not on the whitelist is rejected at gate 4 of the consensus pipeline.
Per-Holding Spending Cap
Maximum spend per billing period per currency or asset holding. The agent cannot exceed this cap regardless of what instructions it receives. The cap is enforced by the consensus engine and the transaction simply fails with an InsufficientBalanceException before the agent can act on it.
Rolling Window Limits
Total spend across a configurable rolling block window (e.g., 7-day equivalent in blocks). This prevents an agent from "saving up" spend across low-activity periods and then bursting through its effective budget in a single high-activity period.
Recipient Whitelist
An agent can be restricted to transacting only with specific account IDs. Payments or trades to non-whitelisted recipients are rejected. This is the on-chain equivalent of a purchase order approval list in which the agent can only pay approved counterparties.
Minimum Balance Floor
The AUTONOMOUS account cannot reduce its balance below a configured floor. This ensures the account always retains enough to cover its subscription obligations, next billing cycles, and any protocol-required minimum balances.
AUTONOMOUS AGENT PERMISSION MATRIX
ALLOW Currency payments
ALLOW Asset trading
ALLOW Subscribe to services
ALLOW Commerce purchases
ALLOW Currency exchange
ALLOW Dividend receipt
DENY Issue certificates
DENY Insurance approval
DENY Grant permissions
DENY TotemApproval
DENY Currency issuance
DENY Chain config changes

Autonomous Trading Desk

Autonomous agents execute trades on the Totem Exchange within hard on-chain limits e.g max position size, permitted asset classes, daily volume cap. No off-chain monitoring needed. The blockchain enforces it.

Automated Loan Processing

MFI agents process applications, verify credit scores, and disburse approved loans automatically with the protocol enforcing disbursement limits and approved recipient lists at consensus.

Recurring Payment Automation

Autonomous treasury agents manage subscription payments, supplier invoices, and dividend distributions within governance-approved parameters. Zero manual intervention. Zero bypass possible.

CREATE AN ACCOUNT

Post-quantum security. Identity Management. One seed phrase.

Create and manage Shamwari accounts with the full suite of identity, domain, and key management tools.