White paper drafted under the European Markets in Crypto-Assets Regulation (EU) 2023/1114 for FFG F9SZWWB89

The Decred (DCR) crypto-asset to which this white paper refers is a crypto-asset other than an EMT or ART. It is native to the Decred blockchain and, according to the DTI FFG shown in F.14, is also available on the Tron blockchain as of 2026-08-05. The maximum supply of DCR is capped by the consensus rules at approximately 21,000,000 DCR. The genesis block of the Decred blockchain was mined on 2016-02-08 (block hash: 298e5cc3d985bfe7f81dc135f360abe089edd4396b86d2de66b0cef42b21d980; source: https://dcrdata.decred.org/block/298e5cc3d985bfe7f81dc135f360abe089edd4396b86d2de66b0cef42b21d980, accessed 2026-08-05). While a DCR token contract was deployed on the Tron blockchain on 2021-05-07, it has recorded no token transfers since deployment, and this white paper therefore addresses the Decred blockchain alone (source: https://tronscan.org/token20/TG3t9VrhcAmtqniCaCjsZpDd8XW5cXtxiB/transfers, accessed 2026-08-05).

Decred is a public, permissionless blockchain network that launched in 2016, designed around stakeholder governance of the protocol and its funding. It operates a hybrid consensus mechanism in which proof-of-work mining is combined with a proof-of-stake layer, so that holders who lock DCR to purchase voting tickets participate in validating blocks and in deciding protocol changes. Stakeholder voting extends to the allocation of the network treasury, which is funded from the block reward, giving the project a self-funded decentralised governance structure.

DCR is the native coin of the Decred blockchain. It is used to pay transaction fees, to reward miners and ticket voters who secure the network, and to fund treasury spending approved by stakeholders. Holding DCR is the means by which a participant acquires voting tickets and so takes part in the network's consensus and governance processes.

The crypto-asset does not grant any legally enforceable or contractual rights or obligations to its holders or purchasers. Any functionalities accessible through the underlying technology are purely technical or operational in nature and do not confer rights comparable to ownership, profit participation, governance, or similar entitlements known from traditional financial instruments.

As defined in Article 3(9) of Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on Markets in Crypto-Assets – amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937 – a utility token is “a type of crypto-asset that is only intended to provide access to a good or a service supplied by its issuer”. This crypto-asset does not qualify as a utility token, as its intended use goes beyond providing access to a good or a service supplied solely by the issuer.

Company Zero LLC is seeking admission to trading on the Payward Global Solutions LTD (“Kraken”) platform in the European Union in accordance with Article 5 of Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on Markets in Crypto-Assets, amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937. The admission to trading is not accompanied by a public offer of the crypto-asset.

Company Zero LLC is a specialised software-development firm focused on blockchain and communications software intended to support individual liberty and personal security. Its principal activities include software work associated with btcsuite, Decred and Bison Relay.

The following financial information covers 2024 and 2025. All amounts are stated in US dollars.

- 2024: Recorded revenue of USD 278,587 and a loss of USD 446,175. Equity was USD 4,507, and cash and cash equivalents were USD 103,373.

- 2025: Recorded revenue of USD 278,534 and a loss of USD 417,466. Equity was nil, and cash and cash equivalents were USD 156,143.

Revenue remained effectively unchanged between 2024 and 2025. The annual loss decreased by USD 28,709, or 6.4%, while cash and cash equivalents increased by USD 52,770, or 51.1%. Equity decreased from USD 4,507 to nil.

Decred is a public, permissionless Layer 1 blockchain network that has operated since its mainnet launch on 2016-02-08. It uses a hybrid consensus mechanism combining Proof-of-Work mining with Proof-of-Stake ticket voting. A holder participates by time-locking DCR to purchase a ticket at the protocol-determined ticket price; the ticket enters the live ticket pool and, once selected, votes, after which the locked DCR is returned to the holder together with the applicable reward. Five tickets are selected pseudorandomly for each block, giving ticket holders a direct role in validating the work of miners. Ticket holders also decide the future of the protocol: consensus rule changes are approved by on-chain ticket voting, and spending from the network treasury, which receives 10 per cent of each block reward, is approved by ticket holders through the Politeia proposal system.

DCR is the native coin of the Decred blockchain, with a supply capped by the consensus rules at approximately 21,000,000 DCR. It is used to pay transaction fees, to reward the miners and ticket voters who secure the network, and to fund treasury spending approved by ticket holders. Purchasing a ticket is the means by which a holder takes part in block validation, consensus rule voting and treasury governance. DCR is not tied to any single application and is not limited to accessing a good or service supplied by any person.

The project is maintained by a decentralised network of independent participants and does not rely on a single controlling entity. Certain organisations, including Company Zero LLC, contribute to protocol development and ecosystem support activities; however, such contributions do not constitute control over the network. Consensus rule changes and treasury spending require approval by ticket holders, and the ongoing development and evolution of the protocol depend on distributed community participation and may vary over time based on technical and operational considerations.

This section provides an overview of the historical developments related to the DCR crypto-asset and a description of planned or anticipated project milestones. All forward-looking elements are subject to significant uncertainty. They do not constitute commitments, assurances or guarantees, and may be modified, delayed or discontinued at any time.

Past milestones:

- Mainnet launch and initial distribution - 8 February 2016. The network launched with an 8 per cent premine, divided equally between the initial development team and 2,972 registered participants. No ICO or public token sale took place.

- First Proof-of-Stake block votes - 21 February 2016. Start of Decred’s hybrid consensus: DCR holders can time-lock DCR to obtain tickets, and selected tickets vote on whether to validate the preceding Proof-of-Work-mined block. At least three ticket votes are required for a block to be valid.

- First consensus-rule vote - 9 July 2017. Ticket holders first used the on-chain voting process to approve a change to the consensus rules.

- Politeia launched - 15 October 2018. Politeia is Decred’s proposal, discussion and voting platform. It is used for higher-level governance matters, including Treasury expenditure and policy decisions; voting is cast by eligible ticket holders and proposal data is cryptographically anchored to the Decred blockchain.

- Lightning Network support activated on mainnet — 9 May 2019. This added support for off-chain payment channels, intended to permit smaller or more frequent payments without recording every payment directly on the Decred blockchain.

- CoinShuffle++ mixing introduced - 28 August 2019. CoinShuffle++ is an optional, non-custodial CoinJoin-style mixing feature. It seeks to make it more difficult to link mixed DCR outputs to their prior inputs, but transaction amounts remain visible and privacy depends on user behaviour, including avoiding address reuse.

- DCRDEX integrated into Decred software - 25 January 2021. DCRDEX is a decentralised exchange for peer-to-peer trading of supported crypto-assets. It uses cross-chain atomic swaps so that a DCRDEX server does not take custody of users’ funds during a trade.

- Decentralised Treasury enabled - 9 April 2021. DCP-0006 enabled the Treasury architecture under which approved Treasury expenditure can be processed on-chain, replacing the earlier custodial arrangement for Treasury funds.

- First substantial subsidy reallocation - 8 May 2022. Following DCP-0010, the block subsidy changed from 60 per cent Proof-of-Work, 30 per cent Proof-of-Stake and 10 per cent Treasury to 10 per cent, 80 per cent and 10 per cent respectively. This increased the share allocated to selected voting-ticket holders.

- Bison Relay launched - 15 December 2022. Bison Relay is a communications and social-media application that uses Decred’s Lightning Network for micropayments.

- BLAKE3 Proof-of-Work and revised subsidy split activated - 29 August 2023. BLAKE3 is a cryptographic hash function used here for the Proof-of-Work mining puzzle, replacing the prior Proof-of-Work algorithm. The same activation changed the block-subsidy allocation to 1 per cent for miners, 89 per cent for Proof-of-Stake voters and 10 per cent for the Treasury. It did not change the maximum supply.

- Treasury expenditure policy locked in, 11 January 2026; activated, 8 February 2026. DCP-0013 replaced the previous maximum-expenditure rules with a consensus-enforced policy whose target limit is 4% of the Treasury balance over a 6,912-block expenditure-policy window, approximately 24 days.

Future milestones:

- Continued protocol hardening of the dcrd full node implementation, including work on the connection manager and on cryptographic performance.

- Further development and testing of Rust-based Decred libraries, including dcr-rs, which provides Decred transaction, address, key-derivation and signing primitives.

- Expansion of the KeyOS Passport Prime hardware-signing ecosystem, including an inheritance tooling application.

Note: All future milestones are subject to significant uncertainty, including but not limited to technical feasibility, regulatory developments, market adoption and community governance decisions. The project may modify, delay or discontinue any of these initiatives at any time. Past implementation or performance outcomes do not constitute an indication of future results, and any such changes may materially affect the characteristics, availability or perceived value of the DCR crypto-asset for its holders.

No capital has been raised for the Decred project through external funding rounds or prior token sales. No initial coin offering, public token sale, seed round, venture round or angel round has been conducted, and Company Zero LLC has raised no external capital for the project.

Development work carried out before the launch of the mainnet in 2016 was funded out of pocket by the development team behind the project and compensated at launch through a premine rather than through external investment. The bring-up costs so compensated amounted to approximately USD 415,000, comprising approximately USD 300,000 in development costs already paid to developers and approximately USD 115,000 for unpaid work and for purchases made by developers individually.

At the launch of the Decred mainnet on 2016-02-08, a premine of 1,680,000 DCR (source: https://dcrdata.decred.org/tx/5e29cdb355b3fc7e76c98a9983cd44324b3efdd7815c866e33f6c72292cb8be6, accessed 2026-08-05), being 8 per cent of the maximum supply, was distributed in a single transaction. Half of that amount, 840,000 DCR, was allocated to Company Zero LLC and its developers in compensation for the bring-up costs described above, at a rate of USD 0.49 per DCR, whether purchased or exchanged for work performed. The remaining 840,000 DCR was distributed evenly to 2,972 participants in the launch airdrop, being 282.63795424 DCR each. The developers and project members committed not to trade their premined DCR for twelve months from launch and Company Zero LLC committed to a period of twenty-four months. The premine is a historical event at the launch of the network and does not form part of the current allocation of resources to the project.

The Decred project is funded on an ongoing basis from its own block rewards rather than from external sources. The protocol credits 10% of each block subsidy to the project treasury. Expenditure from the treasury is decided by DCR stakeholders through the project's on-chain proposal and voting platform, and no single person or entity may direct it.

Not applicable, as this white paper serves the purpose of admission to trading and is not associated with any fundraising activity for the crypto-asset project.

The purpose of seeking admission to trading is to enable the crypto-asset to be listed on a regulated platform in accordance with the applicable provisions of Regulation (EU) 2023/1114 and Commission Implementing Regulation (EU) 2024/2984. The white paper has been drawn up to comply with the transparency requirements applicable to trading venues.

Holder restrictions are subject to the rules applicable to the crypto-asset service provider, as well as any additional restrictions that provider may impose.

The costs involved in accessing the trading platform depend on the specific fee structure and terms of the respective crypto-asset service provider. These may include trading fees, deposit or withdrawal charges, and network-related gas fees. Investors are advised to consult the applicable fee schedule of the chosen platform before engaging in trading activities.

Not applicable, as this white paper is written to seek admission to trading, not for the initial offer to the public.

Not applicable, as this white paper is written to seek admission to trading, not for the initial offer to the public.

MiCA-compliant crypto-asset service providers should have robust measures for managing conflicts of interest. Given the broad audience addressed by this white paper, prospective investors should review their counterparty’s conflicts-of-interest policy.

Not applicable, as this white paper is written to seek admission to trading, not for the initial offer to the public.

Not applicable, as this white paper is written to seek admission to trading, not for the initial offer to the public.

DCR is the native crypto-asset of the Decred blockchain, a standalone Layer-1 network with its own consensus rules. It is used as a means of transferring and holding value on that network, to pay the transaction fees required to have transactions included in a block, and as the collateral that enables participation in the network's consensus mechanism and governance.

Holders may time-lock DCR to purchase tickets under the network's Proof-of-Stake mechanism. In each block, five tickets are selected pseudo-randomly and called to vote. Those votes serve two functions: they approve or reject the preceding block produced by a Proof-of-Work miner, where at least three of the five votes are required for the block to stand, and they decide whether proposed changes to the consensus rules take effect, where approval requires 75 per cent of non-abstaining tickets. When a ticket is called to vote, the DCR locked in it is unlocked and returned to the holder's wallet together with the Proof-of-Stake reward where the ticket voted successfully.

Ticket holders also decide how the network's treasury is spent. Proposals for funding and for higher-level policy matters are put to ticket holders on the project's Politeia platform, and funds are released only where a proposal is approved. No single person or entity may direct treasury expenditure.

The treasury is funded from the block reward rather than from any external source. Of each block reward, 1 per cent is allocated to the Proof-of-Work miner who produced the block, 89 per cent to the five Proof-of-Stake voters on that block, being 17.8 per cent to each, and 10 per cent to the treasury. The block subsidy reduces by approximately 1 per cent every 6,144 blocks, being roughly every 21 to 22 days, and the upper limit on the total supply is 20,999,999.98387408 DCR.

The DCR crypto-asset does not confer ownership, profit participation, governance rights over Company Zero LLC or any related entity in a corporate-law sense, or any form of legally enforceable economic entitlement. All functionalities associated with DCR are technical in nature and relate exclusively to interactions within the Decred network. The voting described above is participation in the technical operation of that network and does not constitute a shareholder or membership right against any legal person. The actual usability of DCR depends on factors including system stability, governance decisions, development progress, and the operational conditions of the Decred blockchain, which are outside the control of holders.

Future milestones:

- Continued protocol hardening of the dcrd full node implementation, including work on the connection manager and on cryptographic performance.

- Further development and testing of Rust-based Decred libraries, including dcr-rs, which provides Decred transaction, address, key-derivation and signing primitives.

- Expansion of the KeyOS Passport Prime hardware-signing ecosystem, including an inheritance tooling application.

Note: All future milestones are subject to significant uncertainty, including but not limited to technical feasibility, regulatory developments, market adoption and community governance decisions. The project may modify, delay or discontinue any of these initiatives at any time. Past implementation or performance outcomes do not constitute an indication of future results, and any such changes may materially affect the characteristics, availability or perceived value of the DCR crypto-asset for its holders.

The crypto-asset referred to herein is a crypto-asset other than an EMT or ART and is natively implemented on the Decred blockchain. DCR is divisible to eight decimal places. The functionally fungible group identified by the FFG DTI in F.14 includes a DCR token contract on the Tron blockchain, deployed on 2021-05-07 (contract address TG3t9VrhcAmtqniCaCjsZpDd8XW5cXtxiB; source: https://tronscan.org/token20/TG3t9VrhcAmtqniCaCjsZpDd8XW5cXtxiB/transfers, accessed 2026-08-05). That contract has recorded no transfers since deployment. It therefore carries no transaction activity, no economic activity attributable to DCR, and no energy consumption or associated adverse climate impacts capable of being attributed to it on the activity-proportional basis described in S.9. The information on the underlying technology in Part H and the sustainability indicators in Part J accordingly relate to the Decred blockchain alone. Should transfer activity arise on the Tron implementation, the effect on this white paper will be assessed under Article 12 of Regulation (EU) 2023/1114. The crypto-asset does not confer ownership, profit participation, or any other legally enforceable rights against any person. Governance and reward functions available to holders arise at protocol level and are not contractual entitlements. Any functionalities associated with the token are limited to potential technical features within the relevant platform environment. These functionalities do not represent contractual entitlements and may depend on future development decisions, technical design choices, and operational conditions. The crypto-asset does not embody intrinsic economic value; instead, its value, if any, is determined exclusively by market dynamics such as supply, demand, and liquidity in secondary markets.

No such services are currently provided by the issuer.

The crypto-asset does not grant any legally enforceable or contractual rights or obligations to its holders or purchasers. Any functionalities accessible through the underlying technology are of a purely technical or operational nature and do not constitute rights comparable to ownership, profit participation, governance, or similar entitlements known from traditional financial instruments. Accordingly, holders do not acquire any legally enforceable claim against the issuer of the crypto-asset or any third party.

As the crypto-asset does not confer any legally enforceable rights or obligations, there are no applicable procedures or conditions for their exercise. Any interaction or functionality that may be available within the project’s technical infrastructure – such as participation mechanisms or protocol-level features – serves operational purposes only and does not create, evidence, or constitute any contractual or statutory entitlement.

As the crypto-asset does not confer any legally enforceable rights or obligations, there are no conditions or mechanisms for modifying such rights or obligations. Adjustments to the technical protocol, smart contract logic, or related systems may occur in the ordinary course of development or maintenance. Such changes do not alter the legal position of holders, as no contractual rights exist and no rights arise under applicable law or regulation. Holders should not interpret technical updates or governance-related changes as amendments to legally binding entitlements.

No future public offers of crypto-assets are currently planned.

The crypto-assets themselves are not subject to any technical or contractual transfer restrictions and are generally freely transferable. However, crypto-asset service providers may impose restrictions on buyers or sellers in accordance with applicable laws, internal policies or contractual terms agreed with their clients.

Not applicable.

Not applicable, as the crypto-asset in scope does not have any value protection scheme in place.

Not applicable, as the crypto-asset in scope does not have any compensation scheme in place.

Applicable law likely depends on the location of any particular transaction with the token.

Competent court likely depends on the location of any particular transaction with the token.

The disclosures in this Part relate to the Decred blockchain only, for the reasons set out in F.6.

This information relates to the Decred blockchain. The crypto-asset follows the standards described below.

The following applies to Decred:

1. Network and governance protocols

The base-layer protocol combines Proof-of-Work miners, which select transactions and construct candidate blocks, with Proof-of-Stake voters, which vote on the validity of the preceding block and participate in decisions concerning changes to the consensus rules.

- Each block must contain votes from at least three of five tickets selected from the eligible ticket pool.

- Politeia is an off-chain governance system used for the submission, discussion and voting of proposals relating to project policy, budgets and other non-consensus matters.

- The Decred Lightning Network implementation, dcrlnd, operates as a Layer 2 protocol. It uses payment channels to process transactions outside the base-layer blockchain, with subsequent settlement on the Decred network.

- CoinShuffle++ is a non-custodial protocol through which participating users can combine transactions without transferring control of their DCR to a central intermediary.

2. Protocol specification and upgrade standards

Decred Change Proposals are formal technical documents used to describe proposed changes to the protocol or consensus rules. A Decred Change Proposal normally sets out the proposed change, its rationale and a corresponding reference implementation. The consensus rules are implemented and enforced through the full-node software. Code relating to a proposed consensus change may be included in a software release in an inactive state. It becomes enforceable only after the applicable upgrade thresholds and stakeholder voting requirements have been satisfied. Before voting on a consensus change can begin, the relevant software version must be in use for at least 95% of the latest 1,000 Proof-of-Work blocks and 75% of the Proof-of-Stake votes in the applicable interval. Stakeholders then vote during a period of 8,064 blocks using “Yes”, “No” or “Abstain” votes. The proposal requires a quorum of 10% and at least 75% affirmative votes, excluding abstentions, to pass. An approved change is activated following the applicable lock-in interval, which is approximately four weeks. Non-consensus matters, including project budgets and proposed Treasury expenditure, are addressed through Politeia. Politeia proposals generally require at least 60% approval and participation by at least 20% of the eligible ticket pool.

3. Cryptographic and networking standards

- Decred uses BLAKE-256 with 14 rounds for block identifiers. Following the relevant protocol change in 2023, BLAKE3 is used for the Proof-of-Work calculation.

- Transaction authorisation uses elliptic-curve digital signatures. The protocol also supports Schnorr signatures for applicable transaction and script types.

- Transactions and blocks are propagated through a peer-to-peer network.

- Simplified Payment Verification wallets may use compact block filters to identify relevant transactions without disclosing all wallet addresses to full nodes.

- Wallet implementations may use mnemonic recovery mechanisms, including implementations based on BIP-0039.

- Network traffic may be routed through Tor where supported by the relevant software configuration.

- Politeia participants use public and private key pairs to sign proposals and comments. Submission records can be accompanied by censorship tokens that provide evidence of receipt.

- Politeia records are cryptographically anchored to the Decred blockchain through dcrtime. Trillian-based verifiable logs are used to maintain an auditable record of governance data.

This information relates to the Decred blockchain. The crypto-asset follows the standards described below.

The following applies to Decred:

Decred uses a UTXO-based blockchain derived from the Bitcoin transaction model. Transactions consume existing unspent transaction outputs and create new outputs. Valid outputs are recorded in the UTXO set and may subsequently be spent by a transaction satisfying the applicable locking conditions.

Blocks are produced at an intended average interval of approximately five minutes. Each block contains a regular transaction tree and a separate stake transaction tree. Blocks can be identified by their block hash and their sequential height within the blockchain.

Transactions are normally constructed and signed using wallet software, including the Decrediton graphical wallet and dcrwallet. The protocol uses a script-based execution model rather than a general-purpose, Turing-complete virtual machine. Supported functions include redeem scripts, multisignature arrangements, hashed time-locked contracts and on-chain atomic swaps. Signature Script Isolation separates transaction signatures from certain transaction data for the purposes of transaction processing and identification.

The Lightning Network uses two-party payment channels and hashed time-locked contracts for off-chain transfers. Politeia provides off-chain storage and processing of governance proposals, while cryptographic proofs of its records are anchored to the Decred blockchain. CoinShuffle++ provides non-custodial transaction mixing through coordinated multi-party transactions.

This information relates to the Decred blockchain. The crypto-asset follows the standards described below.

The following applies to Decred:

Decred is a Layer-1 network operating under its own protocol and is not a token or smart contract deployed on another blockchain. It uses a hybrid Proof-of-Work and Proof-of-Stake consensus mechanism. Proof-of-Work miners order transactions, construct candidate blocks and perform the computational work required for block production. Proof-of-Stake participants review the miners’ work by voting with tickets that represent time-locked DCR.

A person may participate in Proof-of-Stake by purchasing a ticket at the protocol-determined ticket price. The committed DCR remains locked while the ticket is live. Tickets become eligible after the applicable maturity period and enter the live ticket pool. A live ticket may be selected to vote, may miss a call to vote or may expire without being selected. Following a vote, or the applicable revocation process for a missed or expired ticket, the committed DCR is released after the required maturity period.

For each block, five tickets are selected pseudorandomly from the live ticket pool. These tickets form a temporary voting committee for that block height. A mined block must include votes from at least three of the five selected tickets to satisfy the applicable validity requirements. Those votes also approve or reject the regular transaction tree of the preceding block. If a majority of the included votes approves it, the regular transaction tree is accepted. If a majority rejects it, or the included votes are tied, the regular transaction tree is rejected and its non-stake transactions may be returned to the transaction pool. The separate stake transaction tree remains subject to the applicable consensus rules.

Ticket holders may vote using their own continuously available wallet or may use a Voting Service Provider. A Voting Service Provider may be authorised to cast votes on behalf of a ticket holder but does not receive control of the DCR committed to the ticket.

Decred has probabilistic finality. The probability of a chain reorganisation generally decreases as additional valid blocks are added. A competing chain must satisfy both the applicable Proof-of-Work requirements and the Proof-of-Stake voting requirements. A prospective reorganisation must therefore obtain sufficient participation in both components of the consensus process.

Changes to the consensus rules are not implemented solely through off-chain governance decisions. A consensus change must be implemented in compatible node software and approved through the applicable on-chain stakeholder voting process before activation.

This information relates to the Decred blockchain. The crypto-asset follows the standards described below.

The following applies to Decred:

Decred uses block subsidies, transaction fees, Proof-of-Stake rewards and Treasury funding to incentivise participation in block production, transaction validation, stakeholder voting and network development. The block subsidy is multiplied by 100/101 every 6,144 blocks, corresponding to approximately 21.33 days at the intended block interval. Following the subsidy allocation change activated in 2023, each block subsidy is distributed as follows:

- 1% is allocated to the Proof-of-Work miner;

- 89% is allocated among the Proof-of-Stake voters; and

- 10% is allocated to the Decred Treasury.

Where all five selected tickets vote, each voter is eligible to receive 17.8% of the total block subsidy. The DCR committed to the ticket is also released following completion of the applicable voting or revocation process and the subsequent maturity period. The released ticket price is the return of locked DCR and is not a newly issued reward.

Proof-of-Work miners receive the applicable miner portion of the block subsidy and the transaction fees associated with regular transactions included in the block. Transaction fees are paid by the person submitting the transaction and are generally determined by the size of the signed transaction. These fees are assigned to the miner rather than burned or transferred to the Treasury.

Ticket purchase transactions are also subject to network fees. A ticket holder may select a higher fee rate to increase the likelihood that the ticket purchase is included when demand for tickets exceeds the number permitted in a block. Transaction fees paid for a ticket purchase are not returned if the ticket is included and the ticket subsequently expires. A Voting Service Provider may charge a separate service fee under its own terms.

The Proof-of-Work subsidy is adjusted according to the number of Proof-of-Stake votes included in the block. If fewer than five votes are included, the miner’s subsidy is reduced proportionately. For example, inclusion of three votes results in the miner receiving 60% of the otherwise applicable Proof-of-Work subsidy.

If the included Proof-of-Stake votes reject the preceding block’s regular transaction tree, including where the votes are tied, the Proof-of-Work miner does not retain the subsidy and transaction fees associated with that rejected regular transaction tree. A selected ticket that fails to vote does not receive a Proof-of-Stake reward. The DCR committed to the missed ticket is not subject to principal slashing and can be returned through a revocation transaction following the applicable maturity period, subject to the applicable transaction fee.

The Treasury receives 10% of each block subsidy under the consensus rules. Eligible ticket holders vote on budget and policy proposals through Politeia, an off-chain proposal system whose records are cryptographically anchored to the Decred blockchain. Approval of a Politeia proposal does not itself create or disburse DCR. Treasury payments are made from accumulated Treasury funds through separately authorised Treasury-spend transactions that are subject to the applicable on-chain ticket-holder voting and consensus expenditure rules. Treasury funds may be used to pay persons performing approved work for the Decred project.

Within the Lightning Network, routing nodes may receive fees for forwarding off-chain payments. If a channel participant broadcasts a revoked channel state, the applicable penalty mechanism permits a justice transaction to transfer the disputed channel balance in accordance with the previously agreed channel conditions.

Not applicable, as the DLT is not operated by the issuer, the offeror, the person seeking admission to trading, or any third party acting on their behalf.

1. Regulatory and Compliance

Regulatory frameworks applicable to crypto-asset services in the European Union and in third countries are evolving. Supervisory authorities may introduce, interpret, or enforce rules that affect (i) the eligibility of this crypto-asset for admission to trading, (ii) the conditions under which a crypto-asset service provider may offer trading, custody, or transfer services for it, or (iii) the persons or jurisdictions to which such services may be provided. As a result, the crypto-asset service provider admitting this crypto-asset to trading may be required to suspend, restrict, or terminate trading or withdrawals for regulatory reasons, even if the crypto-asset itself continues to function on its underlying network.

2. Trading venue and connection risk

Trading in the crypto-asset depends on the uninterrupted operation of the trading venues on which it is listed and, where applicable, on its technical connections to external liquidity sources or venues. Interruptions such as system downtime, maintenance, faulty integrations, API changes, or failures at an external venue can temporarily prevent order placement, execution, deposits, or withdrawals, even when the underlying blockchain is functioning. In addition, trading platforms in emerging markets may operate under differing governance, compliance, and oversight standards, which can increase the risk of operational failures or disorderly market conditions.

3. Market formation and liquidity conditions

The price and tradability of the crypto-asset depend on actual trading activity on the venues to which the service provider is connected, whether centralised exchanges (CEXs) or decentralised exchanges (DEXs). Trading volumes may at times be low, order books thin, or liquidity concentrated on a single venue. In such conditions, buy or sell orders may not be executed in full or may be executed only at a less favourable price, resulting in slippage.

Volatility: The market price of the crypto-asset may fluctuate significantly over short periods, including for reasons that are not linked to changes in the underlying project or protocol. Periods of limited liquidity, shifts in overall market sentiment, or trading on only a small number of CEXs or DEXs can amplify these movements and lead to higher slippage when orders are executed. As a result, investors may be unable to sell the crypto-asset at or close to a previously observed price, even where no negative project-specific event has occurred.

4. Counterparty and service provider dependence

The admission of the crypto-asset to trading may rely on several external parties, such as connected centralised or decentralised trading venues, liquidity providers, brokers, custodians, or technical integrators. If any of these counterparties fail to perform, suspend their services, or apply internal restrictions, the trading, deposit, or withdrawal of the crypto-asset on the listing crypto-asset service provider can be interrupted or halted.

Quality of counterparties: Trading venues and service providers in certain jurisdictions may operate under regulatory or supervisory standards that are lower or differently enforced than those applicable in the European Union. In such environments, deficiencies in governance, risk management, or compliance may remain undetected, which increases the probability of abrupt service interruptions, investigations, or forced wind-downs.

Delisting and service suspension: The crypto-asset’s availability may depend on the internal listing decisions of these counterparties. A delisting or suspension on a key connected venue can materially reduce liquidity or make trading temporarily impossible on the admitting service provider, even if the underlying crypto-asset continues to function.

Insolvency of counterparties: If a counterparty involved in holding, routing, or settling the crypto-asset becomes insolvent, enters restructuring, or is otherwise subject to resolution measures, assets held or processed by that counterparty may be frozen, become temporarily unavailable, or be recoverable only in part or not at all, which can result in losses for clients whose positions were maintained through that counterparty. This risk applies in particular where client assets are held on an omnibus basis or where segregation is not fully recognised in the counterparty’s jurisdiction.

5. Operational and information risks

Due to the irrevocability of blockchain transactions, incorrect transaction approvals or the use of wrong networks or addresses will typically make the transferred funds irrecoverable. Because trading may also rely on technical connections to other venues or service providers, downtime or faulty code in these connections can temporarily block trading, deposits, or withdrawals even when the underlying blockchain is functioning. In addition, different groups of market participants may have unequal access to technical, governance, or project-related information, which can lead to information asymmetry and place less informed investors at a disadvantage when making trading decisions.

6. Market access and liquidity concentration risk

If the crypto-asset is only available on a limited number of trading platforms or through a single market-making entity, this may result in reduced liquidity, greater price volatility, or periods of inaccessibility for retail holders.

1. Insolvency of the issuer

As with any commercial entity, the issuer may face insolvency risks. These may result from insufficient funding, low market interest, mismanagement, or external shocks (e.g. pandemics, armed conflicts). In such a case, ongoing development, support, and governance of the project may cease, potentially affecting the viability and tradability of the crypto-asset.

2. Legal and regulatory risks

The issuer operates in a dynamic and evolving regulatory environment. Failure to comply with applicable laws or regulations in relevant jurisdictions may result in enforcement actions, penalties, or restrictions on the project’s operations. These may negatively impact the crypto-asset’s availability, market acceptance, or legal status.

3. Operational risks

The issuer may fail to implement adequate internal controls, risk management, or governance processes. This can result in operational disruptions, financial losses, delays in updating the white paper, or reputational damage.

4. Governance and decision-making

The issuer’s management body is responsible for key strategic, operational, and disclosure decisions. Ineffective governance, delays in decision-making, or lack of resources may compromise the stability of the project and its compliance with MiCA requirements. High concentration of decision-making authority or changes in ownership/control can amplify these risks.

5. Reputational risks

The issuer’s reputation may be harmed by internal failures, external accusations, or association with illicit activity. Negative publicity can reduce trust in the issuer and impact the perceived legitimacy or value of the crypto-asset.

6. Counterparty dependence

The issuer may depend on third-party providers for certain core functions, such as technology development, marketing, legal advice, or infrastructure. If these partners discontinue their services, change ownership, or underperform, the issuer’s ability to operate the project or maintain investor communication may be impaired. This could disrupt project continuity or undermine market confidence, ultimately affecting the crypto-asset’s value.

1. Valuation risk

The crypto-asset does not represent a claim, nor is it backed by physical assets or legal entitlements. Its market value is driven solely by supply and demand dynamics and may fluctuate significantly. In the absence of fundamental value anchors, such assets can lose their entire market value within a very short time. Historical market behaviour has shown that some types of crypto-assets have become worthless. Investors should be aware that this crypto-asset may lose all of its value.

2. Market volatility risk

Crypto-asset prices can fluctuate sharply due to changes in market sentiment, macroeconomic conditions, regulatory developments, or technology trends. Such volatility may result in rapid and significant losses. Holders should be prepared for the possibility of losing the full amount invested.

3. Liquidity and price-determination risk

Low trading volumes, fragmented trading across venues, or the absence of active market makers can restrict the ability to buy or sell the crypto-asset. In such situations, it is not guaranteed that an observable market price will exist at all times. Spreads may widen materially, and orders may only be executable under unfavourable conditions, which can make liquidation costly or temporarily impossible.

4. Crypto-asset security risk

Loss or theft of private keys, unauthorised access to wallets, or failures of custodial or exchange service providers can result in the irreversible loss of assets. Because blockchain transactions are final, recovery of funds after a compromise is generally impossible.

5. Fraud and scam risk

The pseudonymous and irreversible nature of blockchain transactions can attract fraudulent schemes. Typical forms include fake or unauthorised crypto-assets imitating established ones, phishing attempts, deceptive airdrops, or social-engineering attacks. Investors should exercise caution and verify the authenticity of counterparties and information sources.

6. Legal and regulatory reclassification risk

Legislative or regulatory changes in the European Union or in the Member State where the crypto-asset is admitted to trading may alter its legal classification, permitted uses, or tradability. In third countries, the crypto-asset may be treated as a financial instrument or security, which can restrict its offering, trading, or custody.

7. Absence of investor protection

The crypto-asset is not covered by investor-compensation or deposit-guarantee schemes. In the event of loss, fraud, or insolvency of a service provider, holders may have no access to recourse mechanisms typically available in regulated financial markets.

8. Counterparty risk

Reliance on third-party exchanges, custodians, or intermediaries exposes holders to operational failures, insolvency, or fraud of these parties. Investors should conduct due diligence on service providers, as their failure may lead to the partial or total loss of held assets.

9. Reputational risk

Negative publicity related to security incidents, misuse of blockchain technology, or associations with illicit activity can damage public confidence and reduce the crypto-asset’s market value.

10. Community and sentiment risk

Because the crypto-asset’s perceived relevance and expected future use depend largely on community engagement and the prevailing sentiment, a loss of public interest, negative coverage or reduced activity of key contributors can materially reduce market demand.

11. Macroeconomic and interest-rate risk

Fluctuations in interest rates, exchange rates, general market conditions, or overall market volatility can influence investor sentiment towards digital assets and affect the crypto-asset’s market value.

12. Taxation risk

Tax treatment varies across jurisdictions. Holders are individually responsible for complying with all applicable tax laws, including the reporting and payment of taxes arising from the acquisition, holding, or disposal of the crypto-asset.

13. Anti-money-laundering and counter-terrorist financing risk

Wallet addresses or transactions connected to the crypto-asset may be linked to sanctioned or illicit activity. Regulatory responses to such findings may include transfer restrictions, reporting obligations, or the freezing of assets on certain venues.

14. Market-abuse risk

Due to limited oversight and transparency, crypto-assets may be vulnerable to market-abuse practices such as spoofing, pump-and-dump schemes, or insider trading. Such activities can distort prices and expose holders to sudden losses.

15. Legal ownership and jurisdictional risk

Depending on the applicable law, holders of the crypto-asset may not have enforceable ownership rights or effective legal remedies in cases of disputes, fraud, or service failure. In certain jurisdictions, access to exchanges or interfaces may be restricted by regulatory measures, even if on-chain transfer remains technically possible.

16. Concentration risk

A large proportion of the total supply may be held by a small number of holders. This can enable market manipulation, governance dominance, or sudden large-scale liquidations that adversely affect market stability, price levels, and investor confidence.

As this white paper relates to admission to trading of the crypto-asset, the risk description below reflects general implementation risks typically associated with crypto-asset projects and relevant for the crypto-asset service provider.

Delays, failures, or changes in the implementation of the project as outlined in its public roadmap or technical documentation may negatively impact the perceived credibility or usability of the crypto-asset. This includes risks related to project governance, resource allocation, technical delivery, and team continuity.

Key-person risk: The project may rely on a limited number of individuals for development, maintenance, or strategic direction. The departure, incapacity, or misalignment of these individuals may delay or derail the implementation.

Timeline and milestone risk: Project milestones may not be met as announced. Delays in feature releases, protocol upgrades, or external integrations can undermine market confidence and affect the adoption, use, or value of the crypto-asset.

Delivery risk: Even if implemented on time, certain functionalities or integrations may not perform as intended or may be scaled back during execution, limiting the crypto-asset’s practical utility.

As this white paper relates to admission to trading of the crypto-asset, the following risks concern the underlying distributed ledger technology (DLT), its supporting infrastructure, and related technical dependencies. Failures or vulnerabilities in these systems may affect the availability, integrity, or transferability of the crypto-asset.

1. Blockchain dependency risk

DCR is native to the Decred blockchain and depends on the continuous and stable operation of that network. Proof-of-Work miners produce candidate blocks and Proof-of-Stake ticket voters participate in validating the miners' work. Network congestion, insufficient mining or voting participation, software faults, denial-of-service attacks or communications outages may delay transaction inclusion or confirmation, or temporarily prevent the production of valid blocks. Extended disruption or degradation may affect transfers, settlement, ticket participation and the usability of DCR.

2. Protocol and software vulnerability risk

The Decred consensus rules and the software used to implement them, including full-node, wallet, mining, voting and Lightning Network software, may contain coding errors, security vulnerabilities or incompatible behaviour. A defect in an implementation or an improperly coordinated software upgrade may cause transactions or blocks to be rejected, impair wallet or voting functionality, contribute to a chain reorganisation or disrupt network operation. Exploitation of a vulnerability may result in loss of funds or other unintended consequences.

3. Wallet and key-management risk

Holding and transferring DCR depends on secure private key management. Loss, theft or compromise of private keys or wallet recovery information may result in irreversible loss of access. Custodians, trading venues and wallet providers may also be targeted by cyberattacks. Participation in Proof-of-Stake voting introduces an additional operational risk because DCR committed to a ticket remains temporarily locked and a missed vote results in the loss of the associated reward, although the committed DCR remains returnable.

Outdated or vulnerable wallet software:

Users relying on outdated, unaudited or unsupported wallet software may face compatibility issues, security vulnerabilities or failures when interacting with the Decred blockchain. Failure to update wallet software in line with relevant protocol developments may result in transaction errors, temporary loss of access to wallet functions or exposure to known vulnerabilities.

4. Network security risks

Attack risks: Decred combines Proof-of-Work block production with Proof-of-Stake ticket voting. Attacks targeting mining hash power, ticket voting, network communications or node availability could attempt to censor or delay transactions, reorganise recent blocks, facilitate double-spending or disrupt block production. A mined block must include votes from at least three of the five tickets selected for that block. This stakeholder check increases resistance to attacks based only on Proof-of-Work control, but does not eliminate the risk of attacks or failures affecting both components of the consensus process.

Centralisation concerns: A concentration of Proof-of-Work hash power, voting tickets or operational dependence on a limited number of Voting Service Providers may increase the risk of coordinated behaviour, censorship or service disruption. The hybrid design reduces reliance on either miners or ticket voters alone, but network resilience may still be affected if participation becomes concentrated or material infrastructure providers become unavailable.

5. Bridge and interoperability risk

Where tokens can be bridged or wrapped across multiple blockchains, vulnerabilities in bridge protocols, validator sets, or locking mechanisms may result in loss, duplication, or misrepresentation of assets. Exploits or technical failures in these systems can instantly impact circulating supply, ownership claims, or token fungibility across chains.

6. Forking and protocol-upgrade risk

Changes to Decred's consensus rules require compatible node software and approval through the network's Proof-of-Stake voting process. If Proof-of-Work miners, ticket voters, node operators, wallets or service providers do not adopt compatible software, blocks or transactions may be rejected and network services may be disrupted. An uncoordinated or contested change could result in separate chain histories or uncertainty as to which chain is supported by wallets and trading platforms. Even a coordinated rule activation may temporarily create compatibility problems or lead service providers to suspend deposits and withdrawals while they update and verify their systems.

7. Layer 2 and cross-chain transaction risk

Decred supports Lightning Network payment channels and atomic-swap-based cross-chain trading. Funds committed to a payment channel or atomic swap depend on correct software operation, transaction scripts, timelocks, fee selection, network availability and, where applicable, timely monitoring or action by the participants. Software defects, incompatible implementations, insufficient routing liquidity, delayed confirmations or failure to complete the required steps within the applicable time limits may prevent the intended payment or exchange, require use of a refund path or leave funds temporarily inaccessible. A protocol or implementation vulnerability may also expose participants to loss. These mechanisms do not alter the native supply of DCR, but failures may reduce its practical usability or liquidity.

8. Spam and network-efficiency risk

High volumes of low-value (“dust”) or automated transactions may congest the network, slow validation times, inflate ledger size, and raise transaction costs. This can impair performance, reduce throughput, and expose address patterns to analysis, thereby reducing network efficiency and privacy.

9. Front-end and access-interface risk

If users rely on centralised web interfaces or hosted wallets to interact with the blockchain, service outages, malicious compromises, or domain expiries affecting these interfaces may block access to the crypto-asset, even while the blockchain itself remains fully functional. Dependence on single web portals introduces a critical point of failure outside the DLT layer.

None.

This disclosure relates to the Decred blockchain only, for the reasons set out in F.6.

The following applies to Decred:

Decred is a Layer-1 network operating under its own protocol and is not a token or smart contract deployed on another blockchain. It uses a hybrid Proof-of-Work and Proof-of-Stake consensus mechanism. Proof-of-Work miners order transactions, construct candidate blocks and perform the computational work required for block production. Proof-of-Stake participants review the miners’ work by voting with tickets that represent time-locked DCR.

A person may participate in Proof-of-Stake by purchasing a ticket at the protocol-determined ticket price. The committed DCR remains locked while the ticket is live. Tickets become eligible after the applicable maturity period and enter the live ticket pool. A live ticket may be selected to vote, may miss a call to vote or may expire without being selected. Following a vote, or the applicable revocation process for a missed or expired ticket, the committed DCR is released after the required maturity period.

For each block, five tickets are selected pseudorandomly from the live ticket pool. These tickets form a temporary voting committee for that block height. A mined block must include votes from at least three of the five selected tickets to satisfy the applicable validity requirements. Those votes also approve or reject the regular transaction tree of the preceding block. If a majority of the included votes approves it, the regular transaction tree is accepted. If a majority rejects it, or the included votes are tied, the regular transaction tree is rejected and its non-stake transactions may be returned to the transaction pool. The separate stake transaction tree remains subject to the applicable consensus rules.

Ticket holders may vote using their own continuously available wallet or may use a Voting Service Provider. A Voting Service Provider may be authorised to cast votes on behalf of a ticket holder but does not receive control of the DCR committed to the ticket.

Decred has probabilistic finality. The probability of a chain reorganisation generally decreases as additional valid blocks are added. A competing chain must satisfy both the applicable Proof-of-Work requirements and the Proof-of-Stake voting requirements. A prospective reorganisation must therefore obtain sufficient participation in both components of the consensus process.

Changes to the consensus rules are not implemented solely through off-chain governance decisions. A consensus change must be implemented in compatible node software and approved through the applicable on-chain stakeholder voting process before activation.

This disclosure relates to the Decred blockchain only, for the reasons set out in F.6.

The following applies to Decred:

Decred uses block subsidies, transaction fees, Proof-of-Stake rewards and Treasury funding to incentivise participation in block production, transaction validation, stakeholder voting and network development. The block subsidy is multiplied by 100/101 every 6,144 blocks, corresponding to approximately 21.33 days at the intended block interval. Following the subsidy allocation change activated in 2023, each block subsidy is distributed as follows:

- 1% is allocated to the Proof-of-Work miner;

- 89% is allocated among the Proof-of-Stake voters; and

- 10% is allocated to the Decred Treasury.

Where all five selected tickets vote, each voter is eligible to receive 17.8% of the total block subsidy. The DCR committed to the ticket is also released following completion of the applicable voting or revocation process and the subsequent maturity period. The released ticket price is the return of locked DCR and is not a newly issued reward.

Proof-of-Work miners receive the applicable miner portion of the block subsidy and the transaction fees associated with regular transactions included in the block. Transaction fees are paid by the person submitting the transaction and are generally determined by the size of the signed transaction. These fees are assigned to the miner rather than burned or transferred to the Treasury.

Ticket purchase transactions are also subject to network fees. A ticket holder may select a higher fee rate to increase the likelihood that the ticket purchase is included when demand for tickets exceeds the number permitted in a block. Transaction fees paid for a ticket purchase are not returned if the ticket is included and the ticket subsequently expires. A Voting Service Provider may charge a separate service fee under its own terms.

The Proof-of-Work subsidy is adjusted according to the number of Proof-of-Stake votes included in the block. If fewer than five votes are included, the miner’s subsidy is reduced proportionately. For example, inclusion of three votes results in the miner receiving 60% of the otherwise applicable Proof-of-Work subsidy.

If the included Proof-of-Stake votes reject the preceding block’s regular transaction tree, including where the votes are tied, the Proof-of-Work miner does not retain the subsidy and transaction fees associated with that rejected regular transaction tree. A selected ticket that fails to vote does not receive a Proof-of-Stake reward. The DCR committed to the missed ticket is not subject to principal slashing and can be returned through a revocation transaction following the applicable maturity period, subject to the applicable transaction fee.

The Treasury receives 10% of each block subsidy under the consensus rules. Eligible ticket holders vote on budget and policy proposals through Politeia, an off-chain proposal system whose records are cryptographically anchored to the Decred blockchain. Approval of a Politeia proposal does not itself create or disburse DCR. Treasury payments are made from accumulated Treasury funds through separately authorised Treasury-spend transactions that are subject to the applicable on-chain ticket-holder voting and consensus expenditure rules. Treasury funds may be used to pay persons performing approved work for the Decred project.

Within the Lightning Network, routing nodes may receive fees for forwarding off-chain payments. If a channel participant broadcasts a revoked channel state, the applicable penalty mechanism permits a justice transaction to transfer the disputed channel balance in accordance with the previously agreed channel conditions.

The energy consumption of this asset is aggregated across multiple components: For the calculation of energy consumptions, the so called 'bottom-up' approach is being used. The nodes are considered to be the central factor for the energy consumption of the network. These assumptions are made on the basis of empirical findings through the use of public information sites, open-source crawlers and crawlers developed in-house. The main determinants for estimating the hardware used within the network are the requirements for operating the client software. The energy consumption of the hardware devices was measured in certified test laboratories. When calculating the energy consumption, we used - if available - the Functionally Fungible Group Digital Token Identifier (FFG DTI) to determine all implementations of the asset of question in scope and we update the mappings regulary, based on data of the Digital Token Identifier Foundation. The information regarding the hardware used and the number of participants in the network is based on assumptions that are verified with best effort using empirical data. In general, participants are assumed to be largely economically rational. As a precautionary principle, we make assumptions on the conservative side when in doubt, i.e. making higher estimates for the adverse impacts.

To determine the proportion of renewable energy usage, the locations of the nodes are determined using public information sites, open-source and in-house-developed crawlers. Where no information is available on the geographic distribution of nodes, comparable reference networks are used, taking into account similarities in incentivisation structure and consensus mechanism. This geographic information is then combined with publicly available data from Our World in Data. The resulting intensity is calculated as the marginal energy consumption with respect to one additional transaction.

Ember (2025); Energy Institute, Statistical Review of World Energy (2024), with major processing by Our World in Data. “Share of electricity generated by renewables - Ember and Energy Institute” [dataset]. Underlying sources: Ember, “Yearly Electricity Data Europe”; Ember, “Yearly Electricity Data”; Energy Institute, “Statistical Review of World Energy”. Retrieved from: https://ourworldindata.org/grapher/share-electricity-renewables

To determine GHG emissions, the locations of the nodes are determined using public information sites, open-source crawlers, and crawlers developed in-house. Where no information is available on the geographic distribution of nodes, comparable reference networks are used, taking into account similarities in incentivisation structure and consensus mechanism. This geographic information is then combined with publicly available data from Our World in Data. The resulting intensity is calculated as the marginal emission intensity with respect to one additional transaction.

Ember (2025); Energy Institute, Statistical Review of World Energy (2024), with major processing by Our World in Data. “Carbon intensity of electricity generation – Ember and Energy Institute” [dataset]. Underlying sources: Ember, “Yearly Electricity Data Europe”; Ember, “Yearly Electricity Data”; Energy Institute, “Statistical Review of World Energy”. Retrieved from: https://ourworldindata.org/grapher/carbon-intensity-electricity. Licensed under CC BY 4.0.