Emission, Vesting & Unlock Schedule

1. Document Overview

This document explains how the BMZ token emission, vesting, and unlock system works. It describes the structure, roles, access controls, and execution flow used to release BMZ tokens over time in a controlled and verifiable way.

The vesting system is designed to manage long-term token distribution across different allocation categories such as founders, validators, investors, contributors, and ecosystem participants. It ensures that BMZ tokens are released only as per predefined schedules and rules recorded on-chain.

All vesting actions follow fixed logic enforced by smart contracts. Once vesting terms are set, they cannot be changed. This prevents manual overrides, reduces operational risk, and ensures predictable token supply behavior.

The document also explains how allocation wallets, beneficiaries, backend services, and admin tools interact with the vesting system. It is intended for internal teams, auditors, partners, and users who need a clear view of how BMZ emissions and unlocks are executed and monitored.

2. High-Level Vesting Architecture

The BMZ vesting system is built to control how tokens are locked, released, and tracked over time. It separates responsibilities across smart contracts and off-chain services so that token distribution follows fixed rules and remains verifiable at every stage.

The architecture is designed to prevent manual intervention after setup. Once a vesting contract is created, its parameters cannot be changed. This ensures that all stakeholders can rely on predictable emission and unlock behavior.

Vesting System Components

The vesting system consists of four main components, each with a defined role in the lifecycle of BMZ token distribution.

Factory Contract

The Factory Contract is responsible for deploying vesting contracts. It controls who is allowed to create new vesting schedules and checks authorization before deployment. The factory ensures that only approved allocation wallets can deploy vesting contracts and that deployment parameters are valid.

Once a vesting contract is deployed through the factory, its configuration is fixed. The factory does not allow changes to lock periods, vesting schedules, or beneficiaries after deployment.

Vesting Contract (Clone)

Each vesting contract holds BMZ tokens for a specific allocation or beneficiary. It manages the lock period, vesting timeline, and release logic. The contract calculates how many tokens can be released at any given time and transfers tokens only when conditions are met.

The vesting contract enforces all rules on-chain and does not rely on manual approvals for token release.

Backend Scheduler Service

The backend scheduler monitors active vesting contracts and checks when tokens become eligible for release. It prepares and submits transactions to trigger token transfers once lock periods end and vesting conditions are satisfied.

This service supports reliable execution and prevents repeated or invalid releases by validating contract state before each action.

Admin Panel

The admin panel is a web interface used by authorized allocation wallets. It provides visibility into deployed vesting contracts, assigned beneficiaries, release history, and current vesting status.

The admin panel does not bypass contract rules. It acts only as an interface for managing and monitoring vesting activity within the permissions granted to each wallet.

3. BMZ Token Allocation Wallets at Genesis

At genesis, the BMZ native token supply is distributed across a defined set of allocation wallets. Each allocation wallet represents a specific category and acts as the authorized controller for vesting and emission within that category.

These wallets are controlled by the client and are mapped one-to-one with vesting categories. An allocation wallet can deploy vesting contracts only for its assigned category and cannot interact with or manage allocations belonging to other categories.

Each allocation wallet serves as the source of truth for token distribution in its category. All vesting actions initiated from these wallets are enforced through on-chain logic and remain fully auditable.

BMZ Allocation by Category

Each allocation wallet is the only entity permitted to deploy vesting contracts for its category. These wallets act as authorized vesting controllers and are governed by strict access rules defined at the contract level.

All token movements from these wallets occur only through deployed vesting contracts. Direct transfers that bypass vesting logic are not part of the emission design. This ensures that BMZ token releases follow predefined schedules and remain predictable over time.

Every allocation, deployment, and release event is recorded on-chain and can be reviewed by auditors, partners, and users.

4. Access Control Model

The BMZ vesting system follows a strict access control model to ensure that only authorized parties can deploy vesting contracts and manage token distribution. All permissions are enforced at the smart-contract level and cannot be bypassed through interfaces or off-chain systems.

Access control is designed to limit authority, reduce operational risk, and ensure that every vesting action is attributable to a known and approved wallet.

On-Chain Access Control Principles

Access control is enforced directly by the Factory Contract. The contract validates the identity of the caller before allowing any vesting-related action.

Key principles include:

Only approved allocation wallets can deploy vesting contracts

Each allocation wallet is restricted to its own category

Vesting parameters cannot be changed after deployment

Unauthorized actions are rejected at the contract level

