MiCA Whitepaper Inline XBRL

N	Field	Content
00	Table of contents	General Information Part A: Information about the offeror or the person seeking admission to trading Part B: Information about the issuer, if different from the offeror or person seeking admission to trading Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Part D: Information about the crypto-asset project Part E: Information about the offer to the public of crypto-assets or their admission to trading Part F: Information about the crypto-assets Part G: Information on the rights and obligations attached to the crypto-assets Part H: Information on the underlying technology Part I: Information on the risks Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
01	Date of notification	2026-03-06
02	Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114	This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
03	Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114	This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
04	Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114	The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.
05	Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114	FALSE
06	Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114	The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
07	Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114	Warning This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
08	Characteristics of the crypto-asset	BDX is a bridged crypto-asset on BNB Smart Chain in BEP-20 form. Such a deployment represents bridged forms of the native BDX crypto-asset of the Beldex project, a decentralised Web3 ecosystem focused on privacy, security, and confidential digital interactions. This bridged representation of BDX is primarily used to support ecosystem engagement on external networks, while remaining the core privacy, consensus, and protocol-level functionalities of BDX, anchored to the native Beldex blockchain. The BDX native asset is primarily intended to be used to access and interact with services built on the Beldex network, to conduct private transactions between users, and to support the operation and security of the blockchain through staking and Masternode participation. BDX also functions as the reward and incentive mechanism for network participants who contribute to maintaining the network and its associated services. The Beldex blockchain operates under a proof-of-stake consensus mechanism and incorporates privacy-enhancing technologies at the protocol level. Following the transition of the Beldex blockchain from proof-of-work to proof-of-stake, the total supply of BDX was increased to approximately 9.9 billion tokens. This supply framework is designed to support long-term network sustainability, staking incentives, ecosystem development, and the continued operation of Beldex services. Tokens are released into circulation progressively in accordance with predefined allocation and vesting mechanisms. At the time of writing the white paper, As of the latest scheduled release on 31 December 2025, the circulating supply of BDX reached approximately 7.6 billion. The crypto-asset does not represent a claim on any reserves, assets, or revenues, and its value is not tied to any fiat currency or underlying asset. Holding BDX also confers no ownership, governance, voting, dividend, profit-sharing, or other claim against any issuer. BDX is not a financial instrument or security, and its rights are purely functional and limited to the Beldex ecosystem. No contractual obligations are imposed on holders regarding its use or participation in services.
09	Further information about utility tokens	This field is not applicable, as 05 is false.
10	Key information about the offer to the public or admission to trading	The various bridged representations of BDX, including its BEP-20 form on BNB Smart Chain, have enabled trading across multiple centralised and decentralised exchanges worldwide. Seeking admission to a regulated EU trading venue would allow existing holders to trade these tokens within the EU, complementing their current listings on platforms such as Kraken. Broader market access would enhance BDX liquidity, price discovery, and decentralised distribution, while preserving the functional role of the native token within the Beldex blockchain ecosystem.

N	Field	Content
B.1	Issuer different from offerror or person seeking admission to trading	TRUE
B.2	Name	N/A
B.3	Legal form	N/A
B.4	Registered address	N/A
B.5	Head office	N/A
B.6	Registration date	N/A
B.7	Legal entity identifier	N/A
B.8	Another identifier required pursuant to applicable national law	N/A
B.9	Parent company	N/A
B.10	Members of the management body	N/A
B.11	Business activity	N/A
B.12	Parent company business activity	N/A

N	Field	Content
C.1	Name	N/A
C.2	Legal form	N/A
C.3	Registered address	N/A
C.4	Head office	N/A
C.5	Registration date	N/A
C.6	Legal entity identifier	N/A
C.7	Another identifier required pursuant to applicable national law	N/A
C.8	Parent company	N/A
C.9	Reason for crypto-asset white paper Preparation	N/A
C.10	Members of the management body	N/A
C.11	Operator business activity	N/A
C.12	Parent company business activity	N/A
C.13	Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A
C.14	Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	N/A

