Blockmaze

Disclaimer

This whitepaper is provided for informational and explanatory purposes only. It describes the conceptual framework, design principles, and intended direction of the Blockmaze ecosystem, including its approach to blockchain governance, real-world asset representation, and global value exchange. The document does not constitute a final or binding specification of any product, protocol, or service.

Nothing in this whitepaper should be interpreted as an offer, solicitation, recommendation, or commitment to sell or acquire any digital asset, security, financial instrument, or participation right. The content does not represent legal, financial, investment, accounting, or tax advice. Readers are expected to conduct their own independent assessment and seek professional guidance before making any decisions based on the information contained herein.

The descriptions of systems, roles, processes, and mechanisms in this document reflect the current design intent and may evolve over time. Features, structures, and timelines are subject to change based on technical, legal, regulatory, or operational considerations. Forward-looking statements are based on current assumptions; actual results may differ due to external factors, including changes in technology, law, regulation, or market conditions.

No assurance is given that any described functionality will be completed, deployed, or adopted in the form described. This whitepaper does not create any legal relationship, obligation, or entitlement between the reader and any entity associated with Blockmaze. Blockchain-based systems and tokenized representations of real-world assets may be subject to different legal and regulatory treatment across jurisdictions. Readers are responsible for understanding and complying with all applicable laws in their respective jurisdictions.

1. Abstract

Blockmaze is a Layer-0 blockchain protocol designed as foundational infrastructure for real-world asset (RWA) tokenization ecosystems. Built on the Cosmos SDK with CometBFT Byzantine Fault Tolerant consensus and full EVM compatibility, Blockmaze provides a root settlement layer upon which sovereign chains, application-specific chains, and RWA-focused execution environments can be deployed.

The protocol addresses a structural deficiency in existing blockchain infrastructure: modern networks provide strong transaction finality but remain indifferent to whether the assets they settle are backed by credible, authorized, and continuously accountable issuers. Blockmaze closes this gap by implementing a verified issuance model at the protocol level. Every corporate issuer undergoes KYC verification and must hold legal authorization for the asset categories they tokenize. Issuer identity, licensing posture, token rules, and disclosure cadence are published through on-chain registries and enforced by a Governance Council of regulated entities.

Two standardized token templates—BMZ20 for bearer-redeemable assets and BMZ3643 for registry-coherent title assets—encode the distinct operational and legal requirements of different RWA classes directly into protocol-level behavior. The architecture supports a hybrid L0/L1 model: issuers may operate directly on the L0 root network, or deploy sovereign L1 domains for jurisdiction-specific requirements via the Sovereign Entity SDK. Cross-chain interoperability is achieved through the Inter-Blockchain Communication (IBC) protocol.

This whitepaper specifies Blockmaze's protocol architecture, consensus design, validator economics, governance model, token standards, asset lifecycle, tokenomics, and security posture. It is intended for protocol engineers, validators, enterprise RWA issuers, institutional investors, and ecosystem partners evaluating Blockmaze as infrastructure for compliant, institution-grade tokenization.

2. Key Terms

3. The Problem

Blockchains are good at one thing: settling transactions. They order transfers, record them in a shared ledger, and make the record permanent. For digital-only assets, this is enough. The chain is the full picture.

Real-world assets are different. A token that represents gold, dollars, or property carries an obligation outside the chain. Someone must hold the gold. Someone must keep the dollars in a bank. Someone must update the government land registry. The chain cannot enforce any of this.

3.1 The Accountability Gap

Most blockchains treat every token contract the same way. They do not check whether the deployer is a real company, whether that company has the legal right to issue the asset, whether reserves exist, or whether off-chain records match on-chain state.

This is the Accountability Gap: the chain finalizes transfers even when the issuer's promises break down. The chain does not know and does not care.

This is not a bug that a smart contract library can fix. General-purpose blockchains lack the basic building blocks: issuer identity, authorization checks, disclosure enforcement, and consequence signals. Bolting these on at the application layer creates fragmented, inconsistent systems that institutions cannot trust.

3.2 Two Kinds of Assets

Tokenized assets fall into two categories, and each needs different treatment:

• Bearer assets: You redeem these by presenting the token. No government registry update is needed. Examples: stablecoins, gold-backed tokens. The key risk is whether reserves exist.
• Title assets: Legal ownership depends on a government registry, not the token. Examples: real estate. The key risk is whether the on-chain record and the government record stay in sync.