This ensures that token distribution logic remains consistent and resistant to misuse.

Defined Roles

The vesting system defines clear roles with limited and specific authority.

• Super Admin: The contract owner is responsible for approving and managing allocation wallets. This role does not manage vesting schedules or beneficiaries.
• Allocation Wallet / Admin: A category-specific wallet that deploys vesting contracts and assigns beneficiaries for its allocation. It controls only its own category.
• Vesting Beneficiary: The end user or entity that receives BMZ tokens over time according to the vesting schedule defined in the contract.

Each role has clearly separated responsibilities to avoid overlap or privilege escalation.

Authorization Rules

Allocation wallets must be explicitly whitelisted in the Factory Contract before they can deploy vesting contracts. The factory checks the sender address for every deployment request.

Authorization rules include:

• Deployment requests from non-whitelisted wallets are rejected
• Allocation wallets cannot deploy contracts for other categories
• Vesting contract parameters are locked once deployed

These rules ensure that vesting contracts follow predefined governance and that all emissions remain transparent and auditable.

5. Vesting Contract Deployment and Configuration

Vesting contracts are created through a controlled deployment process. This process ensures that BMZ tokens are locked under predefined rules and released only according to the approved vesting schedule.

All vesting contracts are deployed through the Factory Contract by authorized allocation wallets. Direct deployment outside this process is not allowed.

Vesting Contract Deployment

The deployment process involves two main participants:

• Actor: Authorized allocation wallet
• System: Factory Contract

When an allocation wallet initiates deployment, the factory verifies the callerˇs authorization and category permissions. Only after successful validation does the factory deploy a new vesting contract.

Deployment Parameters

During deployment, the allocation wallet must provide the following parameters:

• Lock period (cliff duration)
• Vesting schedule, defined as linear release
• Total BMZ token allocation
• Beneficiary wallet address
• Vesting category identifier

These parameters define how and when BMZ tokens can be released to the beneficiary.

Post-Deployment Behavior

After deployment:

• BMZ tokens are transferred into the vesting contract
• Vesting terms become fixed and cannot be changed
• No updates to the allocation amount, schedule, or beneficiary are allowed

This ensures that once a vesting contract is created, its behavior remains predictable and verifiable for its entire lifecycle.

6. Vesting Execution Flow

The vesting execution flow defines how BMZ tokens move from the locked state to the released state over time. This flow is designed to ensure that tokens are released only when conditions defined in the vesting contract are met, and that execution remains consistent across all vesting categories.

The execution process combines on-chain validation with controlled off-chain triggering. Smart contracts enforce all rules, while off-chain services handle timing and transaction submission.

Lock Period Handling

Each vesting contract includes a lock period, also known as a cliff. During this period, all BMZ tokens remain locked inside the vesting contract.

Key points of lock handling:

• No token transfers are allowed before the lock period ends
• Release attempts during the lock period are rejected by the contract
• The lock duration is defined at deployment and cannot be changed

The lock period ensures delayed access to tokens and supports long-term alignment for each allocation category.

Automated Vesting Claim Execution

Once the lock period has ended, BMZ tokens become eligible for release based on the vesting schedule. Vesting execution is handled by a backend scheduler that operates under defined rules.

Execution steps include:

• Scanning active vesting contracts
• Checking whether the lock period has completed
• Calculating the amount of BMZ tokens eligible for release
• Preparing signed transactions for eligible contracts
• Triggering token transfers through a paymaster service
• Recording transaction details and release status

The scheduler does not override contract logic. It acts only when on-chain conditions confirm that tokens can be released.

Execution Controls and Safeguards

Several controls are in place to protect against errors and misuse

• Vesting state is verified on-chain before each execution
• Duplicate releases are blocked through contract state checks
• Nonce tracking prevents repeated execution of the same release
• Failed transactions are logged and can be retried safely

These safeguards ensure that each BMZ token is released once, at the correct time, and to the correct beneficiary. The vesting execution flow repeats until the full allocation assigned to a vesting contract has been released.

7. Admin Panel Functional Scope

The admin panel is a web-based interface used by authorized allocation wallets to manage and monitor vesting activity. It provides visibility into vesting contracts and release status without bypassing on-chain controls.

All actions performed through the admin panel follow the same authorization rules enforced by the smart contracts.

Allocation Wallet Capabilities

An authorized allocation wallet can use the admin panel to:

• Connect its wallet securely
• View all vesting contracts deployed under its allocation category
• Assign beneficiaries to vesting contracts
• Configure vesting schedules at deployment
• Monitor vesting progress and token releases
• Review transaction history and release records

The admin panel serves as an operational interface and does not allow changes to vesting terms after deployment.

Access Restrictions

Access to the admin panel is limited by wallet permissions.

Key restrictions include:

• Allocation wallets can manage only their own category
• Cross-category access is blocked or limited to read-only views
• Unauthorized wallets cannot deploy or modify vesting contracts

These restrictions ensure the separation of control across allocation categories and maintain clear accountability for all vesting actions.

8. End-to-End Vesting Process Flow

The end-to-end vesting process defines the full lifecycle of the BMZ token distribution, from initial system setup to final token release. This flow ensures that every step follows predefined rules and remains traceable on-chain.

The process begins with system initialization and continues until all tokens assigned to a vesting contract are fully released to the beneficiary.

Process Flow Step

• The Factory Contract is deployed on the network.
• The Super Admin approves and whitelists allocation wallets in the factory.
• An allocation wallet connects to the admin panel.
• The allocation wallet deploys a vesting contract through the factory.
• Vesting parameters and beneficiary details are defined at deployment.
• BMZ tokens are transferred into the vesting contract.
• Tokens remain locked during the defined lock period.
• After the lock period ends, tokens become eligible for release.
• The backend scheduler detects eligible vesting contracts.
• The scheduler submits release transactions when conditions are met.
• BMZ tokens are transferred to the beneficiary wallet.
• The process repeats until the full allocation is released.

Each step is recorded on-chain, allowing any observer to verify deployment, lock status, release events, and final balances. No manual intervention is required once a vesting contract is deployed.

This structured flow ensures predictable emissions, reduces operational risk, and maintains a clear audit trail for all BMZ token unlocks.

9. Beneficiary User Flow

The beneficiary user flow explains how end users view and track their vested BMZ tokens. Beneficiaries do not control vesting execution. They have read-only access to vesting information and receive tokens automatically when release conditions are met.

All data shown to beneficiaries is sourced directly from the on-chain contract state.

User Authentication

A vesting beneficiary connects their wallet to the user dashboard. The system identifies all vesting contracts where the connected wallet is listed as a beneficiary. Access is limited to viewing information. Beneficiaries cannot change vesting parameters or trigger releases.

Vesting Dashboard

The vesting dashboard provides a clear view of the beneficiaryˇs token position.

Users can view:

• Total BMZ tokens allocated
• BMZ tokens already released
• Remaining locked BMZ tokens
• Vesting start date and lock period end date
• Vesting schedule and next release date
• Vesting category associated with the allocation

This information helps beneficiaries understand when and how tokens will be released.

Vesting and Transfer History

The dashboard also shows a complete history of token releases.

For each release, users can view:

• Released the BMZ amount
• Transaction hash
• Timestamp

This ensures transparency and allows beneficiaries to verify every transfer on the blockchain.

Beneficiary Wallet Address Change

The system supports beneficiary wallet updates with added security controls. Both single-wallet and multi-signature approval options are supported. Wallet updates do not change vesting terms. They only redirect future releases to a new approved address.

10. Multi-Signature Approval Model

The vesting system supports a multi-signature approval model for beneficiary wallet address updates. This model adds an extra layer of control when changing the destination address for future token releases.

The approval model applies only to wallet updates. It does not affect vesting schedules, allocation amounts, or release logic.

Wallet Approval Modes

Two approval modes are supported:

• Single Wallet Mode: The beneficiary wallet alone approves the address change.
• Multi-Signature Mode: Address changes require approval from multiple registered wallets.

The approval mode is selected based on security preferences.

Multi-Signature Configuration

In multi-signature mode, the system registers three wallets:

• The beneficiary wallet
• Two additional approver wallets

This creates a fixed set of wallets used for approval.

Approval Rules

The system follows an n-1 approval rule:

• Any two out of the three registered wallets must approve the request
• Approvals are submitted through signed messages

Once the required approvals are collected, the request becomes eligible for execution.

Wallet Update Flow

The wallet update process follows these steps:

• The beneficiary submits a wallet update request.
• Approval signatures are collected from any two registered wallets.
• The system verifies approval validity and quorum.
• The beneficiary address is updated on-chain.
• An event is emitted for audit tracking.
• All future vesting releases are sent to the new wallet address.

This model ensures that wallet changes are controlled, traceable, and protected against unauthorized updates.