# Mazze - Fast. Secure. Private. Mazze documentation with current architecture, privacy, and tokenomics sections aligned to the new-docs source.
Purpose, key features, and underlying technology/files/YBGu1fNygzNStmqLSGoxhttps://github.com/MazzeLabs/docs/blob/docs/broken-reference/README.md
Progress timeline, strategic objectives, key phasesThe project's development plan, including upcoming milestones and future releases./files/dp6a3pvLUD2MkeR4XNzmhttps://github.com/MazzeLabs/docs/blob/docs/broken-reference/README.md
Token distribution, economic model, usage incentives/files/COEm3csEI3DeD4PJHSpBhttps://github.com/MazzeLabs/docs/blob/docs/broken-reference/README.md
Development kits, technical guides, collaborative platforms/files/Pw5ernldXbQ33KOr7zWOhttps://github.com/MazzeLabs/docs/blob/docs/broken-reference/README.md
Informative answers, key terms, comprehensive guide/files/5hq71lEAoIBKnD0qjN7Fhttps://github.com/MazzeLabs/docs/blob/docs/broken-reference/README.md
Collaborative events, engagement initiativesComprehensive technical documentation for developers who want to contribute to the project./files/ikEFJpmAzemIcOtGwIGFhttps://github.com/MazzeLabs/docs/blob/docs/broken-reference/README.md
## Canonical Sections From `new-docs` * [Architecture](/architecture/architecture) * [Privacy](/privacy/privacy) * [Tokenomics](/tokenomics/overview) # Introduction {% hint style="success" %} Greetings, everyone! Welcome to the inaugural edition of the Mazze documentation. For any technical inquiries, please connect with us on [Telegram](https://t.me/MazzeLabs) or [Discord](https://discord.mazze.io/). Be advised that these documents are in an ongoing state of development as of the latest update on February 12, 2024. {% endhint %} Mazze is a layer 1 blockchain designed to establish a decentralized platform integrating robust security and absolute transparency. Its innovative architecture facilitates sustainable high-volume transactions, a significant achievement for a Proof of Work (PoW) chain. Mazze is committed to minimizing environmental impact, a key concern in blockchain technology today. It supports Decentralized Finance (DeFi) and is tailored to empower the creation and proliferation of Decentralized Applications (DApps) in sectors such as finance, healthcare, and education. These applications aim to transform service delivery and access in these fields by offering unparalleled efficiency, security, and user control. Mazze's focus on these sectors demonstrates its dedication to advancing blockchain technology and addressing real-world challenges. The platform leverages advanced cryptographic techniques and innovative consensus mechanisms to optimize transaction speed and reliability, ensuring scalability and network resilience. Designed with user-centricity, Mazze caters to both technical and non-technical users. Its approach to governance and legal compliance reflects a deep understanding of the regulatory landscape, ensuring alignment with global standards and practices. This comprehensive approach positions Mazze as a pioneering force in the blockchain domain, with a clear trajectory towards shaping the future of decentralized technologies and their applications in vital sectors of the economy​​. # Why a New Blockchain? {% hint style="info" %} *You can skip to* [*TL;DR*](#tl-dr) {% endhint %} We, how we are calling now, the Mazze team, felt a compelling need to introduce a fresh perspective in this domain. Our extensive background in blockchain technology has equipped us with a unique understanding of its potential and limitations. Dissatisfied with the operational dynamics of previous blockchain projects we've been involved with, we embarked on creating a new blockchain - one that's rapid, robust, stable, and secure, without relying on millions in venture capital or other private investments. Our vision for Mazze is to demonstrate that a blockchain project can thrive independently, free from the influence of private investors. This autonomy allows us to innovate and execute our ideas more freely, setting a precedent for a successful, investor-independent blockchain project. Choosing Proof of Work (PoW) over Proof of Stake (PoS) was a strategic decision. We believe that PoW, which rewards miners for contributing computing power, offers a more reliable and equitable form of consensus than PoS, which favors those with larger stakes. This aligns with our mission of fostering a decentralized and community-oriented network. Mazze isn't built from scratch but is a sophisticated amalgamation of various open-source elements, meticulously pieced together to form what Mazze is today. Our GitHub repository is open to the public, inviting the community to play an active role in the project's evolution. This approach has already sparked interest among developers from other blockchain projects who are keen on collaborating with us. Our commitment is to create a community-driven project. We believe that the best innovations come from collective wisdom and diverse perspectives. Therefore, we're fostering an environment where the community's voice is not just heard but is a driving force behind our development. As we advance, our focus remains on creating a blockchain that is not just a technological marvel, but one that aligns with the ethos of decentralization, community involvement, and transparency. At Mazze, we're not just building a blockchain; we're nurturing a movement that redefines the boundaries of blockchain technology. ## TL;DR * **Mazze Team Background** | Extensive experience in blockchain, leading to a unique understanding of its potential and limitations. * **New Blockchain Development** | Created to be rapid, robust, stable, and secure without heavy reliance on venture capital or private investments. * **Independent Vision** | Mazze aims to show that blockchain projects can succeed independently, free from private investor influence. * **Decision for PoW** | Chose Proof of Work over Proof of Stake for a more reliable, equitable consensus that rewards community contributions, ensuring network security and decentralization. * **Open Source Foundations** | Mazze is built using a combination of various open-source elements, not from scratch. * **Community Involvement** | Public GitHub repository to encourage community participation in project development. * **Collaboration and Growth** | Interest from other blockchain project developers for collaboration. * **Community-Driven Focus** | Commitment to a project driven by collective wisdom and diverse perspectives. * **Project Principles** | Focused on decentralization, community involvement, and transparency, going beyond just technology to foster a movement in blockchain technology. # Technical Specifications | **Metric** | **Value** | | --------------------------------------------- | -------------------------------------------- | | Consensus / Security | Proof of Work (RandomX) | | Ledger Model | DAG + DETS | | Native Genesis Issuance | 3,900,000,000 MAZZE | | Mining Supply Target | 2,500,000,000 MAZZE | | Theoretical Native Upper Bound | 6,400,000,000 MAZZE | | Initial Base Mining Reward | 4 MAZZE | | Halving Interval | 312,500,000 blocks | | Wrapped MAZZE on Ethereum (current baseline) | 4,900,000,000 MAZZE | | Shielded Pool Merkle Tree Depth | 32 | | Shielded Pool Root History | 64 roots | ### Reference Sections * [Architecture](/architecture/architecture) * [Privacy](/privacy/privacy) * [Tokenomics](/tokenomics/overview) # Whitepaper Economic and Technological Innovations of Mazze The whitepaper on the Mazze blockchain project offers a detailed analysis of its economic and technological aspects. It focuses on how the project enhances blockchain performance, notably through parallel block processing, a feature that distinguishes Mazze from traditional blockchains such as Bitcoin and Ethereum. The paper also delves into the economic model of Mazze, assessing its sustainability and how storage costs affect user behavior in a decentralized network. Additionally, it provides an insightful overview of the factors that influence the ecosystem and user motivation, with a particular emphasis on environmental sustainability and DeFi applications. This document aims to contribute to the blockchain field through its analytical and pragmatic approach. {% embed url="" fullWidth="false" %} # Team We are [**profEdwin**](https://t.me/eliteminer_edwin), [**Equin0x**](https://t.me/Equin0x0), and [**Paladin0x**](https://t.me/Paladin0x), key members of **Team Mazze** - a coalition of visionary technologists. Alongside our colleagues, we're setting out to revolutionize the blockchain landscape with our groundbreaking ideas. Our team embodies innovation and a commitment to community-driven development, principles that are at the heart of our collaborative efforts. ### **Our Journey and Philosophy** Our story began as individuals within the blockchain sector, contributing to various projects and leveraging this revolutionary technology. Our paths merged at a conference, united by a shared perspective on the industry's pitfalls - overvaluation and development cost inflation, driven more by profit than by technological advancement. This realization sparked our collaboration and friendship, laying the foundation for the Mazze team. ### **Our Mission and Approach** With extensive experience in both the technical and managerial facets of crypto, we are now developing a new, self-sustaining blockchain network that **prioritizes the community over private investors and VCs**. Our project is designed with the everyday investor in mind, aiming to be as inclusive as possible. ### **Navigating the Future with Caution** For strategic and legal reasons, we maintain our anonymity. The complexities of blockchain creation, token issuance, and the sales process demand careful navigation of the evolving legal landscape. We anticipate revealing our identities and past achievements as the project solidifies and the regulatory environment becomes clearer. ### **An Invitation to Join the Movement** We are already in discussions with potential collaborators who share our vision of building not just a blockchain, but a movement that empowers its community. The Mazze team is dedicated to transparency, innovation, and the democratization of blockchain technology. ### **Join Us in the Revolution** We invite you to be part of this exciting journey. Together, we can create a future where technology benefits the many, not the few. #### **Welcome to Mazze!** # Phases This roadmap reflects current implementation status and removes date-based labels. ### PHASE A | Foundation > *`Core Architecture and Project Setup`* * [x] Concept development * [x] Whitepaper drafting * [x] Initial technical documentation * [x] Branding and online presence * [x] Early community outreach ### PHASE B | Core Network and Tooling > *`PoW Network, Token Framework, and Dev Operations`* * [x] PoW + DAG/DETS technical direction established * [x] Wrapped MAZZE ERC20 deployment and allocation framework * [x] Testnet operational flow defined * [x] Node + miner setup guides (Docker and source) * [x] Mazze CLI workflows documented * [x] JSON-RPC operational documentation * [x] Mining modes documented (`stratum`, `cpu`, `disable`) * [x] Privacy implementation documented (shielded pool + Groth16 flow) ### PHASE C | Mainnet Readiness and Ecosystem > *`Launch Hardening and Ecosystem Activation`* * [ ] Mainnet launch readiness and validation * [ ] Node operator expansion * [ ] Bridge operations hardening and monitoring * [ ] Ecosystem app rollout (DEX and related integrations) * [ ] Hackathon and grant program execution * [ ] Strategic ecosystem partnerships ### PHASE D | Expansion and Optimization > *`Scale, Interoperability, and Long-Term Growth`* * [ ] Cross-chain interoperability expansion * [ ] DeFi ecosystem growth initiatives * [ ] Network optimization and high-BPS soak tuning * [ ] Operational compliance and governance hardening * [ ] Long-term sustainability initiatives # Overview This section reflects the current tokenomics model from `new-docs`. ### **Current Model (as of February 6, 2026)** * **Wrapped MAZZE on Ethereum:** 4,900,000,000 MAZZE * **Native Genesis Issuance:** 3,900,000,000 MAZZE * **Bridge Bootstrap Reserve:** 1,000,000,000 MAZZE * **Mining Emission Target (native):** 2,500,000,000 MAZZE * **Theoretical Native Upper Bound:** 6,400,000,000 MAZZE ### **Important Bridge Constraint** Bridge liquidity is directional. If one direction runs out of destination-side liquidity, that direction pauses until liquidity is restored by opposite-direction flow. ### **Tokenomics Pages** * [Wrapped Token (ERC20)](/tokenomics/wrapped-token-erc20) * [Allocations](/tokenomics/allocations) * [Bridge Liquidity](/tokenomics/bridge-liquidity) * [Issuance](/tokenomics/issuance) * [Shielded Pool Genesis Fund](/tokenomics/shielded-pool-genesis-fund) * [Inflation](/tokenomics/inflation) (summary; now covered in detail by `issuance.md`) # Token Utility The Powerhouse of the Mazze Ecosystem and the fueling Ecosystem Growth The MAZZE token utility is now described using the current model in `new-docs`. ### **Wrapped MAZZE (Ethereum) Utility** 1. **Facilitates Immediate Liquidity** | Provides early market access on Ethereum. 2. **Supports DEX and CEX Access** | Enables trading and onboarding before full native migration. 3. **Supports Development and Ecosystem Funding** | Helps maintain operations and expansion. 4. **Enables Bridge Onboarding** | Allows Ethereum-side users to move into native MAZZE as bridge capacity allows. ### **Native MAZZE (Mazze Chain) Utility** 1. **Transaction and Execution Fuel** | Used for native-chain transaction economics. 2. **Mining and Security Incentives** | Issuance follows the configured halving schedule. 3. **Fee/Burn Accounting** | Realized supply is affected by mint and burn paths. 4. **Privacy-Related Flows** | Supports shielded pool funding and private transfer mechanics. ### **Reference Pages** * [Wrapped Token (ERC20)](/tokenomics/wrapped-token-erc20) * [Bridge Liquidity](/tokenomics/bridge-liquidity) * [Issuance](/tokenomics/issuance) * [Shielded Pool Genesis Fund](/tokenomics/shielded-pool-genesis-fund) # Wrapped Token (ERC20) The Powerhouse of the Mazze Ecosystem and the fueling Ecosystem Growth ### Token Details
Contract NameMazze
SymbolMAZZE
ChainEthereum
StandardERC20
Decimals18
Contract Address0x4A029F7bCf33AcB03547D8fA7be840347973e24e
### Current Supply State * **Current wrapped MAZZE on Ethereum:** 4,900,000,000 MAZZE * **Legacy ITS reference in old materials:** 5,000,000,000 MAZZE * **Current docs baseline:** 4.9B live wrapped amount ### Bridge Bootstrap and Mining Coverage * 1,000,000,000 MAZZE is planned as bridge bootstrap and initial mining-side coverage. * This reserve is sourced partially from **Ecosystem Development** and **Team Growth** allocations. ### Directional Bridge Liquidity Rule * Bridge liquidity is not infinite one-way liquidity. * If destination-side liquidity is insufficient, that transfer direction is paused. * The direction reopens when opposite-direction flow restores enough liquidity. ### Wrapped MAZZE Utility | Facilitates Immediate Liquidity | Supports DEX and CEX Access | | ---------------------------------- | --------------------------- | | Supports Development Funding | Supports Market Continuity | | Enables Ethereum Holder Onboarding | Supports Bridge Rollout | For liquidity constraints and directional behavior, see [Bridge Liquidity](/tokenomics/bridge-liquidity). # Allocations ### Allocation Framework (ERC20 Reference)
CategoryPercentageAmount
Public Sale and Liquidity52%2,600,000,000 MAZZE
Ecosystem Development Fund20%1,000,000,000 MAZZE
Team Growth Fund12%600,000,000 MAZZE
Community Engagement Fund8%400,000,000 MAZZE
Marketing and Promotion Fund8%400,000,000 MAZZE
### Current Operational Note * Live wrapped MAZZE baseline used by current docs: **4,900,000,000 MAZZE** on Ethereum. * Bridge bootstrap reserve: **1,000,000,000 MAZZE**. * The reserve is sourced partially from **Ecosystem Development** and **Team Growth** funds. ### Vesting and Lock References * **Public Sale and Liquidity** | Liquidity lock-up period: 12 months on Unicrypt. * **Ecosystem Development Fund** | 1 month cliff, then linear vesting over 11 months. Uncx: * **Team Growth Fund** | 1 month cliff, then linear vesting over 11 months. Uncx: * **Community Engagement Fund** | 2 weeks cliff, then linear vesting over 11 months. Uncx: * **Marketing and Promotion Fund** | 2 weeks cliff, then linear vesting over 11 months. Uncx: # Bridge Liquidity This page describes the operational bridge-liquidity logic used alongside Mazze tokenomics. ### Current Baseline * Wrapped MAZZE on Ethereum: **4,900,000,000 MAZZE** * Native genesis issuance: **3,900,000,000 MAZZE** * Bridge bootstrap reserve: **1,000,000,000 MAZZE** * The bridge reserve is sourced partially from **Ecosystem Development** and **Team Growth** allocations. ### Why the 1B Reserve Exists The reserve is intended to bootstrap bridge operations and provide initial coverage for mining-era flows. It is not intended as infinite one-way bridge liquidity. ### Directional Liquidity Rule Bridge capacity is directional: * Direction A: **Ethereum -> Mazze native** * Direction B: **Mazze native -> Ethereum** A transfer in one direction consumes destination-side liquidity. If destination-side liquidity for that direction is insufficient, that direction is blocked until opposite-direction flow restores enough funds. Equivalent rule: * Ethereum -> Native transfer of `x` requires `native_bridge_liquidity >= x`. * Native -> Ethereum transfer of `x` requires `erc20_bridge_liquidity >= x`. * If the inequality is false, that transfer direction is paused. ### Relation to 6.4B Native Theoretical Maximum * Native theoretical maximum comes from `3.9B genesis + 2.5B mining target`. * This is a long-term issuance bound, not a statement that all assets are freely bridgeable at all times. * Bridge throughput is constrained by directional liquidity, so supply may exist on one side while transfers are temporarily paused in one direction. # Issuance ### Supply Summary * Native genesis issuance: **3,900,000,000 MAZZE** * Mining emission target (unchanged schedule): **2,500,000,000 MAZZE** * Theoretical native upper bound: **6,400,000,000 MAZZE** * `6.4B` is a theoretical long-term upper bound, not present-day circulating supply. ### Explicit Supply Logic At epoch `t`, native issued supply follows: `native_total_issued(t) = genesis_issued + mined_to_date(t) - burnt_to_date(t)` Where: * `genesis_issued = 3,900,000,000` * `mined_to_date(t)` follows the halving schedule and is bounded by the mining target in configuration. * `burnt_to_date(t)` includes MIP-1559 burns and other protocol burn paths. ### Codebase Constants Native supply and emission parameters are defined in `crates/mazzecore/parameters/src/lib.rs`: * `GENESIS_TOKEN_COUNT_IN_MAZZE = 3,900,000,000` * `MINING_SUPPLY_TARGET_IN_MAZZE = 2,500,000,000` * `MAX_SUPPLY_TOKEN_COUNT_IN_MAZZE = 6,400,000,000` * `INITIAL_BASE_MINING_REWARD_IN_UMAZZE = 4,000,000` (4 MAZZE) * `HALVING_INTERVAL_IN_BLOCKS = 312,500,000` ### Mining Reward Schedule * Initial base mining reward: `4,000,000 uMAZZE` (4 MAZZE) per block. * Halving interval: `312,500,000` blocks. * Reward is halved by integer division each interval until it reaches zero. ### Burn Interaction Realized supply can stay below the theoretical curve because burn is active: * MIP-1559 burn updates in execution (`burn_by_mip1559`). * Net epoch issuance adjustment in reward settlement. * Additional burn paths during execution. ### Related Pages * [Inflation](/tokenomics/inflation) * [Bridge Liquidity](/tokenomics/bridge-liquidity) * [Shielded Pool Genesis Fund](/tokenomics/shielded-pool-genesis-fund) # Shielded Pool Genesis Fund This page explains how `SHIELDED_POOL_GENESIS_FUND_MAZZE` is applied at genesis. ### What It Is * `SHIELDED_POOL_GENESIS_FUND_MAZZE` defines how many native MAZZE are moved to the shielded pool contract at genesis. * Code location: `crates/mazzecore/core/src/genesis_block.rs`. ### Funding Source (Important) The shielded pool genesis fund is sourced from the genesis treasury balance. It is **not minted** on top of genesis supply. Flow in code: 1. Treasury is funded from `GENESIS_TREASURY_BALANCE_MAZZY_STR`. 2. Seed amount is computed from `SHIELDED_POOL_GENESIS_FUND_MAZZE`. 3. If `treasury_balance >= seed`, code executes `transfer_balance(treasury -> shielded_pool, seed)`. 4. If treasury is missing or insufficient, seeding is skipped and a warning is logged. ### Supply/Accounting Impact * No extra issuance is created by this step. * `total_issued` is not increased during shielded pool seeding. * This is a balance reallocation inside existing genesis-issued funds. ### Related Pages * [Issuance](/tokenomics/issuance) * [Bridge Liquidity](/tokenomics/bridge-liquidity) # Inflation (Merged into Issuance) Inflation is now modeled in the broader **native issuance** accounting and is fully documented in [Issuance](/tokenomics/issuance). ### Current Rule `native_total_issued(t) = genesis_issued + mined_to_date(t) - burnt_to_date(t)` So inflation cannot be evaluated only from mined rewards; burn paths are part of net issuance. ### Current Baseline * Native genesis issuance: **3,900,000,000 MAZZE** * Mining target: **2,500,000,000 MAZZE** * Theoretical native upper bound: **6,400,000,000 MAZZE** ### Where to Read Full Details * [Issuance](/tokenomics/issuance) * [Bridge Liquidity](/tokenomics/bridge-liquidity) # Mazze Node Architecture This folder breaks the node into focused pages. Each topic is scoped to code in this repo and points to the main source files. ## Reading order 1. [Overview](/architecture/overview) - end-to-end pipeline and crate map. 2. [Block structure](/architecture/block-structure) - header/body fields and roots. 3. [Transaction pool](/architecture/transaction-pool) - intake, validation, packing. 4. [Block generation](/architecture/block-generation) - assembling blocks before mining. 5. [PoW and mining](/architecture/pow-and-mining) - Proof of Work, RandomX, Stratum. 6. [DAG and DETS](/architecture/dag-and-dets) - parent/referee graph model. 7. [Consensus](/architecture/consensus) - ordering, timer chain, checkpoints. 8. [Execution and state](/architecture/execution-and-state) - epoch execution and state roots. 9. [Verification](/architecture/verification) - block and tx validation rules. 10. [Storage and snapshots](/architecture/storage-and-snapshots) - state DB and snapshots. 11. [Synchronization](/architecture/synchronization) - sync phases and catch-up. 12. [Networking](/architecture/networking) - P2P, discovery, peer management. 13. [RPC and APIs](/architecture/rpc-and-apis) - JSON-RPC surfaces. 14. [Genesis and params](/architecture/genesis-and-params) - genesis build and config. 15. [Rewards and fees](/architecture/rewards-and-fees) - base reward, fees, penalties. 16. [Node types and light protocol](/architecture/node-types-and-light-protocol) - archive/full/light behavior. # Overview Mazze Node is built as a collection of Rust crates wired together by the main binary in `bins/mazze`. The runtime pipeline is: 1. Transactions arrive over RPC or P2P and enter the transaction pool. 2. The block generator asks the pool for a packable set of transactions and assembles a candidate block header/body. 3. Proof of Work (PoW) is computed locally or via Stratum workers. 4. The synchronization graph ingests headers and bodies and maintains the DAG connectivity. 5. The consensus graph (on top of sync) maintains the DAG-Embedded Tree Structure (DETS) and produces an ordered sequence of epochs. 6. The consensus executor executes epoch transactions and produces deferred state/receipt/logs roots. 7. Block and state data are persisted by the block data manager and storage manager. 8. RPC serves queries backed by the consensus graph, data manager, and state DB. ## Block flow (mermaid) ```mermaid flowchart LR subgraph Ingress rpc[RPC] --> pool[Transaction Pool] p2p[P2P Tx] --> pool end pool -->|pack| bg[Block Generator] bg -->|candidate block| pow[PoW / Mining] pow -->|solved block| sync[Synchronization Graph] sync -->|graph-ready| cons[Consensus Graph] cons -->|ordered epoch| exec[Consensus Executor] exec -->|state roots + receipts| data[Block Data Manager] data --> rpcq[RPC Queries] data -->|best info| bg ``` ## Crate map (high level) * `bins/mazze` - node entrypoint, wiring, and runtime services. * `crates/mazzecore/core` - consensus, sync, txpool, verification, PoW. * `crates/blockgen` - block assembly and mining orchestration. * `crates/network` - P2P transport, discovery, peer management. * `crates/dbs/storage` - state DB, snapshots, Merkle Patricia Trie. * `crates/primitives` - block, header, tx, receipt primitives. * `crates/client` - configuration and JSON-RPC handlers. * `crates/stratum` - Stratum service implementation. * `crates/transactiongen` - optional transaction generator for dev/test. ## Runtime loops * Sync loop: drives the catch-up phases and fetches missing headers/bodies. * Consensus loop: activates ready blocks, updates ordering, and emits epochs. * Execution loop: runs in a worker thread and commits epoch results. * Mining loop: assembles blocks, pushes PoW problems, and submits solutions. * RPC loop: exposes state/block/txpool APIs and tracing. ## End-to-end data flow (compressed) * New tx -> `TransactionPool` -> `PackingPool` -> `BlockGenerator`. * New block header -> `SynchronizationGraph` -> body fetch -> `ConsensusGraph`. * Ordered epoch -> `ConsensusExecutor` -> roots/receipts -> `BlockDataManager`. * Persisted data -> RPC queries and mining inputs. ## Key source files * `crates/mazzecore/core/src/consensus/mod.rs` * `crates/mazzecore/core/src/sync/synchronization_graph.rs` * `crates/mazzecore/core/src/consensus/consensus_inner/consensus_executor/mod.rs` * `crates/mazzecore/core/src/transaction_pool/mod.rs` * `crates/blockgen/src/lib.rs` * `crates/dbs/storage/src/lib.rs` * `crates/client/src/rpc/impls/mazze/mazze_handler.rs` # Block structure Mazze blocks are encoded as a header plus a list of signed transactions. The header carries both DAG topology information (parent + referees) and execution outputs (deferred roots). ## Header fields (BlockHeader) * `parent_hash` - parent edge in the tree portion of DETS. * `height` - block height on the main chain (epoch height). * `timestamp` - unix time used for ordering and PoW checks. * `author` - miner/producer address. * `transactions_root` - MPT root of transaction hashes. * `deferred_state_root` - state root after deferred epoch execution. * `deferred_receipts_root` - receipts root for the executed epoch. * `deferred_logs_bloom_hash` - bloom for logs in the executed epoch. * `blame` - count of ancestors whose deferred roots are incorrect, used for light verification and reward logic. * `difficulty` - PoW difficulty for the block. * `adaptive` - WLSR adaptive flag used by consensus weighting. * `gas_limit` - block gas limit used by packing and verification. * `referee_hashes` - extra DAG edges referencing other blocks. * `custom` - custom bytes used for fork markers and protocol transitions. * `nonce` - PoW nonce. * `base_price` - per-space base fee (native and EVM). ## Deferred roots and epochs Execution is deferred by a fixed number of epochs to reduce reorg churn. The header of block N carries roots computed from earlier epoch execution, which is why these fields are labeled "deferred". ## Block body The body is a vector of `SignedTransaction`. The canonical `Block` encoding includes transactions without sender/public fields (RLP of `TransactionWithSignature`), while helper encoders can include the public key when needed for RPC or sync. ## Compact blocks `CompactBlock` is used for efficient block relay. It includes short IDs derived from a random nonce, so peers can reconstruct the full block from their mempool. ## Key source files * `crates/primitives/src/block_header.rs` * `crates/primitives/src/block.rs` * `crates/mazzecore/core/src/verification.rs` # Transaction pool The transaction pool buffers incoming transactions, verifies them, and produces a packable set for block generation. It manages per-sender nonce order and supports two "spaces" (native and EVM). ## Main components * `TransactionPool` - public API, ties to data manager and executed state. * `TransactionPoolInner` - core data structures and packing logic. * `DeferredPool` - per-sender nonce pools plus a packing pool. * `PackingPool` - randomized packing algorithm with gas/price weighting. * `AccountCache` - keeps nonce and balance hints for validation. ## Intake and validation flow 1. RPC/P2P submits a `SignedTransaction`. 2. `VerificationConfig` and `Machine` checks validate chain id, gas bounds, epoch bounds, and signature. 3. Transaction is inserted into the sender's `NoncePool`. 4. Ready contiguous nonces are mirrored into the `PackingPool`. ## Packing model * Transactions are grouped per sender into `PackingBatch` objects to preserve nonce order. * `PackingPool` is a treap-based structure that supports randomized sampling. * Sampling considers block gas limits, block size limits, and minimum gas price. * For EIP-1559 style pricing, the pool estimates the next base price using `compute_next_price` and adjusts the packing gas limit accordingly. ## Space-aware packing Mazze uses `SpaceMap` for dual spaces: * Native space is always packable. * EVM space is packable only after the configured transition height. The pool tracks gas usage per space and enforces per-space limits during block validation. ## Key source files * `crates/mazzecore/core/src/transaction_pool/mod.rs` * `crates/mazzecore/core/src/transaction_pool/transaction_pool_inner.rs` * `crates/mazzecore/packing-pool/src/pool.rs` * `crates/mazzecore/packing-pool/src/packing_batch.rs` # Block generation Block generation is responsible for assembling a candidate block header/body, using the current consensus best view and a packable transaction set. ## Core flow 1. `BlockGenerator` queries the txpool for best info and packed transactions. 2. It asks the consensus graph for the latest deferred state/blame info. 3. It chooses a parent and a referee set (bounded terminal hashes). 4. It fills a new header via `BlockHeaderBuilder`. 5. It hands the candidate to the mining loop or dev-mode auto generator. ## Parent and referees * The parent is the best block hash from consensus. * Referees are selected from terminal DAG tips and filtered to exclude the parent. * `choose_correct_parent` may adjust the parent/referees to satisfy consensus rules. ## Header assembly details * `transactions_root` is computed from the packed transactions. * `deferred_state_root`, `deferred_receipts_root`, `deferred_logs_bloom_hash`, and `blame` are pulled from consensus. * `gas_limit` is derived from target gas limit and elasticity multiplier. * `base_price` is computed by the txpool for EIP-1559 style pricing. * `custom` data is set using `Machine::params().custom_prefix()` for fork flags. ## Mining integration * A `ProofOfWorkProblem` is generated from the header's problem hash. * Depending on `MiningType`, the problem is sent to CPU workers or Stratum. * On a solved nonce, `on_mined_block` hands the block to the sync service. ## Key source files * `crates/blockgen/src/lib.rs` * `crates/mazzecore/core/src/consensus/mod.rs` * `crates/mazzecore/core/src/transaction_pool/mod.rs` # PoW and mining Mazze uses a Proof of Work scheme backed by RandomX hashing. Mining produces a nonce that satisfies a difficulty boundary. ## Proof of Work primitives * `ProofOfWorkProblem` bundles the block hash, difficulty, boundary, and seed. * `ProofOfWorkSolution` carries the nonce. * `PowComputer` computes the PoW hash with RandomX using a cached VM. The boundary is derived from difficulty; a block is valid when `pow_hash <= boundary`. ## RandomX cache and seed `PowComputer` uses `RandomXCacheBuilder` to hold RandomX VMs and to swap context when the seed hash changes. This makes per-block hashing fast while still rotating the seed across epochs. ## Difficulty adjustment `target_difficulty` computes the next target from recent blocks, the configured block generation period, and the adjustment epoch period in `ProofOfWorkConfig`. ## Mining modes * `CPU` - local worker threads iterate nonces. * `Stratum` - a job dispatcher hands work to external miners and validates submitted nonces. * `Disable` - mining is turned off (used for read-only nodes or some dev modes). ## Key source files * `crates/mazzecore/core/src/pow/mod.rs` * `crates/mazzecore/core/src/pow/cache.rs` * `crates/blockgen/src/lib.rs` * `crates/blockgen/src/miner/stratum.rs` # DAG and DETS Mazze blocks form a DAG, not a single chain. Each block has a parent edge and zero or more referee edges. The consensus layer treats this as a DAG-Embedded Tree Structure (DETS). ## Graph primitives The `dag` crate defines core traits: * `Graph` - nodes with an index. * `DAG` - predecessor edges and topological order. * `DETS` - tree parent plus referee edges. * `RichDAG` / `RichDETS` - forward edges for traversals. `DETS` is the key abstraction used by sync and consensus. ## Parent and referee edges * Parent edge: ensures a tree backbone and supports chain-like operations. * Referee edges: link side blocks to expand the past set and increase throughput while preserving ordering. ## DAG tips and future sets * Tips are terminal blocks with no children. * `get_future` and `topological_sort` help build ordered subsets of the DAG, especially when computing outlier sets or epoch block ordering. ## Where DETS is implemented * `SynchronizationGraphInner` implements DETS for all received blocks. * `ConsensusGraphInner` implements DETS for validated, ready blocks. ## Key source files * `crates/util/dag/src/lib.rs` * `crates/mazzecore/core/src/sync/synchronization_graph.rs` * `crates/mazzecore/core/src/consensus/consensus_inner/mod.rs` # Consensus Consensus in Mazze is handled by `ConsensusGraph`, which sits on top of the synchronization graph. It maintains the DAG-Embedded Tree Structure (DETS) and implements the Timer Chain WLSR / Mazze ordering algorithm. ## ConsensusGraph responsibilities * Accept ready blocks from the sync graph. * Maintain the DETS view of the DAG. * Compute an ordered sequence of epochs and the best block hash. * Provide mining inputs (best info, terminal hashes, blame/state data). * Dispatch epoch execution tasks. ## DAG/consensus view (mermaid) Solid edges are parent links; dashed edges are referee links. ```mermaid flowchart TB subgraph DAG["DAG (parent + referee edges)"] A[Block A] --> B[Block B] B --> C[Block C] A -.-> D[Block D] B -.-> E[Block E] D --> F[Block F] end subgraph Consensus["Consensus view"] C -->|main chain| M[Epoch N] E -->|outlier set| O[Outliers] M --> T[Timer chain anchor] M --> X[Execution queue] end ``` ## Ordering and weights (Timer Chain WLSR) The ordering algorithm blends two ideas: * Weighted longest chain (WLSR) over the DAG to capture total work. * Timer chain to anchor stable checkpoints. Key parameters are configurable: * `adaptive_weight_beta` and `heavy_block_difficulty_ratio` determine adaptive weighting for heavy blocks. * `timer_chain_block_difficulty_ratio` and `timer_chain_beta` govern timer chain selection. * `era_epoch_count` defines checkpoint spacing. ## Outliers, adaptive blocks, and partial invalidity When a block arrives, consensus computes its outlier set (blocks in the future of its parent view) and derives an adaptive weight. Blocks that choose an incorrect parent or carry an incorrect adaptive flag are marked partial invalid. Partial invalid blocks remain in the DAG but are excluded from rewards and ordering. ## Epochs and eras * An epoch is the ordered block set associated with a main-chain block. * An era is a contiguous range of epochs used for checkpointing and pruning. * `cur_era_genesis` and `cur_era_stable_height` define the active era window. Consensus dispatches execution by epochs, and execution is deferred to reduce reorg churn. ## Checkpoints and timer chain The timer chain provides a stable anchor for era checkpoints. When a candidate checkpoint is selected, the graph is trimmed to a new era while ensuring that no timer-chain block sits in the outlier of the new genesis. ## Confirmation and mining readiness `ConfirmationMeter` tracks confirmation depth for main-chain blocks. Once the node enters the normal phase and the consensus graph is stable, the `ready_for_mining` flag enables block generation. ## Key source files * `crates/mazzecore/core/src/consensus/mod.rs` * `crates/mazzecore/core/src/consensus/consensus_inner/mod.rs` * `crates/mazzecore/core/src/consensus/consensus_inner/consensus_new_block_handler.rs` # Execution and state Mazze executes transactions in epochs. Execution is deferred by a fixed number of epochs to limit reorg churn and to align with the DAG ordering. ## ConsensusExecutor `ConsensusExecutor` owns a worker thread that processes `EpochExecutionTask` items. Each task includes: * The epoch hash and ordered block list. * The start block number for VM `Env`. * Optional reward execution info. * A flag indicating whether the epoch is on the local main chain. ## Execution pipeline 1. Prefetch accounts and storage for the epoch. 2. Initialize epoch context and set base/burnt gas prices. 3. For each block: * Build the VM `Env` (chain id, block number, gas limit, base price). * Execute each transaction with `ExecutiveContext::transact`. * Record receipts, logs, and traces. 4. Produce `EpochExecutionCommitment` containing: * `StateRootWithAuxInfo` (snapshot and intermediate epoch ids). * Receipts root and logs bloom root. If the epoch is on the local main chain, transactions that were packed but not executed are recycled back into the txpool. ## Deferred roots and blame The execution output is stored in the block data manager and reflected into later headers as deferred roots. The `blame` field allows light clients to decide which deferred roots are trustworthy. ## State availability boundary `StateAvailabilityBoundary` tracks the height range where state is available. Archive nodes keep full history; full nodes may limit availability based on snapshots and checkpoints. ## Key source files * `crates/mazzecore/core/src/consensus/consensus_inner/consensus_executor/mod.rs` * `crates/mazzecore/core/src/consensus/consensus_inner/consensus_executor/epoch_execution.rs` * `crates/mazzecore/internal_common/src/state_root_with_aux_info.rs` * `crates/mazzecore/internal_common/src/state_availability_boundary.rs` # Verification Verification rules ensure that incoming blocks and transactions are valid before they enter consensus. ## Header validation `verify_header_params` checks: * Custom data length and custom prefix for fork markers. * Presence of `base_price`. * Proof of Work validity (unless in catch-up mode or seed unknown). * Referee count bound and duplicate parent/referee hashes. * Basic timestamp validity (when enabled). ## Block integrity * Transactions root is re-computed via MPT and compared to the header. * Block size is checked against `max_block_size_in_bytes`. ## Transaction validation * Signature and encoding checks. * Gas, storage, and epoch height bounds. * Chain id and space-specific rules. ## Base fee and gas checks `verify_sync_graph_ready_block` verifies that: * Packed gas does not exceed per-space limits. * Base price is correctly derived from parent and gas usage. ## Inclusion proofs The verification module exposes helpers to compute and verify: * Transaction inclusion proofs. * Block receipt proofs. * Epoch receipt proofs. These are used by RPCs and light client workflows. ## Key source files * `crates/mazzecore/core/src/verification.rs` * `crates/primitives/src/block_header.rs` * `crates/dbs/storage/src/impls/merkle_patricia_trie/trie_proof.rs` # Storage and snapshots State persistence is provided by the `mazze-storage` crate. It combines a Merkle Patricia Trie (MPT) with snapshotting and delta layers to balance performance and history retention. ## Storage layers * Delta MPTs: append-only changes between snapshots. * Snapshot MPTs: compact state snapshots at selected epochs. * State DB backend: MDBX by default, configurable via `MdbxConfig`. ## StorageManager and state access `StorageManager` and `StateManager` provide: * Read/write access to the current state. * Snapshot creation and pruning. * Proof generation and state sync support. ## Snapshot policy `StorageConfiguration` controls: * `snapshot_epoch_count` and `era_epoch_count`. * Extra snapshots for sync (`ProvideExtraSnapshotSyncConfig`). * Cache sizes and open snapshot limits. * Directory layout under `storage_db/`. ## Interaction with consensus `BlockDataManager` keeps a `StateAvailabilityBoundary` describing which epoch states can be read. This allows full nodes to prune old state while still serving recent queries. ## Key source files * `crates/dbs/storage/src/lib.rs` * `crates/dbs/storage/src/state_manager.rs` * `crates/dbs/storage/src/impls/storage_manager/snapshot_manager.rs` * `crates/dbs/storage/src/impls/merkle_patricia_trie/mod.rs` * `crates/mazzecore/core/src/block_data_manager/mod.rs` # Synchronization Synchronization brings the local node in sync with the network and feeds ready blocks into consensus. ## Phases Archive and full nodes follow a fixed phase pipeline: 1. CatchUpRecoverBlockHeaderFromDB 2. CatchUpSyncBlockHeader 3. CatchUpCheckpoint 4. CatchUpFillBlockBodyPhase 5. CatchUpSyncBlock 6. Normal Each phase drives specific network requests and graph updates. ## SynchronizationGraph The sync graph stores all received headers and blocks and tracks their status: * Header-only, graph-ready, block-ready. * Parent and referee connectivity. * Frontiers for not-ready blocks and old-era blocks. Only blocks that are graph-ready and have full bodies are delivered to consensus. ## State sync Snapshot-based state sync uses: * Snapshot manifest requests. * Chunk requests/responses. * Candidate selection and restoration helpers. ## Key source files * `crates/mazzecore/core/src/sync/synchronization_phases.rs` * `crates/mazzecore/core/src/sync/synchronization_graph.rs` * `crates/mazzecore/core/src/sync/message/mod.rs` * `crates/mazzecore/core/src/sync/state/mod.rs` # Networking The `network` crate implements the P2P transport, discovery, and peer management used by sync and block propagation. ## Core services * `NetworkService` manages sessions and protocol handlers. * Discovery maintains a node table and periodically refreshes peers. * Handshake and session layers enforce protocol compatibility. ## Configuration highlights `NetworkConfiguration` includes: * Listen/public addresses and UDP port. * Bootnodes and reserved nodes. * Peer limits and handshake limits. * NAT and discovery settings. * Throttling and IP filter controls. ## Node typing and tagging Peers advertise `node_type` tags (archive/full) to bias requests during sync, and the sync layer can choose preferred node types for block retrieval. ## Key source files * `crates/network/src/lib.rs` * `crates/network/src/service.rs` * `crates/network/src/discovery.rs` * `crates/mazzecore/core/src/sync/message/status.rs` # RPC and APIs Mazze exposes a JSON-RPC interface over HTTP, WebSocket, and TCP. Handlers are implemented in the `client` crate and call into consensus and storage. ## Namespaces * `mazze_*` - core chain queries, blocks, receipts, balances, logs, and DAG tips. * `debug_*` - execution tracing and diagnostics. * `trace_*` - transaction and block traces. * `txpool_*` - pending pool status and contents. ## Query path Most RPCs resolve through: * `ConsensusGraph` for chain/epoch context. * `BlockDataManager` for headers, receipts, and rewards. * State DB for balances, storage, and contract code. ## Configuration RPC ports and limits are configured in `client/src/configuration.rs`, including HTTP/WS/TCP ports, thread counts, and max payload sizes. ## Key source files * `crates/client/src/rpc/impls/mazze/mazze_handler.rs` * `crates/client/src/rpc/impls/mazze/common.rs` * `crates/client/src/rpc/traits/mazze_space/mazze.rs` * `crates/client/src/configuration.rs` # Genesis and params Genesis bootstraps chain state, internal contracts, and initial balances. ## Genesis block creation `genesis_block` performs: * State initialization and internal contract setup. * Funding of configured genesis accounts (including dev/test keys when used). * Genesis treasury account creation and shielded pool seeding. * Emission of genesis transactions (create2 factory, optional shielded key). * Construction of the genesis header with initial difficulty and gas limit. ## Explicit genesis issuance logic Current native genesis target is 3,900,000,000 MAZZE. In code, genesis accounting is two-step: 1. Credit explicit genesis accounts first. 2. Mint only the remaining amount needed to reach the configured genesis total. This avoids double-counting between explicit allocations and the special genesis-account mint path. Shielded pool bootstrap at genesis is a treasury transfer, not extra issuance. See `../tokenomics/shielded-pool-genesis-fund.md`. ## Genesis inputs * `genesis_accounts` and `genesis_secrets` can override the account set. * `execute_genesis` controls whether genesis is executed or loaded from db. ## Chain parameters Configuration exposes key consensus parameters: * `initial_difficulty` * `era_epoch_count` * `referee_bound` * `adaptive_weight_beta`, `heavy_block_difficulty_ratio` * `timer_chain_block_difficulty_ratio`, `timer_chain_beta` * `transaction_epoch_bound` Hardfork transitions are also configured by height/epoch. ## Key source files * `crates/mazzecore/core/src/genesis_block.rs` * `crates/client/src/configuration.rs` * `crates/mazzecore/internal_common/src/chain_id.rs` * `crates/mazzecore/parameters/src/lib.rs` # Rewards and fees Rewards are computed per epoch and distributed to block authors. ## Reward components * Base reward from the block-height halving schedule. * Outlier penalty reduction for outlier blocks. * Transaction fees distributed to packing authors. * Burned fees removed from issued supply accounting. Blocks marked partial invalid receive no reward. ## Explicit net issuance logic At reward settlement, native supply is adjusted by net mint: `net_issuance_epoch = total_base_reward_epoch - burnt_fee_epoch` * If positive, `total_issued` increases by that delta. * If negative, `total_issued` decreases by the absolute delta. This is why supply can be deflationary in epochs where burn exceeds mint. ## Fee and burn model Mazze tracks burned fee paths during execution and in global stats: * MIP-1559 burn is recorded and subtracted from issued supply. * Additional burn paths (for example contract-balance burn on specific destruction flows) also reduce issued supply. ## Reward execution flow 1. Consensus determines reward epoch and block set. 2. `ConsensusExecutor` gathers reward execution inputs. 3. `process_rewards_and_fees` computes per-block rewards and fees. 4. Burn and mint are netted into issued-supply accounting. 5. Results are persisted in `BlockDataManager`. ## Key source files * `crates/mazzecore/core/src/consensus/consensus_inner/consensus_executor/mod.rs` * `crates/mazzecore/core/src/consensus/consensus_inner/consensus_executor/epoch_execution.rs` * `crates/mazzecore/executor/src/state/state_object/reward.rs` * `crates/client/src/rpc/impls/mazze/mazze_handler.rs` # Node types and light protocol Mazze supports multiple node types that trade storage for sync cost. ## Node types * `Archive` - keeps full historical state and receipts. * `Full` - keeps recent state and snapshots, prunes older history. * `Light` - relies on witnesses/blame verification and remote state proofs. The node type is encoded on the wire and affects sync preferences. ## Light protocol The light protocol provides: * Block/receipt proofs and witnesses for light clients. * Peer type validation to avoid incompatible requests. Light nodes are more conservative about which peers they accept and what data they trust, using the `blame` field and witness checks. ## Key source files * `crates/mazzecore/core/src/node_type.rs` * `crates/mazzecore/core/src/light_protocol/handler/mod.rs` * `crates/mazzecore/core/src/light_protocol/provider.rs` * `crates/mazzecore/core/src/consensus/consensus_inner/blame_verifier.rs` # Privacy Mazze implements privacy through a shielded pool internal contract and a zero-knowledge proof flow built into native transactions. ## Pages * [Overview](/privacy/overview) * [Shielded pool contract](/privacy/shielded-pool) * [Shielded transactions](/privacy/transactions) * [Keys and tooling](/privacy/keys-and-tooling) For CLI and RPC walkthroughs, use your local shielded-transactions runbook. # Overview Mazze privacy is implemented as a shielded pool that accepts deposits and shielded spends. The pool is an internal contract that verifies Groth16 proofs and maintains a Poseidon Merkle tree of commitments. ## High-level flow 1. Shield (deposit): A public transfer calls `shield(bytes32,bytes)` with a commitment and ciphertext. The pool appends the commitment to its Merkle tree, stores a new root, and emits a log with the commitment and ciphertext. 2. Spend (shielded bundle): A shielded transaction calls `applyShieldedBundle(...)` with an anchor (root), nullifiers, new commitments/ciphertexts, optional transparent outputs/values, and a fee. The pool verifies the Groth16 proof, marks nullifiers as spent, updates the Merkle tree, and transfers any transparent outputs and fees from the pool. ## Cryptography in the implementation * Groth16 over BLS12-381 is used for proof verification in the pool contract. * Poseidon is used for commitment hashing and Merkle tree construction. * The Merkle tree depth is 32, and the pool keeps a history of 64 roots for anchor selection. ## What is public on chain * Commitments and ciphertexts are logged as `ShieldedNote` events. * Nullifiers are stored to prevent double spends. * Merkle roots are stored and exposed via `root()`. * Transparent outputs and their values are public inputs in the proof. # Shielded pool contract The shielded pool is an internal contract (built-in) that holds shielded balances and verifies proof-based spends. ## Address * `SHIELDED_POOL_CONTRACT_ADDRESS` in `crates/mazzecore/parameters/src/internal_contract_addresses.rs` ## Public functions * `shield(bytes32,bytes)` * Accepts a commitment and ciphertext with a non-zero value transfer. * Appends the commitment to the Poseidon Merkle tree. * Emits a `ShieldedNote(bytes32,bytes)` event. * `applyShieldedBundle(...)` * Verifies a Groth16 proof against the anchor, nullifiers, commitments, outputs, values, and fee. * Marks nullifiers as spent. * Appends new commitments and emits `ShieldedNote` events. * Pays the fee and transparent outputs from the pool balance. * `root()` * Returns the latest Merkle root. * `isNullifierSpent(bytes32)` * Returns whether a nullifier has been spent. * `setVerifyingKey(bytes)` * Sets the Groth16 verifying key once (admin only). * `verifyingKeyHash()` * Returns the keccak hash of the verifying key. ## Limits and parameters * Tree depth: 32 levels. * Root history: 64 roots. * Max nullifiers per bundle: 8. * Max commitments per bundle: 8. * Max transparent outputs per bundle: 8. * Max ciphertext size: 512 bytes. * Max proof size: 256 bytes. * Max verifying key size: 8192 bytes. ## Storage layout (system storage) The pool stores its state in system storage keyed by hashed prefixes: * `shielded:vk_len`, `shielded:vk_word:*`, `shielded:vk_hash` * `shielded:nullifier:*` * `shielded:root_index`, `shielded:root:*` * `shielded:leaf_index`, `shielded:frontier:*` ## Genesis behavior If a verifying key is provided at genesis, a `setVerifyingKey` transaction is executed and the shielded pool admin is cleared. Genesis can also seed shielded pool balance using `SHIELDED_POOL_GENESIS_FUND_MAZZE`. That seed is transferred from treasury (not newly minted). See `../tokenomics/shielded-pool-genesis-fund.md`. # Shielded transactions Shielded transfers are encoded as native transactions with a special payload that targets the shielded pool contract. ## Transaction type * Shielded transactions are represented as `TypedNativeTransaction::Shielded`. * The payload (`data`) contains the encoded shielded proof and bundle inputs. ## Validation rules The verifier enforces these constraints for shielded transactions: * The transaction must be unsigned. * The action must be `Call` to the shielded pool address. * `value` must be zero (transfers happen inside the pool). * `gas_price` must be zero (the proof includes a fee field). * The payload must not be empty. The RPC call request builder also enforces recipient, value, and payload checks before building a shielded transaction. ## Sender derivation Shielded transactions are unsigned. The node derives a synthetic sender address from the transaction hash (`SignedTransaction::new_shielded`). ## Transaction pool behavior * Shielded transactions are stored in a dedicated `shielded_pool` map (no nonce ordering). * The packer selects shielded transactions after packing normal native and EVM transactions, respecting remaining gas and block size limits. # Keys and tooling ## Verifying key lifecycle The shielded pool verifies Groth16 proofs using a verifying key stored on chain. * `setVerifyingKey(bytes)` stores the verifying key in system storage and exposes its hash via `verifyingKeyHash()`. * The key is cached as a prepared verifying key to speed up proof checks. At genesis, the node can load a verifying key from disk and execute a `setVerifyingKey` transaction. The loader looks for: * `run/shielded_vk.hex` * `shielded_vk.hex` If a key is set at genesis, the shielded pool admin is cleared so the key can no longer be changed. ## Genesis pool seeding Genesis optionally seeds the shielded pool balance from the treasury using `SHIELDED_POOL_GENESIS_FUND_MAZZE`. ## CLI utilities The executor crate includes helper binaries for the shielded flow: * `shielded_keygen` - generate proving/verifying keys. * `shielded_vkhash` - compute a verifying key hash. * `shielded_verify` - verify a proof payload against a verifying key. * `shielded_note` - build/decrypt notes and derive Merkle paths. * `shielded_bundle` - build shielded bundles and proofs. ## Operational docs Step-by-step CLI and RPC usage should follow your local shielded-transactions runbook. # Overview As a developer in the Mazze ecosystem, you're at the forefront of blockchain innovation. You have the opportunity to: * **Create Decentralized Applications (DApps) |** Mazze's robust platform is tailored for a diverse range of sectors, including finance, healthcare, and education. It supports the creation and proliferation of DApps, offering unprecedented levels of efficiency, security, and user control. * **Leverage Advanced Cryptography |** Utilize cutting-edge cryptographic techniques and innovative consensus mechanisms for optimizing transaction speed and reliability. * **Enhance Scalability and Network Resilience |** Benefit from Mazze’s layered architecture, sharding techniques, and efficient data structures. **Tools and Resources.** This section provides an array of resources: * **Technical Documentation |** Detailed guides on Mazze's architecture, consensus mechanisms, and smart contract development. * **APIs and SDKs |** Access to Mazze’s APIs and Software Development Kits for seamless integration and development. * **Community Support |** Connect with other developers and the Mazze team for collaboration and support. **Getting Started.** Jump into building on Mazze: 1. **Explore the Documentation |** Familiarize yourself with the Mazze blockchain’s capabilities. 2. **Set Up Your Environment |** Utilize our guides to set up your development environment. 3. **Start Building |** Use our tools and resources to start creating innovative solutions on the Mazze blockchain. **Join the Revolution** Be a part of the next generation of blockchain developers. Build on Mazze for a more efficient, secure, and scalable blockchain experience.
# Project GitHub GitHub is a vital platform for software development, serving as a central hub where developers and teams collaborate on code. It's the foundation of open-source projects worldwide, including the Mazze project. On GitHub, you'll find the actual codebase of Mazze, witnessing the ongoing development and evolution of our blockchain technology. {% embed url="" %} # EVM Compatibility ### Ethereum Virtual Machine (EVM) Overview The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts in Ethereum. It is a powerful, sandboxed virtual stack embedded within each full Ethereum node, responsible for executing contract bytecode. Contracts written in high-level languages (like Solidity) are compiled into EVM bytecode. **Importance of EVM Compatibility for Layer 1 Blockchains** | EVM compatibility allows Layer 1 blockchains like Mazze to leverage Ethereum's established ecosystem, enabling developers to use familiar tools and languages. This compatibility facilitates easier migration of DApps and smart contracts from Ethereum to Mazze, broadening the potential user and developer base. ### Mazze Blockchain Architecture Mazze combines Proof of Work (PoW) and Directed Acyclic Graph (DAG) technologies. This unique architecture requires specialized adaptations to ensure EVM compatibility. ### Smart Contracts on Mazze Benefits of EVM Compatibility: * **Enhanced Interoperability** | Seamless interaction with Ethereum-based protocols and assets. * **Developer Familiarity** | Utilize existing Ethereum development tools and languages. * **Broader Adoption** | Attracts a wider community of developers and users familiar with Ethereum. **Comparison with Non-EVM Layer 1 Blockchains** | Non-EVM chains often face challenges in attracting Ethereum developers due to the need for learning new languages and tools. Mazze, being EVM-compatible, removes this barrier. ### Future Developments Potential Enhancements: * Further optimization of EVM integration for better performance. * Expanding the range of Ethereum-compatible tools and libraries available for Mazze. **Influence on the Blockchain Ecosystem** | The continuous improvement in EVM compatibility on Mazze is expected to set a benchmark in the blockchain space, influencing other projects to adopt similar approaches for interoperability and developer engagement. *** ## Challenges and Solutions ### Integration Challenges: 1. **Adapting EVM to Mazze's PoW and DAG Structure** | The planned integration of the Ethereum Virtual Machine (EVM) into Mazze's innovative blend of Proof of Work (PoW) and Directed Acyclic Graph (DAG) architectures is anticipated to present significant challenges. The complexity primarily stems from reconciling the linear, sequential nature of traditional EVM-based blockchains with the concurrent transaction processing capabilities of Mazze's DAG structure. A key future focus will be ensuring that EVM's state transition and contract execution model, originally designed for linear blockchains, will be effectively and efficiently functional within a DAG framework. 2. **Ensuring Network Security and Performance** | As we proceed with integrating the EVM, paramount importance will be placed on maintaining the network's security and performance. Key future concerns include preventing the introduction of EVM from opening new vectors for attacks, especially considering Mazze's unique consensus mechanism. Moreover, it is crucial that the integration does not significantly compromise the network's high throughput and scalable architecture, which are among Mazze's primary value propositions. ### Planned Solutions: 1. **Custom-Built Modules for EVM-Mazze Integration** | To tackle these upcoming challenges, our development team plans to engineer a series of custom-built modules. These will serve as an interface layer between the EVM and Mazze's underlying architecture, performing several critical functions: * **Transaction Mapping and Ordering** | A specialized module will be developed for converting the DAG-based transaction structure into a format compatible with EVM's linear execution model. This will involve dynamically ordering transactions to respect the causal relationships of the DAG, while ensuring consistent and deterministic state transitions in the EVM. * **State Management Optimization** | Considering the concurrent nature of DAG, we plan to implement an advanced state management system. This system will isolate the execution environment of each smart contract, preventing state conflicts or inconsistencies during concurrent executions. This will be achieved through a blend of lock-free data structures and optimized concurrency control algorithms. * **Consensus Bridging** | A crucial module will act as a liaison between Mazze's PoW-DAG consensus mechanism and the EVM. It will be designed to make the EVM aware of the consensus state and enable correct processing of transactions following Mazze's network rules. 2. **Continuous Optimization for High Throughput and Security** | The EVM integration into Mazze will be an ongoing process of optimization and enhancement. This will include: * **Performance Benchmarking** | We plan regular benchmarking of the network to monitor the impact of EVM integration on throughput and latency. This will aid in identifying performance bottlenecks and in optimizing both the EVM and Mazze's underlying architecture. * **Security Audits** | We will conduct regular and comprehensive security audits to identify and address potential vulnerabilities that might arise from the EVM integration. This will encompass both static codebase analysis and dynamic testing under various network scenarios. * **Community-Driven Development** | We will leverage the open-source community for testing, feedback, and contributions, enabling a broad exploration of use cases and scenarios. This approach is aimed at ensuring a robust and well-tested EVM integration process. # Smart contracts ### What is a Smart Contract? A "smart contract" is a program operating on the Mazze blockchain, an EVM-compatible platform. It consists of both code (its functions) and data (its state), housed at a unique address on the Mazze blockchain. Smart contracts function as a type of Mazze blockchain account, possessing a balance and capable of receiving transactions. Unlike user-controlled accounts, smart contracts are automatically executed by the network once deployed. Users can interact with these contracts through transactions that trigger specific functions within the contract. Smart contracts establish and autonomously enforce rules, akin to traditional contracts, but through their code. Once deployed, smart contracts are typically immutable and interactions with them are permanent. ### Permissionless Deployment On the Mazze blockchain, anyone can create and deploy a smart contract, provided they have the necessary coding skills in a smart contract language and sufficient native blockchain tokens (similar to ETH) for deployment. Deploying a smart contract, a form of transaction, requires payment of network fees ("gas"), with contract deployment generally incurring higher gas costs than standard transactions. The Mazze blockchain supports user-friendly programming languages for smart contract development, such as Solidity. These contracts must be compiled for the Mazze blockchain's virtual machine to interpret and store them. ### Limitations Smart contracts inherently lack the ability to access real-world information directly, as they cannot pull data from external sources. This is intentional, as external data reliance could compromise the network's consensus, crucial for its security and decentralization. To integrate real-world data, blockchain applications use oracles, tools that provide external data to smart contracts. Another constraint is the maximum contract size. On the Mazze blockchain, a smart contract can be up to 24KB; exceeding this limit results in gas exhaustion. Developers can circumvent this limitation by employing methods like [The Diamond Pattern](https://eips.ethereum.org/EIPS/eip-2535). ### Multisig Contracts Multisig (multiple-signature) contracts on the Mazze blockchain require several authentic signatures for transaction execution. They offer a safeguard against single failure points, especially for contracts managing significant token amounts. Multisig contracts distribute contract management and key holding responsibilities, preventing catastrophic losses from a single key compromise. They are also useful for simple DAO governance structures. A multisig contract might require, for example, 3 out of 5 or 4 out of 7 valid signatures (N ≤ M, M > 1) for execution. In a 4/7 multisig setup, four out of seven possible valid signatures are needed, ensuring fund retrievability even if three signatures are lost and mandating majority agreement for contract execution. # Solidity Solidity is a premier programming language for smart contract development, drawing influences from C++, Python, and JavaScript. It is a statically typed, object-oriented language, tailored for the Mazze blockchain, an EVM (Ethereum Virtual Machine) compatible platform. Solidity's design aims for ease of adoption by programmers versed in modern programming languages. ### Key Elements of Solidity on Mazze Blockchain 1. **Pragma Directive** | Every Solidity file on Mazze blockchain begins with a pragma directive, specifying compatibility with Solidity version 0.4.0 or later. This directive is file-specific, meaning imported files' pragmas don't automatically apply to the importing file. Example: `Pragma solidity ^0.8.2` 2. **Contracts** | In Solidity, contracts resemble C++ classes and live at specific addresses on the Mazze blockchain. They encapsulate code and data, with properties including: * Constructors: Special functions for contract initiation, executed once per contract upon creation. * State Variables: These variables store the contract's state. * Functions: Used to modify state variables and hence the contract's state. 3. **Visibility Quantifiers** | Functions and state variables in a contract have varying visibility, facilitating interactions between contracts. * `external`: Functions callable only by other contracts, not internally. Use `this.function_name()` for internal calls. State variables can't be external. * `public`: Accessible both externally and internally. Public state variables automatically generate getter functions. * `internal`: Only for internal or derived contract use. * `private`: Restricted to internal use, inaccessible to derived contracts. 4. **Data Types** | Solidity supports various data types including Booleans, Integers (int/uint), Addresses (standard and payable for Ether transactions), and String Literals. 5. **Mapping** | A key-value pair storage mechanism, supporting built-in data types like arrays, enums, and operators. Useful for associating values with specific storage locations. 6. **Gas** | A metric indicating the computational effort required for operations on the Mazze blockchain. Each function, operation, or state change in a smart contract incurs a Gas cost. 7. **ABI** | The Application Binary Interface in Solidity functions akin to a web API, defining methods and structures for binary contract interactions. ### Solidity Contract Development on Mazze Blockchain * **Testing and Deployment** | Smart contracts, once deployed, are immutable. Therefore, rigorous testing for bugs and vulnerabilities is crucial. The Hardhat development framework is highly recommended for Solidity development on Mazze, offering ease in compiling, testing, and deploying contracts. It's compatible with major JavaScript APIs like Ether.js and Web3.js. * **Front End and Web3 Development** | Post contract development, constructing a user-friendly interface is vital for dApp interaction. Web3.js and Ether.js are top libraries for front-end development, simplifying tasks like Ether transactions, smart contract interactions, and more. # Developing Smart Contracts To begin working with Mazze blockchain, which is compatible with the Ethereum Virtual Machine (EVM), you'll first need to install Hardhat in your project directory. Execute the following command to install Hardhat: ```bash npm install --save-dev hardhat ``` After installation, initiate Hardhat by running `npx hardhat`. This action will generate a Hardhat configuration file (`hardhat.config.js`) in your project directory: ```bash npx hardhat ``` You'll be greeted by the Hardhat interface: ``` npx hardhat Welcome to Hardhat v2.2.1 ✔ What do you want to do? · Create an empty hardhat.config.js Config file created ``` The next step is to create your first smart contract. In the `contracts` directory, store your Solidity source files (.sol). Let's start with a basic contract named `Box`, which allows storing and retrieving a value. Create the contract in the file `contracts/Box.sol`: ```solidity // contracts/Box.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract Box { uint256 private _value; // Emitted when the stored value changes event ValueChanged(uint256 value); // Stores a new value in the contract function store(uint256 value) public { _value = value; emit ValueChanged(value); } // Reads the last stored value function retrieve() public view returns (uint256) { return _value; } } ``` For compiling Solidity code to EVM bytecode, configure Hardhat to use a suitable Solidity compiler version, matching your contract's requirements. In `hardhat.config.js`, specify Solidity 0.8 for our `Box.sol` contract: ```solidity // hardhat.config.js /** * @type import('hardhat/config').HardhatUserConfig */ module.exports = { solidity: "0.8.4", }; ``` To compile, run: ```bash npx hardhat compile ``` Hardhat will compile all contracts in the `contracts` directory. The compiled artifacts (bytecode and metadata) will be stored in the `artifacts` directory. As your project expands, you might create more contracts. For instance, let's add an access control system to our `Box` contract. We'll create an `Auth` contract that stores an administrator address. This contract will be placed in a subdirectory, like `contracts/access-control/Auth.sol`. ```solidity // contracts/access-control/Auth.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract Auth { address private _administrator; constructor(address deployer) { // Make the deployer of the contract the administrator _administrator = deployer; } function isAdministrator(address user) public view returns (bool) { return user == _administrator; } } ``` To integrate `Auth` with `Box`, use an import statement in `Box.sol`: ```solidity // contracts/Box.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; // Import Auth from the access-control subdirectory import "./access-control/Auth.sol"; contract Box { uint256 private _value; Auth private _auth; event ValueChanged(uint256 value); constructor() { _auth = new Auth(msg.sender); } function store(uint256 value) public { // Require that the caller is registered as an administrator in Auth require(_auth.isAdministrator(msg.sender), "Unauthorized"); _value = value; emit ValueChanged(value); } function retrieve() public view returns (uint256) { return _value; } } ``` For advanced modularization, consider using inheritance in Solidity. A great resource for reusable modules and libraries is the OpenZeppelin Contracts library. It's thoroughly audited for security and correctness. To use OpenZeppelin Contracts, install the library: ```bash npm install @openzeppelin/contracts ``` Then, import the necessary contracts from OpenZeppelin. For example, to add access control to `Box`, replace the `Auth` contract with `Ownable` from OpenZeppelin: ```solidity // contracts/Box.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; // Import Ownable from the OpenZeppelin Contracts library import "@openzeppelin/contracts/access/Ownable.sol"; // Make Box inherit from the Ownable contract contract Box is Ownable { uint256 private _value; event ValueChanged(uint256 value); constuctor() Ownable(msg.sender) {} // The onlyOwner modifier restricts who can call the store function function store(uint256 value) public onlyOwner { _value = value; emit ValueChanged(value); } function retrieve() public view returns (uint256) { return _value; } } ``` For more information on developing secure smart contract systems, refer to the [OpenZeppelin Contracts documentation](https://docs.openzeppelin.com/contracts/5.x/), including their [Access Control guide](https://docs.openzeppelin.com/contracts/5.x/access-control). # Introduction to Mazze Testnet This section is now focused on **real operational testing** of Mazze node, CLI, RPC, and mining workflows. ### What changed Older testnet pages contained early-phase assumptions and fixed values that are no longer reliable. The canonical testnet operational docs are now: * [Mazze Node & Miner Setup Guide](/testnet/setup-guide) * [Mazze CLI](/testnet/mazze-cli) * [Mazze Mining Guide](/testnet/mining) * [Mazze JSON-RPC Guide](/testnet/rpc) * [Viewing Mazze Logs](/testnet/viewing-logs) ### Current network cadence note For this documentation set, the current operational target is **4 BPS**. ### Scope Use this testnet section for: * Running and validating node/miner infrastructure * Wallet and transfer workflows via CLI * RPC-based integration tests * Mining mode validation (`stratum`, `cpu`, `disable`) # Setup Guide This guide describes two methods for setting up a Mazze node and miner: using Docker (recommended) or building from source. For the Zurich development phase, we recommend using Docker. For reading logs, see our [Viewing Mazze Logs](/testnet/viewing-logs) guide. For CLI usage, RPC details, and mining operations, see [Mazze CLI](/testnet/mazze-cli), [RPC Guide](/testnet/rpc), and [Mining Guide](/testnet/mining). ## 1. Docker Setup ### 1.1 Compose-based Setup (Recommended) The repository includes a ready-to-use `docker-compose.yml`. To run Mazze: 1. Edit `run/hydra.toml`: * Set `public_address = ""` (or leave empty to auto-detect). * Set `mining_author = ""` (or leave empty to disable mining on the node). * Ensure `log_conf = "/app/config/log.yaml"` is present (already set in this repo). 2. Optional: edit `run/log.yaml` for logging format/level. It is mounted into the container at `/app/config/log.yaml` and has `refresh_rate: 30 seconds`. 3. Start the services: ```bash sudo docker compose up -d ``` To roll out a freshly published image tag, pull and recreate: ```bash # Optional if using non-default tag suffixes: # export MAZZE_IMAGE_TAG= sudo docker compose pull sudo docker compose up -d --force-recreate ``` Verify the deployed image revision: ```bash sudo docker compose exec node cat /app/REVISION sudo docker compose exec miner cat /app/REVISION ``` 4. View logs: ```bash sudo docker compose logs node | tail -n 200 sudo docker compose logs miner | tail -n 200 ``` 5. Retrieve your node ID (after node starts): ```bash sudo docker compose logs node | grep "Self node id:" | tail -n 1 ``` 6. Apply config changes: ```bash sudo docker compose up -d --force-recreate ``` 7. Stop services: ```bash sudo docker compose down ``` Notes: * Logs are written under `./logs/node` and `./logs/miner` on the host. * For persistent chain data on the host, you can add a volume to `docker-compose.yml`, for example: * `- ./blockchain_data:/app/blockchain_data` ### 1.2 Manual Docker Run (Optional) If you prefer `docker run`, ensure ports are open and set the same mounts as in the compose file. Compose is recommended for simplicity. ## 2. Building from Source For developers who want to build from source: 1. Clone the repository: ```bash git clone https://github.com/MazzeLabs/mazze-rust-release.git cd mazze-rust-release ``` 2. Install dependencies: ```bash sudo apt-get update sudo apt-get install build-essential pkg-config libssl-dev cmake hwloc libhwloc-dev libudev-dev # Install Rust: https://www.rust-lang.org/tools/install curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` 3. Build the project: ```bash cargo build --release ``` 4. Configure the node: * Edit `run/hydra.toml` * Set your VM's IP address * Configure your mining author address 5. Start the node and miner: ```bash ./start-node.sh ./start-miner.sh ``` ## 3. Dev Mode (Local) Use dev mode for local testing (fast blocks, local RPC, shielded testing). 1. (Optional) Re-genesis with shielded keys (wipes dev chain data): ```bash ./run/regenesis-shielded.sh --dev ``` 2. Build the dev node binary: ```bash cargo build -p mazze ``` 3. Start the dev node: ```bash ./run/start-node-dev.sh ``` 4. If blocks are not advancing, build and start the miner: ```bash cargo build --release -p mazze-miner ./run/start-miner.sh ``` 5. Open the CLI: ```bash ./run/mazze-cli.sh ``` Logs: * Dev node: `run/logs/mazze-node-dev.log` * Miner: `run/logs/mazze-miner.log` Stop everything: ```bash ./run/stop.sh ``` Dev data directory: * `run/blockchain_data_dev` ## Important Notes Changing log level / config: * Edit `run/hydra.toml` (`log_level = "info" | "debug" | "warn" | "error"`) or adjust `run/log.yaml`. * Then recreate containers: ```bash sudo docker compose up -d --force-recreate ``` Container logging options are handled by Docker; compose already mounts `run/log.yaml` as `/app/config/log.yaml` with a refresh rate, so updates apply without rebuilding images. ## Additional Notes * Ensure Docker is installed and running on your system * The automated setup creates a `node_id.txt` file containing your node's identifier * Monitor the logs directory for debugging information * For security reasons, consider configuring additional firewall rules * Backup your mining author address securely ## Soak Testing For high-BPS soak runs and metrics-based GC/DB tuning, use the dedicated internal soak-testing runbook for your environment. # Mazze CLI The Mazze CLI (`run/mazze-cli.sh`) is a lightweight wrapper around JSON-RPC for wallet management, transfers, and shielded pool workflows. You can run it as a one-shot command or in an interactive shell. ## Prerequisites * A running node with HTTP RPC enabled. * For local usage, set `jsonrpc_local_http_port` in `run/hydra.toml`, or use `run/start-node-dev.sh` which enables it automatically. * Alternatively, point the CLI at a remote RPC with `RPC_URL`. * Rust is required for the CLI to auto-build helper binaries (`mazzekey`, `shielded_note`, and the `addrconv` helper for base32/hex conversion). ## Quick start ```bash ./run/mazze-cli.sh status ./run/mazze-cli.sh wallet new alice ./run/mazze-cli.sh wallet balance --name alice ``` Run without arguments to enter interactive mode: ```bash ./run/mazze-cli.sh mazze> help ``` ## Environment variables * `RPC_URL`: HTTP RPC endpoint (default: `http://127.0.0.1:12539`). * `MAZZE_NETWORK_ID`: Network id used for address encoding (default: `1990`). * `MAZZE_DECIMALS`: Token decimals for formatting (default: `18`). * `MAZZE_HOME`: CLI data directory (default: `~/.mazze`). * `MAZZE_CLI_DASH`: Enable dashboard in interactive mode (default: `1`). * `MAZZE_CLI_DASH_REFRESH`: Dashboard refresh interval in seconds (default: `2`). * `MAZZE_CLI_COLOR`: Force color on/off (default: `1`, or `0` if `NO_COLOR`). * `MAZZE_SHIELDED_FROM_EPOCH`: Start epoch for shielded note scanning. * `MAZZE_SHIELDED_LOG_CHUNK`: Log query batch size when scanning shielded notes. * `MAZZE_FAUCET_AMOUNT`: Default faucet amount in MAZZE for dev/test. * `MAZZE_WALLET_PASS`: Unlock encrypted wallets non-interactively. ## Commands ### Wallet * `wallet new [--password]`: Create a new wallet and store the secret. * `wallet import [--password]`: Import an existing secret. * `wallet list [--no-balances]`: List known wallets (optional balance fetch). * `wallet balance --name [--epoch ] [--public|--private|--all] [--from-epoch ]`: Show public and/or shielded balances. Shielded scans start at `--from-epoch`. * `wallet transfer --name --dest --amount [--shielded]`: Public transfer by default, or shielded transfer when `--shielded` is set. * `wallet unshield --name --dest --amount `: Move funds from the shielded pool to a public address. * `wallet shield-deposit --name --amount [--to ]`: Deposit public funds into the shielded pool. * `wallet show `: Print wallet metadata (addresses, encryption, created). * `wallet address --name `: Print public address. * `wallet shielded-address --name `: Print shielded address (if present). * `wallet delete `: Remove wallet files from disk. ### Chain and account queries * `status`: Raw `mazze_getStatus` response. * `summary`: Human-friendly status summary. * `balance [epoch]`: Public balance at epoch (default latest). * `account [epoch]`: Account info at epoch. * `nonce [epoch]`: Next nonce. * `pending `: Pending transaction info. * `pending-txs [limit]`: Pending transactions for account. * `tx `: Get transaction by hash. * `receipt `: Get receipt by hash. * `tx-status `: Print receipt or pending status. * `watch [interval] [timeout]`: Wait for a receipt to appear. * `addr `: Convert hex <-> base32 address. * `dashboard `: Control the interactive dashboard. * `wait [seconds]`: Wait for RPC to become responsive. ### Transfers * `send `: Send a public transfer. * `faucet --name [--amount ]`: Dev/test faucet using genesis accounts. * `shield-deposit [shielded-output]`: Deposit into the shielded pool. * `shield-send [--inputs ] `: Send shielded outputs (requires prebuilt inputs JSON). ### Shielded pool (read-only) * `root`: Query current shielded pool root. * `vkhash`: Query the verifying key hash. * `nullifier `: Check a nullifier state. ## Related docs * `setup-guide.md` * `../privacy/transactions.md` * `rpc.md` # Mining Guide Mazze uses Proof-of-Work backed by RandomX. A node validates PoW and assembles blocks; miners search nonces that satisfy the current difficulty target. ## Mining modes (node config) Mining behavior is controlled by `run/hydra.toml`: * `mining_author`: reward address (base32 or 40-hex). Required for mining. * `mining_type`: `stratum`, `cpu`, or `disable`. * `stratum_listen_address`, `stratum_port`: stratum endpoint for external miners. * `stratum_secret`: 64-hex secret used to authorize stratum workers (required by `mazze-miner`). * `pow_problem_window_size`: PoW manager window size. If `mining_type` is not set, the node defaults to: * `stratum` when `mining_author` and `stratum_secret` are set. * `cpu` when `mining_author` is set but `stratum_secret` is not. * `disable` otherwise. ## Stratum mining (recommended for production) 1. Set your reward address: * `mining_author = ""` 2. Enable stratum: * `mining_type = "stratum"` * `stratum_listen_address = "0.0.0.0"` (or bind to a specific IP) * `stratum_port = 32525` * `stratum_secret = "<64-hex>"` (required by `mazze-miner`) 3. Start the node: ```bash cargo build --release -p mazze ./run/start-node.sh ``` 4. Start the miner (local): ```bash cargo build --release -p mazze-miner ./run/start-miner.sh ``` ### Miner configuration `mazze-miner` reads the stratum address and secret from the node config. You can override settings on the command line: ```bash ./target/release/mazze-miner \ --config run/hydra.toml \ --stratum-address 127.0.0.1:32525 \ --num-threads 16 \ --worker-id 1 ``` The helper script `run/start-miner.sh` also supports environment variables: * `NUM_THREADS` (default: 16) * `WORKER_ID` (default: 1) * `RANDOMX_FULL_MEM` (default: 0, set to `1` for full-memory RandomX) If miners are remote, expose `stratum_port` and set `stratum_listen_address` accordingly. ## CPU mining (single-node) For a single machine without stratum workers: 1. Set `mining_author`. 2. Set `mining_type = "cpu"`. 3. Start the node (`./run/start-node.sh`). No separate miner process is needed in CPU mode. ## Dev mode (no PoW) In dev mode, blocks can be generated without PoW: * `mode = "dev"` * `dev_block_interval_ms = 500` (or omit for tx-triggered blocks) * `mining_type = "disable"` Use `run/start-node-dev.sh` to generate a dev config automatically. ## Monitoring mining * Logs: `run/logs/mazze-node.log` and `run/logs/mazze-miner.log`. * RPC checks: * `mazze_getStatus` (chain progress). * `mazze_getBlockRewardInfo` (reward data per epoch). ## Related docs * `../architecture/pow-and-mining.md` * `setup-guide.md` * `viewing-logs.md` # RPC Guide Mazze exposes JSON-RPC over HTTP, WebSocket, and TCP. There are two RPC surfaces: * Mazze core (native) APIs. * EVM (Ethereum-compatible) APIs. The exact set of enabled methods depends on your config. ## Endpoints and configuration All RPC ports and API allowlists live in `run/hydra.toml`. Common fields: * `jsonrpc_http_port`, `jsonrpc_ws_port`, `jsonrpc_tcp_port`: Mazze core APIs. * `jsonrpc_local_http_port`, `jsonrpc_local_ws_port`, `jsonrpc_local_tcp_port`: local-only Mazze endpoints (recommended for debug/admin calls). * `jsonrpc_http_eth_port`, `jsonrpc_ws_eth_port`: EVM APIs. * `public_rpc_apis`: core API allowlist (`all`, `safe`, `mazze`, `debug`, `trace`, `txpool`, `test`, `pubsub`, ...). * `public_evm_rpc_apis`: EVM API allowlist (`evm`, `eth`, `ethpubsub`, `ethdebug`). ## HTTP call examples Mazze core status: ```bash curl -s http://127.0.0.1:12539 \ -H 'content-type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"mazze_getStatus","params":[]}' ``` Mazze call (latest\_state): ```bash curl -s http://127.0.0.1:12539 \ -H 'content-type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"mazze_call","params":[{"to":"MAZZE:TYPE.BUILTIN:AAEJUAAAAAAAAAAAAAAAAAAAAAAAAAAABAJ1SJV3W2","data":"0xebf0c717"},"latest_state"]}' ``` EVM (eSpace) block number: ```bash curl -s http://127.0.0.1:58545 \ -H 'content-type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' ``` ## WebSocket pubsub example ```bash # Requires a WS client like wscat wscat -c ws://127.0.0.1:52535 > {"jsonrpc":"2.0","id":1,"method":"mazze_subscribe","params":["newHeads"]} ``` ## Supply and burn calls * `mazze_getSupplyInfo`: returns chain supply aggregates from node state. * `mazze_getFeeBurnt`: returns cumulative MIP-1559 burned amount. Interpretation note: * Theoretical tokenomics maximum and live bridge liquidity are separate from direct RPC state values. * For current tokenomics model and bridge constraints, see: `../tokenomics/overview.md` and `../tokenomics/bridge-liquidity.md`. ## Full RPC method list ### Mazze core (native) APIs ``` mazze_gasPrice mazze_maxPriorityFeePerGas mazze_epochNumber mazze_getBalance mazze_getAdmin mazze_getSponsorInfo mazze_getCollateralForStorage mazze_getCode mazze_getStorageAt mazze_getStorageRoot mazze_getBlockByHash mazze_getBlockByHashWithMainAssumption mazze_getBlockByEpochNumber mazze_getBlockByBlockNumber mazze_getBestBlockHash mazze_getNextNonce mazze_sendRawTransaction mazze_call mazze_getLogs mazze_getTransactionByHash mazze_getAccountPendingInfo mazze_getAccountPendingTransactions mazze_estimateGasAndCollateral mazze_feeHistory mazze_checkBalanceAgainstTransaction mazze_getBlocksByEpoch mazze_getSkippedBlocksByEpoch mazze_getTransactionReceipt mazze_getAccount mazze_getConfirmationRiskByHash mazze_getStatus mazze_getBlockRewardInfo mazze_clientVersion mazze_getSupplyInfo mazze_getCollateralInfo mazze_getFeeBurnt mazze_isTimerBlock mazze_getTimerChain mazze_getTimerChainDifficulty mazze_getBlockBlameInfo mazze_getDagTips mazze_getSkippedBlockHashesByEpoch mazze_getRandomXEpochInfo mazze_getEraDetails mazze_getBlockWeight mazze_isAdaptiveBlock mazze_isPartialInvalid ``` ### Mazze filters ``` mazze_newFilter mazze_newBlockFilter mazze_newPendingTransactionFilter mazze_getFilterChanges mazze_getFilterLogs mazze_uninstallFilter ``` ### Mazze txpool ``` txpool_status txpool_nextNonce txpool_transactionByAddressAndNonce txpool_pendingNonceRange txpool_txWithPoolInfo txpool_accountPendingInfo txpool_accountPendingTransactions ``` ### Mazze debug and admin ``` txpool_inspect txpool_content txpool_accountTransactions txpool_clear net_throttling net_node net_disconnect_node net_sessions current_sync_phase consensus_graph_state sync_graph_state mazze_sendTransaction accounts new_account unlock_account lock_account sign mazze_signTransaction mazze_getEpochReceipts debug_statOnGasLoad debug_getEpochReceiptProofByTransaction debug_getTransactionsByEpoch debug_getTransactionsByBlock ``` ### Mazze trace ``` trace_block trace_filter trace_transaction trace_epoch ``` ### Mazze test/dev ``` sayhello getblockcount getgoodput generate_empty_blocks generatefixedblock addnode removenode getpeerinfo mazze_getChain stop getnodeid addlatency generateoneblock generate_one_block_with_direct_txgen test_generatecustomblock test_generateblockwithfaketxs test_generateblockwithblameinfo test_generate_block_with_nonce_and_timestamp get_block_status expireblockgc getMainChainAndWeight getExecutedInfo test_sendUsableGenesisAccounts set_db_crash save_node_db ``` ### Mazze pubsub (WebSocket) Methods: ``` mazze_subscribe mazze_unsubscribe ``` Subscription kinds: `newHeads`, `logs`, `newPendingTransactions`, `syncing`, `epochs`. ### EVM (Ethereum-compatible) APIs ``` web3_clientVersion net_version eth_protocolVersion eth_syncing eth_hashrate eth_coinbase eth_mining eth_chainId eth_gasPrice eth_maxPriorityFeePerGas eth_feeHistory eth_accounts eth_blockNumber eth_getBalance eth_getStorageAt eth_getBlockByHash eth_getBlockByNumber eth_getTransactionCount eth_getBlockTransactionCountByHash eth_getBlockTransactionCountByNumber ``` # Viewing Logs ## Zurich development phase While the Mazze network is in the Zurich development phase, logs are stored in the `run/logs` directory by default with a higher verbosity level (DEBUG). This is to ensure that the Mazze team can monitor the network and identify any issues that may arise. This verbosity level will be reduced to INFO after the mainnet launch. In the meantime, **you must be careful with the log size**, as it will grow quickly. ## Docker Installation View logs in real-time using: ```bash # Node logs docker logs -f mazze-node # Miner logs docker logs -f mazze-miner ``` ## Source Build Installation Logs are stored in the `run/logs` directory by default. ```bash # Node logs tail -f run/logs/mazze-node.log # Miner logs tail -f run/logs/mazze-miner.log # Remove `-f` flag if you don't want to follow the logs in real-time. ``` # Getting Started This quick start is aligned with [Setup Guide](/testnet/setup-guide). ## Fast path (Docker recommended) 1. Edit `run/hydra.toml`: * `public_address = ""` (or leave empty for auto-detect). * `mining_author = ""` (optional; required for mining). 2. Start services: ```bash sudo docker compose up -d ``` 3. Check logs: ```bash sudo docker compose logs node | tail -n 200 sudo docker compose logs miner | tail -n 200 ``` 4. Verify node ID: ```bash sudo docker compose logs node | grep "Self node id:" | tail -n 1 ``` 5. Open CLI and verify status: ```bash ./run/mazze-cli.sh status ./run/mazze-cli.sh summary ``` ## Next steps * Wallet operations: [Mazze CLI](/testnet/mazze-cli) * Mining configuration: [Mining Guide](/testnet/mining) * RPC checks and integration: [RPC Guide](/testnet/rpc) * Log monitoring: [Viewing Mazze Logs](/testnet/viewing-logs) # Deploying Smart Contracts Mazze supports EVM-compatible development workflows, but test configuration must come from your current RPC environment. ## Before deploying 1. Ensure node/RPC are running: [Setup Guide](/testnet/setup-guide), [RPC Guide](/testnet/rpc). 2. Verify chain responsiveness: ```bash ./run/mazze-cli.sh status ``` 3. Query EVM chain id from active RPC before hardcoding it in tooling: ```bash curl -s http://127.0.0.1:58545 \ -H 'content-type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' ``` ## Hardhat example (environment-driven) ```javascript require('@nomicfoundation/hardhat-toolbox'); module.exports = { solidity: '0.8.24', networks: { mazze: { url: process.env.MAZZE_RPC_URL, accounts: [process.env.PRIVATE_KEY], chainId: Number(process.env.MAZZE_CHAIN_ID), }, }, }; ``` Use environment variables from your active node deployment, not old static docs values. ## Recommended workflow * Build and deploy as usual with Hardhat/Foundry/Truffle. * Use [RPC Guide](/testnet/rpc) for JSON-RPC method checks. * Use [Mazze CLI](/testnet/mazze-cli) to inspect balances/receipts quickly. # FAQs and Troubleshooting ## FAQs ### Q1: What is the current block cadence target? **A:** Current operational target in this docs set is **4 BPS**. Effective cadence can vary by mode and network conditions. ### Q2: What is the fastest supported setup path? **A:** Docker Compose (`sudo docker compose up -d`) from [Setup Guide](/testnet/setup-guide). ### Q3: How do I control mining behavior? **A:** Configure `run/hydra.toml` using `mining_type` (`stratum`, `cpu`, `disable`), `mining_author`, and stratum fields. See [Mining Guide](/testnet/mining). ### Q4: How do I inspect chain health quickly? **A:** Run: ```bash ./run/mazze-cli.sh status ./run/mazze-cli.sh summary ``` and use `mazze_getStatus` from [RPC Guide](/testnet/rpc). ### Q5: Which section is canonical for privacy implementation? **A:** `privacy/` is canonical. ## Troubleshooting ### Issue 1: Node starts but chain does not advance * Confirm RPC responds (`./run/mazze-cli.sh status`). * If mining is expected, verify `mining_author` and `mining_type`. * In stratum mode, confirm `stratum_secret`, miner connectivity, and worker logs. ### Issue 2: Miner running but no accepted work * Check node and miner logs ([Viewing Mazze Logs](/testnet/viewing-logs)). * Confirm `stratum_address`, `stratum_port`, and secrets match. * Validate thread settings (`NUM_THREADS`, `RANDOMX_FULL_MEM`) where relevant. ### Issue 3: CLI commands fail * Verify `RPC_URL` points to active endpoint. * Ensure HTTP RPC is enabled in `run/hydra.toml`. * Check if local-only RPC port is used by your setup. ### Issue 4: Config changes have no effect in Docker Apply config by recreating containers: ```bash sudo docker compose up -d --force-recreate ``` # Temporary Limitations This page tracks current operational caveats for the Zurich development phase. ## Known constraints * Logging verbosity is higher (DEBUG), so log size grows quickly. * Behavior can differ across modes (`dev` vs normal PoW modes). * Dev mode may use custom intervals (`dev_block_interval_ms`) and should not be treated as production throughput. * Mining availability depends on config (`mining_author`, `mining_type`, stratum settings). ## What to do during testing * Monitor logs continuously ([Viewing Mazze Logs](/testnet/viewing-logs)). * Keep config under version control (`run/hydra.toml`, `run/log.yaml`). * Recreate containers after config changes: ```bash sudo docker compose up -d --force-recreate ``` * Validate chain progress with RPC/CLI (`mazze_getStatus`, `./run/mazze-cli.sh summary`). ## Cadence note Current operational target used in docs is **4 BPS**, but effective observed cadence can vary with network conditions and selected mode. # Wallet Tool Connection (MetaMask) This page has been updated to avoid stale hardcoded values. ## Recommended approach Use your **current RPC endpoint and chain settings** from your active environment configuration rather than old static values. * For local development, get RPC ports from `run/hydra.toml`. * For operational checks, validate connectivity first with [RPC Guide](/testnet/rpc) and [Mazze CLI](/testnet/mazze-cli). ## Steps 1. Open MetaMask and choose **Add network**. 2. Fill network fields using the RPC endpoint and chain ID currently used by your node/environment. 3. Save and switch network. 4. Verify connectivity by sending a read-only call (for example with `eth_chainId` from [RPC Guide](/testnet/rpc)). ## Important If your environment is updated, network values may change. Always trust active configuration and RPC validation over old screenshots/tutorial constants. # Feedback and Reporting Issues Accurate reports are critical for node/miner/RPC stability. ## What to include in every report * Environment: Docker or source build * Config context: relevant `run/hydra.toml` fields (sanitize secrets) * Exact command executed * Full error output * Time range of issue * Node ID (if available) ## Required logs ### Docker ```bash docker logs -f mazze-node docker logs -f mazze-miner ``` ### Source build ```bash tail -n 300 run/logs/mazze-node.log tail -n 300 run/logs/mazze-miner.log ``` ## Useful diagnostic checks ```bash ./run/mazze-cli.sh status ./run/mazze-cli.sh summary ``` And RPC status call from [RPC Guide](/testnet/rpc). ## Where to report Use the official Mazze support/community channels and include the full context above so issues can be reproduced quickly. # FAQ ### What is Mazze at a technical level? Mazze is a PoW blockchain with a DAG-based structure (DETS in consensus), epoch-based execution, and native + EVM transaction spaces. ### What is the current block production cadence? Current operational docs use **4 BPS** (4 blocks per second) as the network target. In local dev mode, cadence can differ based on `dev_block_interval_ms` and configuration. ### Is "1 block per second" still correct? No. That value is outdated and has been replaced in this documentation set. ### What consensus/mining model is used? Mazze uses Proof of Work with RandomX hashing. Mining can run in `stratum`, `cpu`, or `disable` mode, configured in `run/hydra.toml`. ### How do I run a node quickly? Use Docker Compose (recommended in the [Setup Guide](/testnet/setup-guide)), configure `run/hydra.toml`, then start with: ```bash sudo docker compose up -d ``` ### How do I mine on Mazze? Set `mining_author`, choose `mining_type` (`stratum` or `cpu`), and run node/miner per the [Mining Guide](/testnet/mining). ### Does Mazze have privacy features today? Yes. Privacy is implemented via a shielded pool internal contract with proof-verified shielded transactions. ### Which proof system is currently implemented in privacy? The current privacy implementation uses **Groth16 over BLS12-381** with a Poseidon Merkle tree. ### Where is privacy documentation maintained now? Privacy documentation is maintained in the **Privacy** section: [Overview](/privacy/overview), [Shielded Pool](/privacy/shielded-pool), and [Shielded Transactions](/privacy/transactions). ### Where should I manage wallets and transfers? Use `./run/mazze-cli.sh` (Mazze CLI) for wallet creation/import, balance checks, transfers, and shielded operations. ### Where can I find RPC details? Use the [RPC guide](/testnet/rpc) for endpoints, namespaces, and examples. ### Where are logs stored? For source builds: `run/logs/`. For Docker: `docker logs -f mazze-node` and `docker logs -f mazze-miner`. ### What are the current core tokenomics values? * Wrapped MAZZE on Ethereum: 4,900,000,000 * Native genesis issuance: 3,900,000,000 * Mining target: 2,500,000,000 * Theoretical native upper bound: 6,400,000,000 ### Where should I start reading now? * [Architecture](/architecture/architecture) * [Privacy](/privacy/privacy) * [Tokenomics](/tokenomics/overview) * [Setup Guide](/testnet/setup-guide) * [Mazze CLI](/testnet/mazze-cli) * [Mining Guide](/testnet/mining) # Glossary Navigating Blockchain Terminology ## Definitions
BPS (Blocks Per Second)Block production rate. Current operational target documented here is 4 BPS, while dev mode can run with different intervals.
DAGDirected Acyclic Graph used by Mazze for parent/referee block relationships.
DETSDAG-Embedded Tree Structure used by consensus to order and process blocks.
EpochOrdered execution unit in Mazze. State/receipts commitments are handled with deferred epoch execution.
PoW (Proof of Work)Consensus security model used by Mazze. Hashing is RandomX-based.
RandomXPoW algorithm implementation used for nonce search and block validation.
StratumMining mode where miners connect to a node's stratum endpoint and submit solutions.
CPU MiningMining mode where the node mines locally without external stratum workers.
Shielded PoolInternal contract handling privacy-preserving deposits and spends with proof verification.
Groth16Zero-knowledge proof system currently used in Mazze privacy implementation.
Poseidon Merkle TreeMerkle structure used by the shielded pool for commitments and roots.
NullifierUnique value recorded in shielded spends to prevent double-spending of private notes.
Bridge Liquidity (Directional)Bridge capacity is direction-dependent; one direction can pause if destination-side liquidity is insufficient.
Native IssuanceSupply accounting model: genesis + mined - burnt.
Mazze CLICommand-line tool (`run/mazze-cli.sh`) for wallet, transfer, and shielded workflows via RPC.
RPCJSON-RPC interfaces (Mazze native + EVM-compatible) exposed over HTTP/WS/TCP depending on config.
For canonical technical details, see [Architecture](/architecture/architecture), [Privacy](/privacy/privacy), [Tokenomics](/tokenomics/overview), and [Testnet Operations](/testnet/setup-guide). # Zealy Campaign Engage, Achieve, and Earn Welcome to the Mazze Zealy Campaign, a dynamic platform where our community members can engage with the Mazze project in exciting and rewarding ways. Through Zealy, we’re offering a series of tasks and challenges that not only promote deeper understanding and involvement with our blockchain technology but also reward your efforts and contributions. ### **How It Works** * **Tasks and Challenges**: Participate in various activities ranging from social media engagement, content creation, to technical challenges related to Mazze. * **Earn Rewards**: Complete tasks to earn points that can be exchanged for rewards, including MAZZE tokens, exclusive access to events, and more. * **Track Your Progress**: Zealy’s intuitive platform lets you keep track of your achievements and see how you stack up against other community members. ### **Why Participate?** * **Enhance Your Knowledge**: Learn more about Mazze and blockchain technology through hands-on involvement. * **Community Engagement**: Connect with other Mazze enthusiasts, share experiences, and grow together. * **Recognition and Rewards**: Your efforts and contributions are valuable to us. Earn rewards as you help us build a stronger community. ### **Get Started Today** Join the Mazze Zealy Campaign now and start your journey towards becoming a more active member of our community. Let’s innovate, engage, and grow together.
Zealy Campaign and Instructions Soon
# Ambassador Program Join Our Mission The Mazze Ambassador Program is an exclusive initiative inviting enthusiastic individuals to become key representatives of the Mazze blockchain project. As a Mazze Ambassador, you will play a pivotal role in spreading awareness and fostering community engagement for our innovative blockchain platform. ### **Why Become a Mazze Ambassador?** * Share your passion for blockchain technology and help shape the future of Mazze. * Gain early access to new features and direct communication channels with our development team. * Lead and nurture the Mazze community, organizing events and engaging in meaningful conversations. * Enjoy exclusive rewards, including MAZZE tokens, and be recognized for your contributions and influence. ### **Your Role as an Ambassador** * Use your network and platforms to spread the word about Mazze’s unique features and developments. * Offer valuable insights and suggestions to help improve the Mazze platform. * Be an active participant in forums, social media, and community events, acting as a bridge between Mazze and its users. ### **Who Can Apply?** Whether you're a blockchain enthusiast, a content creator, or a community influencer, if you have a passion for innovation and a drive to make a difference, we want you on our team. ### **Join Us Today** Become a Mazze Ambassador and help lead the way in blockchain technology. Apply now to start your journey with us and be part of something revolutionary.
Ambassador Program Application Form [Soon](/community/ambassador-program#join-us-today)
# Hackathon Elevating Blockchain Security At Mazze, we treat security as a core engineering requirement. The Mazze Hackathon is part of our ecosystem hardening and developer activation work in **Phase C**. ### **Mazze Hackathon** | **More than a competition** The Mazze Hackathon is not just a contest; it's an innovation incubator and a testament to our dedication to security. We invite developers, coders, and cybersecurity experts worldwide to rigorously test our blockchain infrastructure. This event is a platform for identifying vulnerabilities, optimizing performance, and developing groundbreaking security solutions. ### **Event Highlights:** * From smart contract security to network resilience, the Hackathon offers a range of categories for participants to showcase their skills. * We harness the collective intelligence of a global community, ensuring shared responsibility for our platform's security. * The event will be enriched with workshops, keynote speeches, and collaborative sessions, featuring leading figures in blockchain and cybersecurity. * Significant contributions and breakthroughs will be acknowledged with substantial rewards, highlighting the value we place on innovative solutions. ### **Long-Term Impact** The Mazze Hackathon goes beyond the event itself. The insights and advancements achieved will be integral to our continuous development cycle, ensuring Mazze stays at the forefront of blockchain security technology. ### **Join Us in Shaping a Secure Blockchain Future** The Mazze Hackathon is more than a competition; it's a festival of technology, a hub for knowledge exchange, and a display of our unwavering commitment to security. Join us in this landmark event to push the boundaries of blockchain security and innovation. {% hint style="info" %} *Hackathon registration and schedule are published during **Phase C** through official communication channels.* {% endhint %} # Grant Program Fostering Development on the MAZZE Blockchain The Mazze Grant Program is designed to accelerate growth across the ecosystem. It targets developers, researchers, and teams building useful infrastructure and applications on Mazze. ### **Why Apply for the Mazze Grant?** * Developers can build on Mazze's PoW + DAG/DETS architecture and current privacy stack. * Grants are available in MAZZE tokens or USDT, offering flexibility and financial stability for your projects. * Gain access to a community of experts, resources, and potential partnerships within the Mazze ecosystem. ### **Eligibility and Application** The grant program is open to developers, startups, and researchers proposing projects that contribute to scalability, privacy tooling, developer infrastructure, and ecosystem adoption. ### **Benefits of the Grant Program** * By providing financial and technical support, we aim to bring the best minds to develop on Mazze. * Encourage a range of use cases, from DeFi to supply chain solutions, expanding the utility of MAZZE. * Strengthen the Mazze community, fostering a robust and diverse network of users and developers. ### **Join Us in Shaping the Future of Blockchain** If you're passionate about blockchain technology and have a project that aligns with our vision, we invite you to apply for the Mazze Grant Program. Together, we can push the boundaries of what's possible in the blockchain space. {% hint style="info" %} *Grant program application windows are announced during **Phase C** ecosystem activation and through official communication channels.* {% endhint %} # Media Kit Banding and Logos Our brand is crafted with you in mind, designed for your use and enhancement. These guidelines provide an easy-to-follow structure for anyone leveraging the Self Chain brand in their projects. ### Logotype Importance Our logotype stands as the cornerstone of our visual identity, playing a crucial role in establishing brand recognition. To achieve this, it is imperative that the logo is consistently replicated across all mediums. Clarity and visibility are paramount; the logo must not be obscured by nearby elements and should always be surrounded by a sufficient area of clear space to ensure its prominence. {% hint style="warning" %} **Please consider the following guidelines when utilizing the logo** * Avoid cropping, rotating, or pairing the logo with different colors. * Do not reconstruct the logo with alternative typefaces. * Steer clear of adding shadows, transparencies, or any other effects. * Maintain the logo's original shape and proportions without alteration. * Ensure there is ample padding around the logo to preserve its integrity. {% endhint %} {% tabs %} {% tab title="Banner PNG" %}
{% file src="/files/5RmvYjw5thNMNhhqkYCn" %}
{% file src="/files/cAEMwVKL162VitJ61jLk" %}
{% file src="/files/UaVC9pvqICeRuTMRJWgh" %} {% endtab %} {% tab title="Banner SVG" %} {% file src="/files/DmAYVfTwWWzALK5DvfhG" %} {% file src="/files/PYAJWSyl48wDJiQ319oq" %} {% file src="/files/6b4p56T5mkbmg0M29cIZ" %} {% endtab %} {% endtabs %} ### Token The MAZZE Token serves as an adaptable representation of the network for instances where the complete brand identity cannot be accommodated, or the square dimensions of the medium necessitate a more condensed form. {% tabs %} {% tab title="Logo PNG" %}
{% file src="/files/ZSq2QRsaUTuX9s6H8gAi" %}
{% file src="/files/qYDNGtMS01TsSnBk0Wdu" %}
{% file src="/files/2utKavmhDVMjv9GaKJsE" %} {% endtab %} {% tab title="Logo SVG" %} {% file src="/files/1zP1jxKNR989vvH8Yyw3" %} {% file src="/files/VNlvQ2l9PcTPAFI404JU" %} {% file src="/files/32jlne6QHHJVrpHY2ib1" %} {% endtab %} {% endtabs %} # Careers Our mission is to attract exceptional talent motivated by the revolutionary spirit of the Web3 industry and its foundational principles. Our team is a mosaic of individuals from various corners of the globe, embracing a rich diversity of backgrounds, experiences, ethnicities, races, colors, genders, and sexual orientations. Reflecting our worldwide user base, we aspire for our core team to mirror this global diversity, fostering an inclusive environment where innovation and collaboration flourish. {% hint style="success" %} ### We're now hiring! {% endhint %} ### TikTok **Content Creator** Role Summary | This position is centered on crafting engaging and creative video content specifically for TikTok. The role requires close collaboration with our marketing team to devise impactful content strategies and campaigns, keen observation of evolving TikTok trends for optimal content alignment, and proactive engagement with the platform's community to ensure the brand's voice is consistently represented. **Key Responsibilities:** * Produce and refine captivating TikTok videos. * Work alongside the marketing department to create effective content plans. * Stay updated with TikTok trends to enhance audience engagement. * Actively interact with viewers, responding to comments and queries. **Qualifications:** * Demonstrated experience in TikTok content creation. * Insight into the cryptocurrency market and decentralized finance. * A knack for generating original content ideas. * Proficiency in video editing and in-depth knowledge of TikTok's algorithm. * Superior English communication and writing skills. *** ### Telegram Community Moderator **Role Overview** | As a Telegram Community Moderator, you'll be pivotal in managing our Telegram group, fostering a welcoming environment, guiding discussions, and ensuring community guidelines are upheld. This role involves direct interaction with our community, addressing inquiries, and facilitating engaging discussions. **Responsibilities:** * Engage with and moderate the Telegram community. * Enforce community standards and guidelines. * Facilitate discussions and provide assistance to members. **Requirements:** * Proven experience in community management, especially on Telegram. * Excellent communication skills and the ability to foster a positive community environment. * A good understanding of blockchain technology and digital currencies. *** ### Marketing Lead **Role Summary** | The Marketing Lead will strategize, develop, and execute comprehensive marketing plans and campaigns across various platforms. This role demands innovation in brand positioning, market research, and the creation of targeted marketing strategies to drive engagement and growth. Leadership in coordinating cross-functional teams and managing marketing initiatives from conception through to analysis is key. **Responsibilities:** * Develop and implement marketing strategies. * Lead cross-functional teams in marketing campaign execution. * Analyze market trends and adjust strategies accordingly. **Requirements:** * Proven leadership in marketing roles. * Strong analytical skills and strategic thinking. * Excellent communication abilities and teamwork skills. *** ### **Join Our Vibrant Team!** Embrace the opportunity to become a vital member of our forward-thinking and energetic team, thriving in a rapidly expanding industry. Engage directly with pioneers and thought leaders within the blockchain realm, contributing to groundbreaking projects. Your commitment and contributions will be met with ample recognition and rewards, ensuring your growth alongside ours. **Ready to Make an Impact?**\\
Shoot us an email with your resume. [career@mazze.io](mailto:career@mazze.io)
# Partnerships Join Our Journey – Collaborate with MAZZE At Mazze, we're committed to advancing the blockchain technology landscape through our unique Proof of Work (PoW) structure integrated with a Directed Acyclic Graph (DAG) architecture. Our focus is not just on building a robust and scalable blockchain network, but also on enhancing user privacy and security. With plans to incorporate Zero-Knowledge Proofs (ZK Proofs), we're on a path to creating a more private and efficient blockchain experience. ### **Why Partner with MAZZE?** * Our DAG-based PoW blockchain is designed for efficiency and scalability, setting us apart in the blockchain space. * Our roadmap includes the integration of ZK Proofs, ensuring that we stay ahead in the blockchain privacy domain. * We believe in growing together. Partnering with us means joining a forward-thinking community dedicated to advancing blockchain technology. * Mazze's unique architecture makes it ideal for a wide range of applications, from finance to supply chain management. ### **How You Can Collaborate** * Join us in building and refining the Mazze ecosystem. We welcome collaborations that push the boundaries of what's possible in blockchain technology. * Contribute to the ongoing research in blockchain technology, particularly in areas of scalability, efficiency, and privacy. * Explore how Mazze can transform your business, whether it’s through secure transactions, streamlined supply chains, or any other blockchain application. ### **Join Us on This Exciting Journey** We're more than just a blockchain project; we're a community of innovators, thinkers, and doers. Partner with us to be part of a growing ecosystem that values privacy, efficiency, and scalability. Reach out to explore how we can work together to shape the future of blockchain technology. ### **Contact Us** Get in touch to discuss partnership opportunities and how we can drive blockchain innovation together.
Contact us [partnerships@mazze.io](mailto:partnerships@mazze.io)
# Listings Connect with Us for Listings and Indexing In the ever-evolving world of blockchain and cryptocurrencies, visibility and accessibility are key. At Mazze, we understand the importance of being present across all relevant platforms, be it exchanges, protocols, or information aggregators. Our mission is to ensure that our innovative blockchain solution is accessible and well-represented wherever potential users and partners are looking. ### **Why List** Mazze**?** * Listing Mazze can significantly enhance the visibility of your platform, attracting a diverse audience interested in cutting-edge blockchain technology. * By associating with Mazze, known for its unique DAG-based PoW structure and upcoming integration of ZK Proofs, your platform gains credibility in the market. * Our collaboration can be a catalyst for mutual growth, driving more traffic and engagement to your platform while expanding our user base. ### **Collaboration Opportunities** * We're eager to partner with exchanges that value innovation and security as much as we do. * Collaborate with us to explore synergies between our technologies and to offer more comprehensive solutions to our users. * Feature Mazze in your listings and data presentations to offer your audience detailed and up-to-date information about our project. ### **Partner with Us** Join us in our journey to enhance the blockchain ecosystem. Listing Mazze is not just about adding another project to your platform, but about embracing a vision of a more scalable, efficient, and private blockchain world. Let's collaborate to bring this vision to a wider audience. ### **Get in Touch** We're excited about the prospect of working with you. Reach out to discuss how we can make Mazze a valuable addition to your platform.
Contact us [contact@mazze.io](mailto:contact@mazze.io)