Treating both as generic tokens either restricts bearer assets with unnecessary gatekeeping or leaves title assets without the registry coherence they require.

3.3 What Institutions Need

Before committing capital to tokenized assets, institutions require four things:

1. Attribution: The issuer must be a known, verified entity.
2. Authorization: The issuer must hold the legal right to issue the asset.
3. Standardization: Token behavior must be predictable and audited. No hidden admin powers.
4. Observability: The system must make issuer obligations visible over time, not just at launch.

Without these, settlement infrastructure speeds up risk instead of reducing it.

4. The Blockmaze Thesis

Blockmaze separates two concerns that existing chains mix together:

• Settlement is the network's job. The chain records transfers. No issuer or governor can reverse them.
• Accountability is the issuer's job. The issuer holds reserves, honors redemptions, updates registries, and publishes proof.

The chain should not try to force redemption by rewriting history. Instead, it should make issuer obligations visible, standard, and enforceable through economic consequences.

This is the Accountability Layer. An issuer can issue tokens only after verification. The issuer stays credible only while meeting ongoing obligations. When obligations fail, the market sees it.

These accountability rules must live at Layer-0, not in a single application on a single chain. When accountability is just an app, every issuer implements it differently (or skips it). When accountability is a protocol, every token inherits the same rules, every issuer faces the same checks, and the whole ecosystem runs on one auditable trust model.

This is why Blockmaze is a Layer-0. The accountability primitives—issuer registries, token standards, proof deadlines, governance—must apply across every chain in the ecosystem. A Layer-1 would confine these rules to one chain. A Layer-0 makes them the foundation for all chains built on Blockmaze.

5. Protocol Architecture

5.1 Why Layer-0

Blockmaze is a Layer-0, not a Layer-1. The difference is not just a label:

• A Layer-1 is a single chain with its own consensus, state, and apps. Its rules apply only to itself.
• A Layer-0 provides shared infrastructure: consensus, security, registries, cross-chain messaging—that multiple Layer-1 chains inherit.

Blockmaze acts as a Layer-0 by providing five things no single L1 can offer for an ecosystem:

1. A root settlement layer with instant BFT finality that sovereign L1 chains inherit.
2. A shared validator set whose economic incentives are tied to RWA settlement integrity.
3. Cross-chain messaging via IBC for asset transfers and registry lookups across all connected chains.
4. Protocol-level registries (issuer, token standard, chain) that apply across every chain—not trapped inside one L1.
5. A Sovereign Entity SDK for deploying jurisdiction-specific L1 chains that anchor back to L0.

The L0 root chain is not just a relay. It runs its own execution environment, registries, and governance. Issuers can deploy tokens on L0 without building their own chain. But L0's main role is to serve as the trust anchor for the wider ecosystem.

5.2 State Machine and Cosmos SDK

Blockmaze runs on a replicated deterministic state machine. The network holds one canonical state S at each block height. Transactions are grouped into blocks for processing. The state transition is deterministic:

S' = F(S, B)

F is the state transition function, S is the current state, B is a block of ordered transactions, and S' is the result. Any node that replays the same blocks from genesis will reach the same state. This determinism is what makes consensus possible: validators agree on the state by agreeing on the order of blocks.

Blockmaze uses the Cosmos SDK as its application framework. The SDK organizes functions into modules, each with its own state store, message handlers, and query endpoints. Blockmaze adds RWA-specific modules on top of the standard set (see Section 5.4).

5.3 CometBFT Consensus

CometBFT (formerly Tendermint BFT) handles networking and consensus. It propagates transactions, orders them into blocks, and gets validators to agree on which blocks are valid.

Core Properties

• Byzantine fault tolerance: The network tolerates up to one-third of validators acting maliciously. Safety holds as long as less than one-third of the total staked BMZ is in bad hands.
• Instant finality: Once a block gets signatures from more than two-thirds of validator stake, it is final. It cannot be reversed. There is no waiting period. This matters for RWA settlement, where legal and financial parties need clear finality before they recognize ownership.
• Liveness: The chain keeps producing blocks as long as more than two-thirds of the validator stake is online.

How a Block Gets Committed