N	Field	Content
E.1	Public offering or admission to trading	ATTR
E.2	Reasons for public offer or admission to trading	By admitting BDX token, in its BEP-20 or other token standard representations, to trading venues, holders will benefit from transparent price discovery and improved liquidity across regulated markets. As these bridged tokens are the forms of BDX commonly traded on centralised and decentralised exchanges, their admission supports broader access for the project’s community and ecosystem participants, enabling easier entry and exit from positions. This contributes to a more dynamic and efficient market, while preserving the native token’s role within the Beldex blockchain ecosystem.
E.3	Fundraising target	N/A
E.4	Minimum subscription goals	N/A
E.5	Maximum subscription goals	N/A
E.6	Oversubscription acceptance	N/A
E.7	Oversubscription allocation	N/A
E.8	Issue price	N/A
E.9	Official currency or any other crypto-assets determining the issue price	N/A
E.9	Official currency or any other crypto-assets determining the issue price	N/A
E.10	Subscription fee	N/A
E.11	Offer price determination method	N/A
E.12	Total number of offered/traded crypto-assets	7605634908
E.13	Targeted holders	ALL
E.14	Holder restrictions	N/A
E.15	Reimbursement notice	N/A
E.16	Refund mechanism	N/A
E.17	Refund timeline	N/A
E.18	Offer phases	N/A
E.19	Early purchase discount	N/A
E.20	Time-limited offer	N/A
E.21	Subscription period beginning	N/A
E.22	Subscription period end	N/A
E.23	Safeguarding arrangements for offered funds/crypto-Assets	N/A
E.24	Payment methods for crypto-asset purchase	N/A
E.25	Value transfer methods for reimbursement	N/A
E.26	Right of withdrawal	N/A
E.27	Transfer of purchased crypto-assets	N/A
E.28	Transfer time schedule	N/A
E.29	Purchaser's technical requirements	N/A
E.30	Crypto-asset service provider (CASP) name	N/A
E.31	CASP identifier	N/A
E.32	Placement form	N/A
E.33	Trading platforms name	Kraken (Payward Europe Solutions Limited)
E.34	Trading platforms Market identifier code (MIC)	PGSL
E.35	Trading platforms access	Beldex is seeking admission to trading on cryptocurrency trading platforms operating within the EU, including but not limited to Kraken, subject to each platform’s independent listing procedures, compliance assessments, and technical integration requirements. Once admitted and verified, BDX will be available to Kraken users in supported jurisdictions, broadening regulated market access and liquidity for the token. Investors can access trading on trading platforms by registering an account through the website or mobile application, completing identity verification (KYC/AML), and meeting age and jurisdictional eligibility criteria.
E.36	Involved costs	Exchanges may apply a service fee calculated as a percentage of each transaction, with the exact amount disclosed to the user prior to execution. Deposits and withdrawals involving fiat currency may also be subject to additional commissions imposed by external payment service providers.
E.37	Offer expenses	No offer related expenses are involved.
E.38	Conflicts of interest	No potential conflicts of interest have been identified at this stage.
E.39	Applicable law	Ireland
E.40	Competent court	ireland