Consensus runs in rounds for each block height. Each round has three steps:

1. Propose: A proposer (picked by weighted round-robin) broadcasts a block of transactions from the mempool.
2. Prevote: Each validator checks the block and broadcasts a prevote. Invalid or missing blocks get a nil vote.
3. Precommit: If a validator sees prevotes for the same block from more than two-thirds of the stake, it precommits. Once two-thirds precommit, the block is final.

If a round times out, a new proposer takes over. This keeps the chain alive even when individual validators go down.

ABCI: The Boundary Between Consensus and Application

CometBFT talks to the Blockmaze application through the Application Blockchain Interface (ABCI). This boundary keeps consensus and application logic separate. Key message types:

• CheckTx: Validates transactions before they enter the mempool. Checks signatures, sequence numbers, gas limits, issuer permissions, and whitelist status (for BMZ3643).
• DeliverTx: Processes transactions inside committed blocks. Runs state transitions: registry writes, token operations, proof submissions, governance actions.
• BeginBlock / EndBlock: Runs at the start and end of each block. Handles validator updates, reward distribution, slashing, and proof-of-reserves deadline checks.
• Commit: Computes the Merkle root of the current state. This root goes into the next block header, enabling lightweight clients to verify any state claim against validator signatures.

CometBFT keeps three ABCI connections open: one for mempool checks, one for consensus processing, and one for queries. Queries do not slow down block production.

5.4 Application Modules

Blockmaze extends the Cosmos SDK with purpose-built modules:

• x/issuer-registry: Stores issuer profiles, KYC status, authorization, permitted standards, proof deadlines, and compliance history.
• x/token-registry: Holds BMZ20 and BMZ3643 template definitions, approved versions, audit records, and deployment links.
• x/chain-registry: Tracks sovereign L1 metadata: jurisdiction, validator set, IBC channels, transparency ratings.
• x/proof-cadence: Manages proof submissions, deadlines, and automatic standing downgrades when proofs are missed.
• x/governance: Runs the Governance Council's quadratic voting, proposals, and issuer enforcement actions.
• x/bmz-staking: Extends Cosmos staking with issuer bonding, GBMZ liquid staking, and custom slashing conditions.
• x/evm: The EVM compatibility module (Section 5.5).

5.5 EVM Compatibility

Blockmaze supports the full Ethereum Virtual Machine. Developers can deploy Solidity contracts and use standard Ethereum tools with no changes. This works through:

• Ethereum transaction format wrapped as a Cosmos SDK message, so EVM and native transactions coexist in the same block.
• Ethereum's secp256k1 curve in the SDK keyring, supporting MetaMask, WalletConnect, and standard key pairs.
• A StateDB interface that maps Ethereum account state onto the Cosmos IAVL+ Merkle tree.
• A JSON-RPC endpoint supporting standard eth_* methods for use with Hardhat, Foundry, ethers.js, and web3.js.

BMZ20 and BMZ3643 tokens are available both as native Cosmos modules and EVM contracts, with the same behavior in both. Native modules offer tighter integration with the accountability layer. EVM contracts serve developers moving from Solidity-based workflows.

5.6 Hybrid L0/L1 Model

L0 Mode (Default)

An issuer deploys tokens on the L0 root chain. They inherit the default validator set, BFT finality, token standards, and the public accountability registries. No separate chain needed.

Sovereign L1 Mode (Optional)

Issuers in jurisdictions that need extra controls—such as data residency, local AML rules, or specific financial crime mitigation—can deploy a sovereign L1 chain using the Sovereign Entity SDK. The SDK provides:

• Pre-configured chain scaffolding with Blockmaze RWA modules built in.
• Tools for defining the L1's own validator set, staking rules, and slashing conditions.
• Configurable compliance hooks for pre-transaction and post-transaction checks.
• Automated IBC channel setup to the L0 root.

Sovereign L1s connect to L0 via IBC. They can look up issuer standing on L0, anchor settlement proofs to L0, and transfer assets cross-chain. They keep full control of their local execution, validators, and governance.

5.7 Cross-Chain Communication (IBC)

Blockmaze uses the Inter-Blockchain Communication (IBC) protocol for cross-chain messaging. IBC provides:

• Authenticated messaging: Each packet includes a cryptographic proof of the sender chain's state. The receiving chain checks this proof against its local light client. No trusted middleman needed.
• Ordered delivery: Packets arrive in the order sent. This preserves transfer logic across chains.
• State verification: Packets carry Merkle proofs. The receiving chain can verify any claim about the sender's state.

Within Blockmaze, IBC handles four jobs:

1. Asset transfers between L0 and sovereign L1 domains.
2. Cross-chain registry lookups (e.g., a sovereign L1 checking issuer standing on L0).
3. Settlement anchoring: sovereign L1s commit state roots to L0 for extra security.
4. Connections to external IBC-enabled networks in the Cosmos ecosystem.

5.8 On-Chain Registries

Blockmaze maintains three on-chain registries as core building blocks:

• Issuer Registry: Issuer identity, type, KYC status, authorization, permitted standards, proof deadlines, standing history, and bonded BMZ.
• Token Standard Registry: Canonical BMZ20 and BMZ3643 definitions, approved versions, audit hashes, and links between deployed tokens and their issuers.
• Chain Registry: Sovereign L1 metadata: jurisdiction, validator set, IBC channels, and transparency ratings.

These registries make accountability visible at the network level. Governance actions—issuer approvals, status changes, revocations—are recorded as state transitions, creating a complete audit trail.

5.9 Blockmaze Ecosystem: Integrated Architecture Overview

The Blockmaze ecosystem is a unified financial infrastructure designed to bridge traditional real-world asset (RWA) tokenization, decentralized governance, and secure trading.

1. Core Infrastructure: Blockchain Layer (Central Hub)

• Function: Serves as the immutable ledger and consensus engine for the entire ecosystem.
• Key Features: It supports custom Sovereign Entities via an SDK, allowing for tailored jurisdictional compliance. It manages the validation of transactions and smart contracts that power the peripheral modules.
• Connectivity: Acting as the central nervous system, it bi-directionally syncs data with the DAO, Staking, Exchange, and Tokenization platforms to ensure a "single source of truth."

2. Identity & Access: SSO Service (Single Sign-On)

• Function: The gateway for all users, ensuring a seamless and secure onboarding experience.
• Role: It provides unified authentication across the Tokenization Platform and the Exchange. By handling identity management centrally, it simplifies the user journey—one login grants access to asset creation, trading, and governance.

3. Asset Digitization: RWA Tokenization Platform

• Function: The engine for converting real-world assets into digital tokens (BMZ20 & BMZ3643 standards).
• Process: Issuers use this platform to fractionalize assets (like gold or equity). It integrates directly with the Exchange to create trading pairs and utilizes the Blockchain Layer to mint secure, compliant tokens.
• Flow: Data flows from here to the Exchange for liquidity and to the Blockchain for permanent record-keeping.

4. Governance Council DAO

• Function: A decentralized body that empowers the community to steer the ecosystem's future.
• Mechanism: It utilizes Quadratic Voting to prevent plutocracy (where wealth equals power), ensuring fair decision-making. Members vote using GBMZ Tokens (Governance BMZ).
• Interaction: Governance decisions directly influence the Blockchain Layer (e.g., protocol upgrades) and the Staking mechanisms.

5. Financial Incentives: Staking & Liquid Staking

• Function: Aligns user incentives with ecosystem health while generating yield.
• Mechanism: Users lock BMZ tokens to receive GBMZ (Governance tokens). This "Liquid Staking" model allows users to participate in governance (via GBMZ) while their original assets are staked, ensuring active participation doesn't come at the cost of liquidity.
• Connection: It feeds directly into the DAO (providing voting power) and interacts with the Exchange for token swaps.

6. Liquidity & Trading: Web Exchange

• Function: The marketplace where tokenized assets and ecosystem tokens are traded.
• Key Features: It provides liquidity for tokenized pairs and integrates institutional-grade custody (e.g., Fireblocks) for security.
• Flow: It receives asset data from the Tokenization Platform and liquidity from users, settling transactions back onto the Blockchain Layer.

6. Validator Economics

Blockmaze validators secure a network that settles real-world value claims. Their incentives must match this responsibility.

6.1 Validator Set and Delegation

The L0 root chain runs on a bounded validator set. Validators are ranked by total staked BMZ (self-bonded plus delegated). The set is updated at each epoch. Any BMZ holder can delegate to a validator, increasing that validator's weight and sharing in rewards. Validators set a commission rate on delegator earnings.

6.2 Rewards

Validators and delegators earn from two sources:

• Block rewards: New BMZ emitted per block according to the schedule in Section 12. Rewards are split by stake weight.
• Transaction fees: Gas fees paid in BMZ. Fees go to the block proposer and participating validators.

6.3 Slashing

Validators lose staked BMZ for provable misbehavior:

• Double-signing: Signing two different blocks at the same height. This is evidence of an equivocation attack. Penalty: a large percentage of the stake is slashed, and the validator is removed from the set (tombstoned) with no return.
• Prolonged downtime: Missing blocks beyond a defined threshold. Penalty: a smaller percentage is slashed, and the validator is jailed until they prove availability.

Delegators share in slashing losses. This gives delegators reason to pick reliable operators. Slashing parameters are adjustable through governance.

7. Governance

Governance runs the accountability side of Blockmaze. The protocol separates settlement from accountability. Governance manages accountability without touching settlement.

7.1 The Governance Council

Blockmaze starts with a Governance Council of ten regulated entities from different jurisdictions. The council reviews issuer applications, monitors compliance, and takes enforcement action when issuers fail their obligations.

The council does not control settlement. It cannot reverse transactions, censor blocks, or interfere with consensus. Its authority covers issuer permissions (approve, restrict, revoke) and protocol parameters. This boundary is enforced at the protocol level: governance transactions can only write to governance-managed state, not to consensus or settlement history.

7.2 Quadratic Voting

The council uses quadratic voting to prevent any single party from dominating outcomes. Under this system, the cost of casting n votes on one proposal is:

Cost(n) = n² GBMZ

One vote costs 1 GBMZ. Two votes cost 4. Three cost 9. A participant with 100x the tokens of another gets 10x the influence, not 100x. This makes it expensive for any one actor to control governance.

Votes use GBMZ tokens, which holders receive by staking BMZ. GBMZ used in a vote is locked for the voting period and returned when the proposal closes.

7.3 Scope and Enforcement

Scope Boundary

The Governance Council governs corporate issuers and L0 issuance only. It does not govern sovereign issuers, who retain full sovereignty by design. The protocol does not require government entities to submit to a technology-governance body. The council may publish transparency ratings for sovereign issuers, but cannot block, blacklist, or restrict their operations.

Issuer Admission

• Perform KYC verification for corporate issuers via designated verification providers.
• Validate legal authorization for the intended issuance category.
• Approve issuer eligibility, permitted standards (BMZ20, BMZ3643), and initial proof cadence.

Ongoing Monitoring and Enforcement

• Monitor proof cadence via the x/proof-cadence module's automated expiry mechanism.
• Publish issuer status changes to the Issuer Registry when proofs are missed or invalid.
• Revoke or restrict corporate issuer permissions when credibility or legal standing materially degrades: ability to issue, mint, burn, or modify policy parameters.

Enforcement actions do not affect network finality or reverse historical transfers. They are permission-level controls recorded in the Issuer Registry.

Issuer Ratings and Transparency

• Maintain a public issuer standing framework incorporating observable behavior, proof submission history, and credible feedback.
• Publish enforcement rationale and evidence thresholds at a policy level.
• Publicly manage and disclose RFPs, emissions execution, and treasury reporting.

7.4 Protocol Upgrades

Protocol changes follow a structured process:

1. Any GBMZ holder above a deposit threshold submits a proposal.
2. The proposal collects a minimum deposit to enter the voting.
3. GBMZ holders vote via quadratic voting. A quorum and supermajority are required.
4. Approved changes execute at a specified block height.

The council evolves over time: early phases focus on regulated oversight; later phases bring in broader community participation.

8. Issuer Framework

Every corporate issuer must pass a structured review before issuing tokens on L0.

8.1 Admission

The council verifies each applicant's identity (KYC) and legal authorization. Upon approval, the issuer gets a record in the Issuer Registry containing:

• Verified entity identity (name, jurisdiction, registration number).
• Authorized signatories and operational key addresses.
• Legal authorization attestations (licenses, registrations).
• Permitted token standards and approved template versions.
• Proof cadence requirements (how often the issuer must submit proof).
• Bonded BMZ amount.

The protocol does not grant licenses. It checks that the issuer already has the right licenses. Loss of a license is grounds for revocation.

8.2 Proof-of-Reserves and Proof-of-Presence

Issuers submit periodic proof attestations through the x/proof-cadence module:

• Proof-of-Reserves (BMZ20 issuers): An attestation that backing reserves exist. Includes a cryptographic hash of the reserve report, the auditor or custodian's identity, and a timestamp.
• Proof-of-Presence (BMZ3643 issuers): An attestation that the on-chain token state matches the off-chain government registry.

The protocol does not judge the content of proofs. Doing so would require trusted oracles and would add a point of failure. Instead, proofs are published on-chain for anyone to inspect. The market, auditors, and governance evaluate credibility. The protocol enforces the schedule and makes failures visible.

Automatic Deadline Enforcement

The x/proof-cadence module runs inside EndBlock:

1. It tracks each issuer's next proof deadline as a block height.
2. When a proof arrives on time, the deadline resets.
3. When a deadline passes with no proof, the module fires a ProofMissed event and downgrades the issuer's standing.

8.3 Issuer Standing: State Machine

Corporate issuer standing follows a defined state machine with graduated consequences:

APPLICANT    ──[Council approves]──> ACTIVE
ACTIVE       ──[Proof missed]─────> WARNING
WARNING      ──[Proof submitted]──> ACTIVE
WARNING      ──[Second miss]──────> PROBATION
PROBATION    ──[Proof submitted]──> ACTIVE
PROBATION    ──[Third miss]───────> RESTRICTED
RESTRICTED   ──[Council review]───> ACTIVE or REVOKED
ANY STATE    ──[License lost]─────> REVOKED
REVOKED      ──[terminal, no re-entry]

Each transition is recorded with a timestamp, the trigger, and a governance reference if relevant. Revocation is final: a revoked entity cannot re-enter the registry.

Tokens from a revoked issuer remain on-chain and transferable. Settlement is not affected. But the revoked issuer can no longer mint, burn, or change any token parameters.

9. Token Standards: BMZ20 and BMZ3643

Blockmaze defines two token templates, each matched to a different legal reality. Both are available as native Cosmos modules and EVM contracts. Both must reference an approved version from the Token Standard Registry.

9.1 BMZ20: Bearer Assets

BMZ20 is for assets where the holder redeems by presenting the token. No government registry update is needed.

Use Cases

• Fiat-redeemable stablecoins.
• Commodity-backed tokens (gold, silver, oil).
• Other redeemable, possession-based tokens.

Properties

• Open transfer: No whitelist. Tokens move freely between addresses.
• Redemption terms: Set at issuance and stored as an immutable policy hash.
• Proof-of-Reserves: Periodic attestations enforced by x/proof-cadence. Missed proofs trigger standing downgrades.
• Limited admin powers: Mint and burn only when the issuer is in ACTIVE standing. No freeze, blacklist, or metadata changes unless declared in the policy hash at launch.

9.2 BMZ3643: Title Assets

BMZ3643 is for assets where legal ownership depends on a government registry.

Use Cases

• Tokenized real estate.
• Any asset where a government registry determines legal ownership.

Properties

• Whitelist gating: Only approved addresses can hold or transfer tokens.
• Registry coherence: The issuer commits to keeping on-chain transfers and off-chain registries in sync. Each transfer emits an obligation event that the issuer must acknowledge.
• Tax parameters: Structured fields carry data for tax withholding, stamp duty, and registry fees. Defined at issuance, enforced at transfer.
• Proof-of-Presence: Periodic attestations that the on-chain and off-chain states match.

9.3 Token Lifecycle

[Insert diagram: Token Lifecycle State Machine]

Tokens follow a set lifecycle:

TEMPLATE_SELECTED    ──[Instantiate]────────> DEPLOYED
DEPLOYED             ──[Bind to issuer]─────> BOUND
BOUND                ──[Commit policy hash]──> ACTIVE
ACTIVE               ──[Mint / Burn]────────> ACTIVE
ACTIVE               ──[Issuer revoked]─────> FROZEN
FROZEN               ── transfers continue, no mint/burn

The FROZEN state protects existing holders. Tokens still transfer, but the revoked issuer cannot mint, burn, or change settings.