N	Field	Content
F.1	Crypto-asset type	Crypto-assets other than asset-referenced tokens or e-money tokens
F.2	Crypto-asset functionality	BDX, in its BEP-20 form on BNB Smart Chain, is used primarily for trading. It enables faster transactions and access to new use cases across the BSC ecosystem, including DeFi interactions and liquidity provision on EVM-compatible platforms. BDX on BSC, as well as on other networks, represents a bridged version of the native asset on the Beldex blockchain. The native asset serves as a medium of exchange for participants, enables private transactions, secures the network via proof-of-stake, supports decentralised naming services, and provides access to privacy-focused applications. BDX supports confidential peer-to-peer transfers using ring signatures, stealth addresses, and Ring Confidential Transactions (RingCT) with zero-knowledge proofs to conceal transaction amounts while ensuring validity. The Obscura hardfork improved efficiency by reducing proof sizes. Transaction fees are paid in BDX. BDX is used as collateral for masternodes to validate transactions, produce blocks, and support ecosystem services. BDX provides access to one of the core services, developed on the Beldex blockchain, the Beldex Name Service (BNS), which allows users to register unique, censorship-resistant domain names for use across Beldex applications. Access to BNS requires the payment of subscription fees in BDX, with pricing depending on the duration of registration. Transfer of these names to other users is permitted but subject to a protocol-level fee, also denominated in BDX. The token also enables usage of BChat, a privacy-focused messaging application. While basic communication functions may be accessible without payment, advanced features such as wallet integration, identity binding via BNS, and potentially paid messaging tiers are tied to the use of BDX. Similarly, BelNet, a decentralised virtual private network (dVPN), is part of the ecosystem’s service layer. Accessing dedicated bandwidth or prioritised traffic routing via BDX is not currently supported in production. These capabilities are still in the research and design phase and have not yet been implemented or made available to users. The Beldex Browser is a privacy-focused web browser developed as part of the Beldex ecosystem to offer users a secure, decentralised, and anonymous browsing experience. It integrates with the BelNet dVPN to route traffic through decentralised nodes, shielding user IP addresses and enabling censorship-resistant access to content. Unlike conventional browsers, the Beldex Browser is designed to prevent tracking, surveillance, and fingerprinting. The possible utilisation of BDX tokens for bandwidth allocation, enhanced privacy functionalities, or priority routing is currently under research and has not been deployed. BDX will be required for new services and interactions, such as the BNS Marketplace and the MNApp Store. These platforms will allow users to register, trade, or access decentralised applications and identity services within the ecosystem. BDX will function as the unit of payment for marketplace transactions, application access, and possibly in-application features, reinforcing its position as the utility token at the centre of the service layer. In parallel, BDX will also be used in merchant-oriented services with the introduction of point-of-sale infrastructure. This integration aims to facilitate the use of BDX for direct payments in physical and online retail environments. FHE is scheduled for integration across Ethereum, BNB Smart Chain, and Solana. These implementations suggest that bridged versions of BDX, such as ERC-20, BEP-20, and SPL tokens, will be usable in decentralised applications that support confidential computation on those respective chains. In this context, BDX is positioned as a cross-chain asset with verifiable, privacy-aligned functionality, not limited to native applications.
F.3	Planned application of functionalities	Starting in 2026, BDX will be required for the BNS Marketplace and MNApp Store, enabling users to access and interact with decentralised applications and identity services. In parallel, point-of-sale infrastructure for merchant payments is planned for Q1 2026, allowing BDX to be used for transactions in both physical and online retail. By the end of 2026, FHE integration across Ethereum, BNB Smart Chain, and Solana is scheduled, extending BDX’s functionality as a cross-chain asset with privacy-focused features.
F.4	Type of crypto-asset white paper	OTHR
F.5	The type of submission	NEWT
F.6	Crypto-asset characteristics	BDX, as a BEP-20, represents a bridged form of the native BDX asset, a cryptographically secured and fungible protocol crypto-asset of the Beldex ecosystem. The native asset has a maximum supply cap of 9.9 billion BDX, with circulating supply as of February 2026 approximating 7.6-7.8 billion BDX. Total supply includes continuously minted validator rewards generated since transition to PoS consensus on December 10, 2021. BDX utilises 9 decimal precision, where 1 BDX equals 1×10^9 atomic units, distinguishing it from the standard 18-decimal ERC-20 convention. BDX generation occurs through continuous block reward emission at a fixed rate of 10 BDX per block, with validator rewards comprising 6.25 BDX (62.5%) distributed among master node operators and 3.75 BDX (37.5%) allocated to governance functions. Block production targets 30-second intervals, generating approximately 28,880 BDX daily (10 BDX × 2,880 blocks) and roughly 105.41 million BDX annually at constant emission. This perpetual inflation model ensures ongoing incentivisation for network validators without a terminal emission schedule, though inflation rate decreases proportionally as circulating supply increases. Master node staking requirement remains constant at 10 thousand BDX per node, creating deflationary pressure through locked collateral that removes tokens from active circulation. Token burning mechanisms create counterbalancing deflationary dynamics. BNS fees for name registration, domain subscriptions, and ownership transfers are sent to provably unspendable addresses, permanently removing tokens from circulation. Over 7 million BDX has been burned through BNS adoption since the Bern hardfork (January 2024). Flash transaction fees (minimal network fees for standard transactions) are automatically burned on-chain to a wallet with unknown seed phrase, rendering those tokens permanently inaccessible. The burning rate depends on user adoption of BNS and transaction volume, creating variable deflationary pressure that may partially offset perpetual block reward inflation. Cross-chain BDX representations on EVM-compatible networks utilise the standardised contract address 0x6ad12E761b438beA3EA09F6C6266556Bb24C2181 across BNB Smart Chain, Base, Arbitrum, and Ethereum deployments, while on Solana, the BDX representation utilise the contract address CP4w2B3og2TaFUpye1kr8pdeJwwahtESKppZnffN9n9d These contracts implement LayerZero's OFT standard inheriting from OpenZeppelin's Ownable and Pausable contracts, with mint and burn functions enabling cross-chain transfers while maintaining unified supply integrity. The contract uses Solidity version 0.8.22, disables standard ownership renunciation functionality to maintain administrative lifecycle management, and implements 9-decimal precision matching native Beldex blockchain specifications. Native BDX on the Beldex L1 blockchain has no contract address as it operates as the protocol's base layer asset. BDX, in all its representations, does not confer any tangible or physical manifestation, has no intrinsic value guarantee, is non-refundable and cannot be exchanged for cash or equivalent value, does not represent shareholding or ownership rights in any entity, does not entitle holders to dividends, revenue participation, or voting rights, and is not designed as a medium of exchange for general goods or services outside the Beldex ecosystem. Token acquisition is solely for participation in the Beldex ecosystem and obtaining services thereon. BDX is not covered by deposit insurance schemes, investor compensation funds, or government guarantees.
F.7	Commercial name or trading name	N/A as DTI is provided in F.13
F.8	Website of the issuer	This field does not apply as BDX is decentralised with no issuer.
F.9	Starting date of offer to the public or admission to trading	2026-04-04
F.10	Publication date	2026-04-03
F.11	Any other services provided by the issuer	This field does not apply as BDX is issued by a non-identifiable legal entity.
F.12	Language or languages of the crypto-asset white paper	English
F.13	Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available	2ZJBB38FG
F.14	Functionally fungible group digital token identifier, where available	9DS7PNB51
F.15	Voluntary data flag	FALSE
F.16	Personal data flag	TRUE
F.17	LEI eligibility	TRUE
F.18	Home Member State	Ireland
F.19	Host Member States	Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden

N	Field	Content
G.1	Purchaser rights and obligations	This field does not apply as holding BDX does not grant ownership rights, governance or voting rights, dividend entitlements, profit-sharing rights, or any claim against the issuer or related entities. BDX does not constitute a financial instrument or a security. The rights associated with BDX are functional only and relate to its use within the Beldex ecosystem. Depending on the services used, holders may use BDX to access digital services, participate voluntarily in staking or Masternode operations, and transfer value to other users on the network in accordance with the protocol rules. There are no contractual obligations imposed on holders to use BDX in a specific manner or to participate in any service. Holders are responsible for complying with applicable laws and regulations when acquiring, holding, transferring, or using the crypto-asset. Participation in staking, Masternode operations, or ecosystem services is optional and subject to technical conditions defined by the protocol.
G.2	Exercise of rights and obligations	This field does not apply as the token confers no ownership or financial claims and does not impose any legal obligations.
G.3	Conditions for modifications of rights and obligations	This field does not apply as the token confers no ownership or financial claims and does not impose any legal obligations.
G.4	Future public offers	This field does not apply as there is no offer to the public.
G.5	Issuer retained crypto-assets	594000000
G.6	Utility Token Classification	FALSE
G.7	Key features of goods/services of utility tokens	N/A
G.8	Utility tokens redemption	N/A
G.9	Non-trading request	TRUE
G.10	Crypto-assets purchase or sale modalities	N/A
G.11	Crypto-assets transfer restrictions	None
G.12	Supply adjustment protocols	FALSE
G.13	Supply adjustment mechanisms	This field does not apply as BDX incorporates time-based supply management mechanisms and does not rely on demand-based mechanisms to manage token issuance and support ecosystem stability. Ecosystem development funds are released progressively at 3.33% per quarter over a three-year period, while team allocations are subject to a two-year cliff, followed by linear vesting over 18 months.
G.14	Token value protection schemes	FALSE
G.15	Token value protection schemes description	This field does not apply as G.14 is false
G.16	Compensation schemes	FALSE
G.17	Compensation schemes description	This field does not apply as G.16 is false
G.18	Applicable law	There is no written legal agreement between the issuer and the crypto asset holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer (to the extent that can be identified) and the given crypto asset holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset holder.
G.19	Competent court	There is no written legal agreement between the issuer and the crypto asset holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset holder and the issuer. In the absence of such an agreement, the laws that competent court will depend on the location of the issuer and the given token-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset holder.

Part H – Information on underlying technology

N	Field	Content
H.1	Distributed ledger technology	N/A as DTI is provided in F.13
H.2	Protocols and technical standards	This white paper seeks admission to trading of BDX as a BEP20 asset. BDX on the BNB Smart Chain is implemented as a BEP-20 token and has adopted LayerZero's Omnichain Fungible Token (OFT) standard, integrated with Stargate Finance for cross-chain transfers. It maintains a strict 1:1 peg to BDX assets on the Beldex Layer-1 chain through burn-and-mint mechanics: BDX burned on the source chain is minted on the destination chain (and vice versa), ensuring unified supply across networks without wrapped derivatives. The token fully complies with the BEP-20 standard, supports 9 decimals to match the native chain, and enables seamless interoperability for BSC-based DeFi, exchanges, and trading while preserving alignment with the Beldex protocol's privacy features. Networking layer The Beldex blockchain is operated as a peer-to-peer network of masternodes that exchange transactions and blocks. In the Proof-of-Stake phase, a designated block producer gathers valid transactions from the mempool and aggregates them into a nominee block, which is then submitted to a validating quorum of other nodes. This behaviour implies a gossip-style propagation of mempool transactions and blocks across the node set, coordinated by the Beldex daemon processes that implement the core networking stack. A secondary peer-to-peer network is planned and built to support storage and messaging services, extending the networking functionality beyond basic block and transaction propagation. Networking and serialisation Masternode operators are required to run a fully synchronised Beldex daemon configured in master node mode, typically managed as a long-running system service on a Linux host. This daemon participates in the peer-to-peer network, maintains a local copy of the blockchain and exchanges messages with other nodes to maintain consensus and availability. Example service configurations are provided that run the daemon in non-interactive master node mode under a dedicated system user, illustrating the expectation of persistent connectivity and continuous participation in the network. Cryptography and key formats Transaction privacy is enforced through a combination of stealth addresses and Ring Confidential Transactions. Stealth addresses are used as intermediary, one-time expendable addresses that hide the ultimate receiver of a payment on the blockchain, even where the receiver publishes a static address in advance. For each payment, a fresh stealth address is derived so that observers cannot link outputs back to the receiver’s public identifier. Ring Confidential Transactions are also employed to conceal transaction amounts. Ring Confidential Transactions use range proofs based on Pedersen commitments, allowing nodes to verify that no value is created or destroyed without learning the underlying amounts. Ring Confidential Transactions are mandatory for all new transactions, so value transfers in Beldex - BDX are always shielded in this way. Beldex is built on a codebase that originates from Monero and the broader Cryptonote family and those origins are acknowledged explicitly in licence notices. Wallet tooling is designed so that users hold and manage their own private keys locally, using Beldex wallets to secure BDX, stake the asset and trade peer-to-peer, rather than relying on centralised custodians for key management. Application layer The application layer is structured around Beldex - BDX primarily through wallets, staking flows and privacy-enhancing services. Beldex wallets hold users’ private keys, protect BDX holdings, enable staking participation, and facilitate peer-to-peer BDX exchange. A cross-platform desktop wallet is provided that is implemented with an Electron-based graphical interface allowing users to perform these operations without directly interacting with the low-level node software. This wallet communicates with the underlying blockchain through the Beldex daemon and a dedicated wallet remote procedure call process, separating consensus and networking logic from user-facing features while still relying on the same core protocol implementation. Beldex is positioned as both a confidential currency and a platform for privacy-preserving data transmission. In addition to the incentivised full-node layer, an extended architecture is designed that includes a secondary peer-to-peer network and a private messenger, with masternodes expected to host additional services such as storage servers and communication endpoints. These higher-level components build on the base chain’s confidentiality guarantees to support use cases that require private messaging or data handling alongside financial transactions. Interfaces and APIs Operational interfaces are exposed through the Beldex daemon for masternode registration, staking and lifecycle management. Operators run a fully synchronised daemon in master node mode and invoke interactive flows to prepare registrations, define contributors and finalise masternode registration transactions. These flows compute the current staking requirement, validate contributor amounts and construct on-chain transactions that lock collateral and register the node in the masternode set. This interface standardises how operators join the network, manage collateral and maintain their masternode status. A separate wallet remote procedure call component is also provided that serves as the interface between the core node and user-facing applications such as the Electron graphical wallet. The wallet application requires access to the Beldex daemon and the wallet RPC binary and uses them to create and sign transactions, manage addresses and monitor balances on behalf of the user. This architecture ensures that application developers interact with the network through a clearly separated RPC layer rather than embedding consensus or networking logic directly into front-end software.
H.3	Technology used	The BDX BEP20 token contract is implemented in Solidity and operates within the EVM-compatible runtime of BSC, inheriting the chain's high-throughput block production, low-cost gas fees, and compatibility with standard EVM tooling and wallets. The open-source contract code allows independent verification and audit of the mint-and-burn mechanics that maintain 1:1 parity with native BDX on the Beldex Layer-1 chain. The native Beldex Layer-1 serves as the security and privacy foundation, with its open-source node implementation (maintained under the Beldex-Coin organisation on GitHub) providing the canonical ledger and privacy features. Pre-built binaries and source distribution support operators on standard Linux environments, while the BEP-20 version requires no native node operation — users interact via BSC-compatible wallets such as MetaMask, Trust Wallet, or other EVM clients. These wallets manage private keys locally and connect to BSC nodes or RPC endpoints to handle transfers, balances, approvals, and DeFi interactions. No masternode staking or collateral locking is required or possible for the BEP-20 token; economic participation is limited to BSC-native activities (e.g., swaps on decentralised applications). The Electron-based graphical wallet for native BDX can be used alongside BSC wallets for cross-chain management, but BSC users primarily rely on standard EVM wallet interfaces. This architecture decouples the bridged token from native consensus while preserving protocol compatibility and enabling broad access to BSC-based trading and DeFi venues.
H.4	Consensus Mechanism	BDX BEP-20 OFT tokens on BNB Smart Chain does not participate in any consensus mechanism of its own, nor does it grant holders any role in the BNB Smart Chain’s consensus. BNB Smart Chain uses proof-of-staked Authority (PoSA), a hybrid consensus where only holders of the native gas token BNB can stake to become validators and help secure the network. BDX is simply a standard BEP-20 token contract running on top of that chain. Therefore, holders of BEP-20 BDX have zero ability to run nodes, validate blocks, earn consensus rewards, or participate in on-chain governance through their BDX holdings. They can only use the token for transfers, trading, liquidity provision, or DeFi activities on BSC. To participate in consensus or governance, a user must bridge their BDX back to the native Beldex Layer-1 chain and stake it there as a masternode under the Bucephalus PoS system. The Beldex blockchain itself is secured with the Bucephalus PoS consensus mechanism. On 10 December 2021, the transition from Proof-of-Work (PoW) to this PoS design occurred via a hardfork event. PoS in Beldex is presented as an economical and energy-efficient alternative to PoW, leveraging staked BDX rather than continuous energy expenditure to select block producers and validators. After this transition, the average block time was reduced by a factor of four, resulting in an approximate block interval of 30 seconds. A minimum collateral stake of 10,000 BDX is required to operate a PoS node in the consensus set. Each masternode must prove ownership of 10,000 BDX as collateral, which is initially locked for 86,400 blocks. During this lock period, the operator cannot spend the staked collateral, ensuring that consensus participants maintain a fixed economic stake in the network for a significant duration. Any participant is allowed to contribute to the Beldex network as long as the required collateral is locked in a node, reflecting an open validator set model constrained only by the staking requirement. Bucephalus is implemented using quorums of staked nodes that share responsibility for block production and validation. A PoS quorum contains 12 nodes. For each block interval, one node in the quorum acts as the producer, assembling a nominee block from valid transactions drawn from the mempool, while the remaining eleven act as validators that examine the nominee block for correctness. Alongside these PoS quorums, additional quorums are operated such as Flash quorums, masternode quorums and checkpoint quorums that carry out complementary functions in transaction confirmation and history protection. The checkpoint mechanism takes snapshots of the blockchain every four blocks, thereby limiting the number of blocks that an attacker can alter even if that attacker temporarily gains influence over consensus. The security properties of the consensus mechanism are defined in terms of the proportion of staked BDX controlled by an adversary and the penalties applied to misbehaving nodes. An attacker would need to control more than 50% of the total staked BDX in order to take over the network under the PoS model. Penalties for malicious behaviour are enforced by locking the node's collateral for approximately 86,400 blocks (or 30 days), after which the locked BDX is released. This creates a temporary economic deterrent without any permanent loss of funds. The checkpointing mechanism reinforces security by making it infeasible for an attacker to rewrite more than a limited number of recent blocks.
H.5	Incentive Mechanisms and Applicable Fees	The BEP-20 representation of BDX on the BNB Smart Chain carries no protocol-level incentives, staking rewards, governance participation, or token-specific economic mechanisms. All validator incentives, block reward distribution, staking rewards, Flash fee burning, and governance funding remain exclusive to the native Beldex Layer-1 blockchain. Cross-chain transfers to or from BSC via the Beldex Bridge, LayerZero's OFT standard and Stargate Finance incur only standard BSC network gas fees paid in BNB for transaction processing, messaging, and liquidity routing. No additional BDX-based fees, burns, staking yields, or rewards are applied or generated at the bridged level. Network-level fees Beldex network-level transaction fees are denominated in BDX and users who wish to transfer BDX are required to pay these fees to the nodes that process and confirm their transactions. Transaction fees compensate validators and masternodes for bandwidth, storage and computation and align the economic incentives of network participants with the continued operation of the chain. Certain classes of transaction fees are linked directly to supply dynamics. In particular, the fee component associated with Flash instant transactions is burned rather than distributed, which acts as a counterbalance to inflation. Protocol-level fees Flash instant transactions are provided as an instant-payment mechanism built on top of the Beldex blockchain. Flash allows participants to obtain confirmation of transactions before those transactions are included in an on-chain block. A dedicated network fee is associated with Flash transactions and this fee is routed into the coin burning mechanism. Under this design, Flash fees do not accrue to node operators or governance pools but are removed from circulation, contributing to long-term supply management for Beldex - BDX. Validator incentives Consensus participants are rewarded through block rewards and fee flows. After the transition to PoS via the Bucephalus hardfork, the per-block reward was increased from 2 BDX to 10 BDX, raising the rate at which new BDX enters circulation. 62.5% of this new block reward is allocated to masternode block producers and 37.5% to governance, ensuring that both consensus participants and governance mechanisms receive a share of newly minted tokens. In addition, a reward queue is employed for masternodes: masternodes are ordered in a queue, and when a masternode receives a reward it moves to the end of the queue, while nodes that have been waiting for longer move towards the front. This queue design aims to distribute rewards more evenly across the active masternode set over time. These rewards are reinforced with a collateralisation structure that requires masternodes to lock 10,000 BDX, initially for 86,400 blocks, and exposes them to locking of both collateral and rewards if they act maliciously. Pooled staking is also allowed, where a masternode operator may contribute part of the required stake and one to three other contributors provide the remainder. In this pooled model, the participants share rewards in proportion to their stake, subject to minimum contribution thresholds and an operator contribution of at least a quarter of the total requirement. This setup enables smaller BDX holders to participate in validator economics through shared masternodes while preserving the economic alignment of operators who maintain the infrastructure. Governance of parameters A defined share of new issuance is allocated to governance. Specifically, 37.5% of new block rewards is directed to governance-related purposes, while the remaining 62.5% goes to masternode block producers. This mechanism creates an on-chain funding stream that can support governance decisions, development and other activities that sustain the ecosystem. Governance is also embedded into the monetary structure of Beldex - BDX by linking funding capacity directly to block production and inflation.
H.6	Use of distributed ledger technology	False
H.7	DLT functionality description	N/A
H.8	Audit	TRUE
H.9	Audit outcome	CertiK \| 2022 Beldex Chain Code Audit Object: Beldex engaged CertiK in 2022 to perform a dedicated code audit of the Beldex chain, focusing on the Layer-1 implementation that secures Beldex - BDX, with particular emphasis on masternode logic, quorum handling, consensus behaviour and related core components of the node software. The engagement is recorded as a Beldex Chain code audit with a manual review methodology applied to a defined set of source files. Results: The audit identified 24 findings, of which 3 were classified as medium severity, 9 as minor, and 12 as informational, with no critical or high-severity issues reported. The resolution matrix associated with the audit records seventeen findings as resolved and seven as acknowledged, and the centralisation overview lists “None” for distribution, upgrade, privilege and other categories, indicating no centralisation risks were flagged under those headings. Actions: The final status recorded for this engagement shows that the majority of identified issues had been remediated to the auditors’ satisfaction by the time of the last revision on 27 May 2022, with the remaining lower-risk items acknowledged but not marked as resolved. QuillAudits \| 2025 Beldex BNB Smart Chain Smart Contract Audit Object: In December 2025, Beldex engaged QuillAudits to review its smart contract on the BNB Smart Chain, which implements an OFT based on LayerZero’s OFT standard for bridging BDX from the Beldex Layer-1 privacy chain to EVM networks. The review focused on the Solidity implementation of the token contract at the BSC address, examining mint-and-burn mechanics, supply management, access control, pausability, and ownership settings through manual analysis, functional testing, and automated testing. Results: The audit identified three issues: one low-severity and two informational, with no critical, high, or medium-severity findings. The low-severity issue noted inconsistent decimal usage between a nine-decimal contract and an eighteen-decimal commented-out line, which could inflate balances in test deployments only. On mainnet, decimals are consistently set to 9, with no impact on live balances or supply. One informational issue raised concerns about the potential disruption to the omnichain supply invariant caused by a combined owner-only mint and public burn function. The other highlighted centralisation risks from privileged functions like pause, unpause, and mint. All issues were labelled as “acknowledged,” confirming that only minor inconsistencies and best-practice improvements were found. Actions: The audit recommends aligning test assumptions with the nine-decimal configuration, documenting the burn function’s behaviour with owner mint capabilities, and assigning owner roles to a multisignature or timelocked governance to reduce centralisation risk. Findings are recorded as acknowledged, and no major issues were found in automated testing beyond those already noted.