9.4 Comparison

10. RWA Lifecycle: End-to-End

This section traces the full path of a real-world asset on Blockmaze.

10.1 Issuer Onboarding

1. The issuer submits an application to the Governance Council with entity documents and authorization evidence.
2. The council runs KYC and authorization checks.
3. The council writes an ACTIVE record to the Issuer Registry with permitted standards and proof cadence.
4. The issuer bonds the required BMZ amount.

10.2 Token Issuance

5. The issuer picks BMZ20 or BMZ3643 from the Token Standard Registry and selects an approved template version.
6. The issuer creates a token instance (native module or EVM contract).
7. The token is linked to the issuer's registry ID, creating an immutable bond.
8. The issuer commits a policy hash covering redemption terms, proof schedule, whitelist rules (if BMZ3643), and tax parameters (if BMZ3643).

10.3 Trading and Transfer

• BMZ20 tokens transfer freely. The exchange provides trading pairs and liquidity.
• BMZ3643 tokens move only between whitelisted addresses. Each transfer triggers an obligation event for the issuer.

10.4 Ongoing Compliance

• The issuer submits proof on schedule. The x/proof-cadence module resets the deadline.
• Proofs are public. Third parties—auditors, analysts, token holders—can review them.
• Missed proofs trigger automatic standing downgrades and holder notifications.

10.5 Enforcement

• If an issuer fails obligations, the Governance Council reviews the evidence.
• The council submits an enforcement proposal through x/governance.
• On approval, the Issuer Registry restricts or revokes the issuer's permissions.
• Affected tokens enter FROZEN: transfers continue, mint and burn stop.
• All actions are recorded on-chain with a full audit trail.

11. Regulatory Alignment

This section describes design choices that align with regulatory frameworks. It is not a legal interpretation. Blockmaze does not provide legal advice and makes no claims about the regulatory status of any token.

11.1 Built-In Compliance Primitives

• Attribution: Every token links to a KYC-verified issuer. Anonymous issuance is not possible for corporate issuers on L0.
• Standardization: Token behavior is template-defined, versioned, and audited. No hidden admin powers unless declared at launch.
• Observability: Proof submissions, standing transitions, and enforcement actions are visible on-chain at all times.

11.2 Framework Alignment

• MiCA (EU): Issuer attribution, published token rules, and periodic disclosure requirements map to MiCA obligations for crypto-asset issuers.
• Travel Rule: Whitelist-based participation (BMZ3643) and structured transfer metadata support Travel Rule compliance.
• ISO 20022: Lifecycle events (issuance, transfer, redemption, disclosure) can map to ISO 20022-compatible message formats.
• U.S. posture: The protocol focuses on issuer accountability, not legal classification. Tokenized securities remain securities.

12. BMZ Tokenomics

12.1 What BMZ Does

BMZ is the native token. It serves four purposes:

• Validator staking: Validators and delegators stake BMZ to run consensus and earn rewards.
• Issuer bonding: Corporate issuers lock BMZ as an economic commitment. Bonded BMZ is at risk if the issuer fails.
• Gas fees: All L0 transactions consume gas paid in BMZ.
• Governance: Staking BMZ produces GBMZ, which is the voting token for governance decisions.

12.2 Supply and Allocation

Total Supply: 100,000,000,000 BMZ (fixed)

12.3 Vesting

• Founder tokens: Multi-year vesting with a cliff period.
• Investor tokens: Lock-up period followed by linear vesting.
• Validator emissions (20%): Released over time on a declining curve. Higher early emissions to attract validators; lower later as fee revenue grows.
• Circuit Breaker Reserve (4%): Held in protocol escrow. Release requires a supermajority governance vote. Reserved for emergencies.

BMZ has a fixed total supply. No inflation beyond the cap. This paper makes no pricing assumptions.

13. Security and Threats

This section covers attack vectors and the mechanisms that address them.

13.1 Consensus Security

• Safety: Two conflicting blocks cannot both be committed as long as less than one-third of stake is Byzantine. Breaking this requires coordinated double-signing, which is detectable and results in slashing.
• Liveness: The chain produces blocks as long as more than two-thirds of the stake is online. A one-third coalition can halt the chain but cannot forge blocks or reverse finality.
• Finality: Committed blocks are final. No reorgs, no confirmation windows.

13.2 Application-Layer Threats

A. Fraudulent Issuance

Threat: Someone fakes KYC documents to gain issuer status and issue bogus tokens.

Response: KYC runs through the Governance Council with designated verification providers. Issuer profiles are public. Discovery of fraud triggers immediate revocation.

B. False Proofs

Threat: An issuer submits a proof-of-reserves that is not true.

Response: The protocol publishes proofs on-chain for public review. Third-party auditors, counterparties, and governance can challenge claims. The council can revoke permissions based on evidence of fraud. This mirrors the traditional audit model: auditors attest, markets verify, regulators enforce.

C. Governance Capture

Threat: A faction buys enough GBMZ to dominate votes.

Response: Quadratic voting raises the cost of concentrated influence: n votes cost n² tokens. Council seats are spread across jurisdictions. All votes are public. Governance broadens over time.

D. Cross-Chain Attacks

Threat: A compromised sovereign L1 forges IBC proofs to steal escrowed assets on L0.

Response: IBC relies on light client verification. Blockmaze uses mandatory light client updates, governance-managed allowlists for new IBC connections, and monitoring for unusual cross-chain activity.

E. Validator Collusion

Threat: Validators controlling one-third of the stake halt the chain or censor transactions.

Response: The validator set is designed for geographic and institutional diversity. A one-third coalition can halt but cannot forge or reverse blocks. Extended downtime triggers slashing.

13.3 Residual Risks

Some risks cannot be removed by protocol design alone:

• Credit risk: An issuer goes insolvent or refuses to honor redemptions.
• Integrity risk: Sophisticated fraud that escapes market and governance detection.
• Process risk: Off-chain registry updates lag behind on-chain transfers.
• Regulatory risk: Law changes that alter how tokenized assets are treated.

These risks are inherent to real-world asset tokenization. Blockmaze makes them visible and subject to enforcement, but does not claim to eliminate them.

14. Competitive Positioning

Blockmaze shares technical foundations with existing ecosystems but differs in one key way: it embeds RWA accountability at the protocol layer. Here is how it compares.

14.1 Cosmos

Both use the Cosmos SDK and CometBFT. Cosmos is a general-purpose framework for building sovereign chains. It does not include issuer registries, RWA token standards, or governance-managed issuer standing at the protocol level. Any Cosmos chain can add RWA features, but they stay isolated to that chain. Blockmaze makes them the foundation for the entire ecosystem.

14.2 Polkadot

Polkadot provides shared security through its relay chain and cross-chain messaging via XCM. Its relay chain does not address asset compliance. Each parachain must build its own RWA logic with no shared registries or issuer accountability. Blockmaze puts issuer governance and token standards at the root layer.

14.3 Avalanche

Avalanche supports custom subnets with fast finality. Subnets run independently without shared issuer registries, token standards, or compliance governance at the platform level. Blockmaze provides these as native L0 features that every connected chain inherits.

14.4 Summary

Blockmaze does not compete on general-purpose blockchain infrastructure. Cosmos, Polkadot, and Avalanche are mature in that space. The difference is that Blockmaze bakes RWA accountability, compliance, and standardization into the Layer-0 itself.

15. Roadmap

Phase 1: Foundation

• Launch L0 root chain with CometBFT and EVM compatibility.
• Deploy core modules: issuer registry, token registry, proof cadence, governance, staking.
• Deploy BMZ20 and BMZ3643 templates (native + EVM) with third-party security audits.
• Onboard the genesis validator set.
• Seat Governance Council: ten regulated entities across jurisdictions.

Phase 2: Ecosystem Activation

• Launch the issuer KYC pipeline and legal authorization checks.
• Activate proof-of-reserves and proof-of-presence enforcement.
• Integrate BMZ bonding with issuer standing.
• Deploy GBMZ liquid staking and quadratic voting.
• Launch Web Exchange with Fireblocks custody.
• Launch the SSO service and the RWA Tokenization Platform.

Phase 3: Expansion

• Release the Sovereign Entity SDK.
• Run sovereign L1 pilots in select jurisdictions.
• Open IBC connections to the broader Cosmos ecosystem.
• Ship BMZ3643 coherence workflows with tax parameter support.
• Broaden governance participation beyond the initial council.