General information	Page 3
Part A - Information about the offeror or the person seeking admission to trading	Page 4
Part B - Information about the issuer, if different from the offeror or person seeking admission to trading	Page 5
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114	Page 6
Part D - Information about the crypto-asset project	Page 7
Part E - Information about the offer to the public of crypto-assets or their admission to trading	Page 8
Part F - Information about the crypto-assets	Page 9
Part G - Information on the rights and obligations attached to the crypto-assets	Page 10
Part H – Information on underlying technology	Page 11
Part I - Information on risks	Page 12
Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts	Page 13

N	Field	Content
I.1	Offer-related risks	Irreversibility of transactions BDX transactions on the native Beldex Layer-1 chain achieve cryptographic finality after 10 confirmations. For BDX tokens on the native Beldex protocol and on BNB Smart Chain, transactions are irreversible once confirmed. Holders face the risk of permanent loss from erroneous transfers, phishing attacks, compromised private keys, or incorrect addresses, with no protocol-level reversal mechanism available on either chain. Recovery depends entirely on the recipient voluntarily returning funds or control of the recipient’s private keys, which is rarely feasible in adversarial or loss scenarios. Market volatility and price risk BDX market prices, whether quoted as native BDX on the Beldex chain or as the BEP-20 representation on BSC, are subject to rapid and substantial fluctuations driven by broader cryptocurrency market cycles, regulatory developments, liquidity changes, protocol upgrades (including hardforks on the native chain), project announcements, or shifts in BSC ecosystem activity. Holders may experience significant mark-to-market losses, particularly during periods of forced liquidation, low liquidity, or when trading venues impose restrictions or downtime. Custody and key management risk Loss, theft, or compromise of private keys (spend key and view key on the native chain, or BSC-compatible wallet keys for the BEP-20 token) results in permanent loss of holdings with no recovery mechanism provided by the protocol or chain operators. Self-custody exposes users to risks from device failure, malware, phishing, social engineering, or physical theft. Absence of statutory compensation No deposit insurance, government guarantee, or statutory compensation scheme protects BDX holdings. Holders may be exposed to a risk of technical failures, operational incidents, smart contract vulnerabilities, bridge-related risks or counterparty issues. Exchange access and listing risk Access to secondary markets depends on the policies and operational frameworks of centralised exchanges (CEXs) and over-the-counter (OTC) venues. Listing decisions, trading pairs, and geographic availability may change over time, which could influence liquidity, price discovery, and user access. Platform requirements related to onboarding, custody, and compliance procedures may also affect participation. Impact of large transactions Large transfers, disposals, or accumulations of BDX whether on the native chain or via the BEP-20 representation on BSC may materially impact market pricing and stability. Concentrated holdings by major stakeholders, early participants, or liquidity providers could lead to price volatility, particularly during low-liquidity periods or coordinated movements across chains.
I.2	Issuer-related risks	This field does not apply. BDX is not issued by a centralised authority as defined under MiCA; it is issued in a decentralised manner through the automated block reward mechanism of the permissionless Beldex Layer-1 blockchain protocol.
I.3	Crypto-assets-related risks	Vesting and Scheduled Release Risk BDX is released quarterly from designated wallets (Ecosystem, Seed and VC, Team, Marketing). These predictable release events can create selling pressure, market volatility, or adverse price reactions, particularly if releases coincide with weak market conditions or insufficient ecosystem growth. Multiple private keys management To bridge BDX between different networks and the native Beldex blockchain, users must interact with the same cross-chain infrastructure used for outbound transfers, which requires using a compatible Beldex wallet (such as CLI, GUI, or mobile). This process demands proper handling of private keys and credentials on both sides of the bridge. Losing access to a wallet, failure of misconfigured bridge settings, or misuse of incompatible tools, can result in permanent loss of tokens. Supply invariant violation risk The native emission follows a structured block reward model with burning mechanisms for fees. In the EVM POC, value transfer occurs via proof-of-burn rather than arbitrary minting, though transitions present ongoing research challenges that could affect supply accounting if implemented.
I.4	Project implementation-related risks	Protocol upgrade and modification risk Protocol upgrades, such as the Bucephalus hardfork (PoS transition), Bern hardfork (BNS and fee burning), Obscura hardfork (Bulletproofs++ scalability), and the planned 2026 VRF-based consensus shift, require node operator and masternode coordination to update software and validate changes. Insufficient or mistimed adoption may result in chain splits, temporary network partitions, or delayed feature activation. Concentration of Token Holdings A portion of the BDX supply is allocated to designated wallets associated with ecosystem development, seed and venture funding, team incentives, and marketing activities. While these allocations are subject to defined vesting and release schedules, decisions regarding the timing and use of these tokens are coordinated by a limited number of project-related entities, which may influence governance and operational dynamics within the ecosystem. Cross-Chain Bridge Exploit Risk Cross-chain bridges are structurally complex and historically have been a frequent target of exploits across the crypto ecosystem. A successful attack on the Beldex Bridge or its interoperability layers such as LayerZero or Stargate integrations, could lead to unauthorised minting, theft, or disruption of bridged BDX, affecting token holders across all connected chains. Hardfork coordination and adoption risk Hardforks depend on masternode operators applying updates and maintaining participation during activation. Gaps in awareness, technical capability, or participation could lead to reduced liveness, conflicting chains, or prolonged transition periods until quorum consensus stabilises. Node software dependency and version fragmentation risk Beldex relies on specific daemon and wallet software versions for node and masternode operation. During upgrades or hardforks, operators running outdated or incompatible versions may cause rejected blocks, stalled consensus, or network partitions until alignment occurs. Masternode registration and collateral lock-up risk Masternode participation requires locking 10,000 BDX collateral and correct on-chain registration. Implementation errors, failed uptime proofs, or collateral mismanagement can trigger warnings, demerits, locking, or deregistration, potentially reducing network capacity during critical phases such as upgrades.
I.5	Technology-related risks	Residual smart contract vulnerability exposure Native privacy features (ring size 11, RingCT, stealth addresses) reduce traceability but do not eliminate all attack vectors. In the EVM POC, public bytecode visibility and per-contract owner controls introduce potential privacy leaks. Bridged BDX relies on smart contracts deployed on external networks such as Binance Smart Chain, Ethereum and Solana to lock, mint, burn, or transfer value across chains. Any coding errors, vulnerabilities, or logic flaws in bridge or token contracts could result in loss of funds, incorrect minting, or permanent locking of bridged tokens. While audits are referenced, audits do not eliminate the risk of undiscovered vulnerabilities. Residual Administrative and Privilege Risks The BEP-20 BDX contract on BNB Smart Chain has no centralised or renounceable ownership. Core functions (pause, upgrade, mint) are limited to LayerZero OFT mechanics and do not allow arbitrary control over funds or supply. Supporting contracts in Stargate pools or LayerZero endpoints may retain limited privileged functions (e.g., pause or configuration updates) that could disrupt availability or transfers if misused. Native Layer-1 masternode influence via staked collateral does not apply to the BEP-20 token. Risk is low due to non-custodial design, no permanent centralised admin control, and mitigation by LayerZero architecture and audits. Message delivery and finality coordination failures Native transactions rely on master node quorums and 10 confirmations for finality. Delays or quorum failures may temporarily halt block production.
I.6	Mitigation measures	Offer-related risks - Irreversibility of transactions: The BEP-20 representation on BNB Smart Chain follows BSC’s finality rules (typically 6–20 confirmations).The Beldex protocol uses unique key images within MLSAG signatures to detect and reject double-spending attempts automatically upon confirmation. Documentation and wallet tools emphasise address verification and private key security, while 10-confirmation finality and checkpoints (every 4 blocks) provide strong irreversibility guarantees that reduce reversal-related uncertainties. - Market volatility and price risk: Holders are directed to official disclaimers stating that the whitepaper provides no investment guarantees or warranties. - Custody and key management risk: Wallets support 25-word seed phrases, spend/view key pairs, and optional multisignature configurations (e.g., M-of-N) to enhance protection against loss or compromise. Beldex documentation encourages user responsibility for backups and secure storage. - Absence of statutory compensation: Clear disclaimers in the whitepaper state that the document offers no warranties, guarantees, or investment solicitations, explicitly setting holder expectations regarding the absence of external protections. Crypto-asset-related risks - Cross-chain architectural complexity: The bridge closure process included step-by-step user instructions and a cutoff date to reduce ongoing synchronisation risks, with emphasis now on native L1 privacy features. Additionally, BDX has been redeployed across BSC using LayerZero’s OFT standard. This upgrade eliminates the need for wrapped-token mechanics and custodial bridges by enabling direct minting and burning of BDX representations on BSC. The OFT framework reduces synchronisation errors and migration risks by maintaining a unified supply logic across chains, while also improving decentralisation and trust minimisation in the bridging process. - Supply invariant violation risk: Proof-of-burn mechanics in the EVM POC and native fee-burning for Flash transactions help maintain supply integrity,constant block rewards and whitepaper disclosures support monitoring. - Pausability as operational denial vector: Quorum-based consensus (requiring 7/11 validator attestations) and Byzantine fault tolerance (tolerating up to 6 faulty nodes) provide resilience against temporary halts, with documented uptime proofs and penalties. Project implementation-related risks - Protocol upgrade and modification risk: Hardfork communications (e.g., Bucephalus, Bern) provide advanced guidance for node operators, supported by quorum validation and checkpoints to limit regression impacts. Additionally, BSC’s stable PoSA consensus and LayerZero’s upgradeable OFT design allow iterative improvements with minimal disruption to bridged functionality. - Security program limitations: Open-source code and community participation are positioned as ongoing review mechanisms, supplemented by protocol-level protections such as ring signatures and economic penalties. Technology-related risks - Residual smart contract vulnerability exposure: Native cryptographic primitives (MLSAG signatures, RingCT, stealth addresses) and EVM POC iterative fixes (e.g., key exposure mitigations) provide baseline protections, with disclaimers limiting reliance on any single assessment. In addition, Audits of the LayerZero OFT contract and supporting infrastructure (Stargate pools) mitigate known vulnerabilities; public EVM bytecode allows community review, and BSC’s battle-tested runtime adds operational resilience. - Permanent administrative privilege retention: Locking and demerit systems tied to collateral create ongoing accountability for operators without requiring renunciation of influence. - Message delivery and finality coordination failures: 10-confirmation finality combined with Flash quorums for near-instant transactions and checkpoint snapshots every 4 blocks enhance reliability and limit reorg risks.

Index

General information

Part A - Information about the offeror or the person seeking admission to trading

Part B - Information about the issuer, if different from the offeror or person seeking admission to trading

Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114

Part D - Information about the crypto-asset project

Part E - Information about the offer to the public of crypto-assets or their admission to trading

Part F - Information about the crypto-assets

Part G - Information on the rights and obligations attached to the crypto-assets

Part H – Information on underlying technology

Part I - Information on risks

Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts