The branch tKYAN-develop is designated for all the latest developments awaiting testing on the testnet.

Code Repository & Branch Location - Main repository : https://github.com/decenomy/DSW/ - Direct link to branches: https://github.com/decenomy/DSW/branches

How to Compile Docker build: https://github.com/decenomy/DSW/tree/develop/contrib/docker Manual build: https://github.com/decenomy/DSW/tree/develop/doc

Note: Instructions to build for Windows, Linux, MacOS and ARM systems.

Feedback We welcome your feedback! Please submit any issues or suggestions through our GitHub Issues page at https://github.com/decenomy/DSW/issues

The DECENOMY Standard Wallet (DSW) acts as the core codebase for all DECENOMY blockchains, streamlining the process of implementing updates and bug fixes. This setup not only facilitates efficient maintenance but also fosters open-source contributions from the community. Continuous efforts on the DSW are consolidated through its GitHub repository, accessible at https://github.com/decenomy/DSW, where it can also be found various branches at https://github.com/decenomy/DSW/branches. These branches are dedicated to different stages of development, including new releases and specific branches for each blockchain. This allows the code to be efficiently transferred from DSW to the individual blockchain codes.

Updates, including new functionalities and/or enhancements, are periodically integrated into each DECENOMY blockchain's repository through a process known as "rollouts," once a notable volume of improvements has been gathered. Moreover, when a bug is detected in any blockchain, the correction is first applied to the specific blockchain and subsequently integrated into the DSW framework.

It is important to note that the DSW is not intended to function as an independent wallet or cryptocurrency. Rather, it is designed to provide a robust framework for development within the DECENOMY ecosystem.

The open-source model of the DSW invites and supports community engagement in the project. This includes the addition of new features, fixes, or the reporting of bugs through the creation of issues or pull requests on the DSW GitHub repository.

The latest tKYAN binaries are available on GitHub at https://github.com/decenomy/DSW/releases, with versions compatible with Windows, macOS, Linux, and ARM systems.

Download them as you would with any wallet binaries and execute the Qt file or use the command line interface (CLI) as required. Attention As mention before this will run based on a KYAN branch, so without start the wallet with the testnet atribute, it will land on the KYAN blockchain and not on tKYAN blockchain, the testnet we want to achive.

How to start tKYAN wallet using QT file ( GUI )

Introduction

In the realm of cryptocurrency networks, the evolution of masternode systems is a critical juncture where operational efficiency and network stability converge. The traditional masternode model's sudden adjustment of collateral values at a specified block number has posed challenges, resulting in considerable network instabilities. Abruptly dropping the existing masternodes with old collateral values and waiting for new masternodes with updated collateral leads to significant disruptions in the network’s continuity.

The disruptive impact arises from the network's need to cleanse the entire masternode list, causing pauses in operations until the list repopulates. This process introduces considerable instability, impacting the reliability and functionality of the network. Moreover, it creates significant stress and uncertainty for masternode operators, affecting their ability to adapt within the set timeframe.

Proposed Feature: Enhancing Masternode Stability with Collateral Window

The current masternode system undergoes critical changes in collateral values at specific block numbers, precipitating significant network instabilities. The sudden alteration results in the removal of existing masternodes with previous collateral values, prompting a waiting period for the introduction of new masternodes with updated collateral. This process disrupts network continuity, introducing considerable instability and stress among operators.

In response to these challenges, the innovative Masternode Collateral Window feature has emerged. This solution facilitates the setup of new masternodes with adjusted collateral values seven days before the deadline. This extended window aims to alleviate the stress on masternode operators, providing ample time for adjustment and minimizing disruptions to the network.

The development of this feature involves a meticulous reconfiguration of the masternode setup process. Implementing the Masternode Collateral Window entails refining the masternode software to allow operators to update collateral values within the specified window. Extensive testing and validation are essential to ensure the stability and compatibility of the new feature within the network's framework.

The Masternode Collateral Window represents a significant step towards a more stable and stress-free masternode ecosystem. This development aims to significantly reduce network instabilities, providing operators with a smoother transition period for collateral adjustments ultimately fostering a more resilient and predictable network.

Conclusion: Advancing Masternode Stability with Collateral Window

The Masternode Collateral Window brings a critical shift in the masternode ecosystem by extending the collateral adjustment timeline. This innovation significantly diminishes stress and network instabilities by allowing operators a seven-day window to adapt their collateral values. The implementation of this feature demands meticulous adjustments and thorough testing. Ultimately, this advancement promises a more stable, operator-friendly, and predictable masternode network, emphasizing a smoother transition and reduced disruptions in the system.

This documentation page provides an overview of the improvements that are being made to the DSW wallets.

New Features

Introducing Last Paid V2

One of the features of the masternode system is the ability to track when a masternode (MN) was last paid. This information is helpful for determining the order of payments and the expected time until the next payment. However, the previous standard method of calculating the last paid value of an MN has some flaws and inaccuracies that can affect the fairness and efficiency of the payment system. The last paid v2 is a new feature that aims to solve these problems and improve the accuracy and reliability of the last paid value.

Challenges and limitations of the standard version

The previous standard method of calculating the last paid value of an MN is based on the number of votes that an MN receives from other MNs in the network. The inherited masternode system uses a voting mechanism to select which MN will receive the next payment. Each MN casts a vote for another MN that it thinks should be paid next based on various criteria, such as the last paid value, the protocol version, and the collateral age. The MN that receives the most votes in a given block is selected as the winner and is elected to be paid.

However, this voting mechanism has some drawbacks and limitations.

• It relies on the assumption that all MNs are online and voting correctly, which may not always be accurate. Some MNs may be offline, malfunctioning, or maliciously voting for themselves or their possible colluding partners.

• It does not account for the actual time when an MN was paid but only for the votes it received. This means that sometimes an MN may lose a payment round because it received fewer votes than another MN, even though it was truthfully waiting longer to be paid.

• It does not provide a clear and consistent way to measure the last paid value of an MN across different nodes in the network. Different nodes may have different views of the voting history and may disagree on which MN was last paid and when.

Introducing a Blockchain-based solution

The last paid v2 is a new feature that addresses these issues and replaces the old voting mechanism entirely. Instead of using votes to determine when an MN was paid, it uses the blockchain itself as the source of truth.

• The blockchain tracks and records every payment made to an MN in a field called payee.

• The last paid v2 algorithm scans the blockchain from the most recent to the oldest block and looks for this field to identify when an MN was paid.

• It then assigns a last-paid value to each MN based on the block height of its last payment.

This way, it can accurately and objectively determine which MN was waiting longer to be paid and select it as the next winner.

Advantages of Last Paid V2

The last paid v2 has several advantages over the old voting mechanism.

1. It does not depend on external factors such as network connectivity, node availability, or voting behavior. It only relies on the blockchain data, which is immutable and verifiable by anyone.

2. It reflects the actual time when an MN was paid, not just the number of votes it received. This ensures that every MN has a fair chance to receive a payment based on its waiting time, not popularity, influence, or luck.

3. Provides a consistent and transparent way to measure the last paid value of an MN across different nodes in the network. Every node can easily calculate and verify this value by scanning the same blockchain data.

The last paid v2 is a significant improvement for the masternode system and for DECENOMY coins as a whole. It enhances the accuracy and reliability of the payment system, increases its fairness and efficiency, and reduces its complexity and potential for errors. It also makes DECENOMY coins more attractive and competitive as a cryptocurrency that rewards its users for securing and supporting its network.

Introduction

Revolutionizing Masternode Hosting for Decentralization

In the dynamic landscape of cryptocurrency networks, the evolution of masternode systems plays a crucial role in shaping their efficiency and security. This document introduces a groundbreaking feature aimed at transforming the masternode ecosystem, allowing a single full node to host multiple masternode instances.

The advent of multi-instance hosting marks a significant shift, alleviating operational complexities and lowering barriers for masternode operators. This innovation incentivizes the cost-effective management of several masternodes on a singular server, reducing the technical overhead and encouraging broader participation.

Beyond operational efficiency, this feature indirectly fosters network decentralization by enabling easier access and management of masternodes. By simplifying the process of hosting multiple masternodes on private servers, this advancement contributes to a more diverse and resilient network structure.

This document outlines the technical aspects, benefits, and the pivotal role of this feature in promoting a more accessible, cost-efficient, and decentralized masternode ecosystem.

Proposed Feature: Multi-Instance Hosting for Masternodes

This feature introduces a transformative shift in masternode systems by enabling a single full node to host multiple masternode instances, promoting a more accessible, decentralized, and self-sovereign network architecture.

Allowing a single full node to manage multiple masternodes concurrently significantly reduces technical complexities and operational costs. Operators can efficiently manage several masternodes on a private server, enhancing cost-effectiveness and operational efficiency.

Additionally, this advancement indirectly incentivizes decentralization and self-sovereignty by encouraging increased participation. Simplifying the process of hosting multiple masternodes on private servers not only fosters network diversity but also empowers operators, providing greater autonomy and control over their masternode operations.

The technical implementation involves refining the full node software to accommodate multiple masternode instances effectively. Comprehensive testing is imperative to ensure stability, security, and optimized performance within the network.

Ultimately, the implementation of multi-instance hosting aligns with the overarching goal of fostering a more accessible, cost-effective, and self-sovereign masternode ecosystem. This feature significantly reduces operational barriers and promotes decentralization and self-sovereignty, strengthening the network's overall structure and accessibility.

Conclusion: Advancing Decentralization through Multi-Instance Masternode Hosting

The introduction of multi-instance hosting for masternodes marks a pivotal leap in redefining the landscape of cryptocurrency networks. This innovative feature enables a single full node to manage multiple masternode instances, ushering in a more accessible, efficient, and self-sovereign ecosystem.

At first glance, consolidating multiple masternodes on a single server may seem to incentivize centralization. However, this overlooks the nuanced impact of prior practices. Formerly, the forced hosting of one masternode on a single server created a false impression of decentralization, as numerous masternodes were hosted on one server, each operating under different IP addresses and processes.

The newly introduced multi-instance hosting breaks away from this false decentralization paradigm. By significantly reducing the barriers of entry to host multiple masternodes, this feature paves the way for a more genuinely decentralized network. Lowering technical complexities and operational costs encourages individual investors to host masternodes in their private facilities, thereby democratizing masternode ownership and promoting a diversified network structure.

The democratization of masternode ownership not only empowers a more diverse range of stakeholders but also fosters a more resilient and decentralized network structure. Operators gain greater control and autonomy, reinforcing the concept of self-sovereignty within the masternode ecosystem.

Implementation of multi-instance masternode hosting necessitates meticulous testing and refinement to ensure network stability and performance. In essence, this feature's true impact lies in democratizing and decentralizing masternode ownership, leading to a more robust, inclusive, and genuinely decentralized masternode ecosystem.

Dynamic Rewards represents one of the most recent updates introduced by Decenemy, designed to fine-tune our network's block reward mechanism and how coin supply is calculated, ultimately aiming to strengthen stability and sustainability.

With this recent development, block rewards will now be adjusted proportionally according to both the total and circulating supply within the network. This adjustment is essential for preserving the economic stability and sustainability of the network.

Given the dependency of block rewards on coin supply, a sophisticated Circulating Supply Algorithm has been implemented. This enhanced algorithm will guarantee precise supply calculations by:

• Analyzing the entire Unspent Transaction Output (UTXO) set.

• Excluding burn addresses and UTXOs matching the current and upcoming masternode collateral values.

• Counting UTXOs based on their age, fully counting those less than three months old, linearly scaling down those between three to twelve months, and excluding all UTXOs older than twelve months.

Additionally, there has been an enhancement in monitoring supply dynamics. The updated metric provides an efficient method for monitoring coin supply and implementing required adjustments to emission rates when necessary. For example, once the exact values of the total and circulating supplies are determined, the system computes the emission rate for the current period. This process also involves anticipating expected minting, determined by specified percentages of the total and circulating supplies.

To streamline the reward adjustment process, Decenomy introduces a damping function. This function moderates any changes in the block reward (delta value) through a linear approach, ranging from 0% to 10% with each adjustment.

Context

A testnet, short for "test network," is an experimental network that allows for blockchain development and testing without the risk and expense of transacting on the main network, known as the mainnet. Testnets simulate the conditions of the blockchain environment, providing developers a safe space to experiment with new projects, smart contracts, and any blockchain-based applications. This way, they can detect any errors, vulnerabilities, or inefficiencies before deployment on the live blockchain.

Testnets are crucial for several reasons:

1. Testing and Development: Developers can test new features or assets thoroughly without using real cryptocurrency or assets, which can be expensive and risky.

2. Education and Experimentation: They offer a hands-on learning environment for newcomers wanting to understand blockchain technology without financial risk.

3. Debugging: Finding and fixing bugs in a controlled environment helps improve the security and stability of applications before they go live.

4. Network Testing: Testnets can simulate various conditions to see how the network behaves under stress or in unusual situations, ensuring resilience and scalability.

Most blockchain projects offer their own testnets, and while they operate similarly to the mainnet, the coins used on a testnet have no real-world value. This setup encourages wide-ranging experimentation and testing without the fear of losing valuable assets.

DECENOMY Testnet

As previously noted, due to the central codebase of the DSW and its implementation across all DECENOMY blockchains, there's only a need for a single testnet within the ecosystem.

This testnet operates on the KYAN branch, initiates a specific blockchain for testing when started with the testnet argument. It is recognized by the ticker tKYAN.

Compiled binaries allow tKYAN to function as a Desktop Wallet across various systems, including Windows, MacOS, Linux, and ARM systems. Additionally, tKYAN is also integrated into the Flits App https://flitswallet.app/, enabling seamless transfers between desktop and the Flits mobile app and facilitating the setup of masternodes on Flits for added convenience. It is worth noting that within Flits, the ticker is displayed in all caps as TKYAN, though it refers to the same testnet blockchain.

To monitor tKYAN activity, please refer to the official DECENOMY explorer https://explorer.decenomy.net/TKYAN/. For more detailed information on transactions occurring on the blockchain, our secondary, more technically detailed explorer at https://tkyan.flitswallet.app/ is available. It's important to remember that tKYAN is a blockchain without any real-world value or market association. It exists purely and solely for testing purposes.

tKYAN Binaries

• Compile Your Own tKYAN Binaries

• Pre Build tKYAN Binaries

The DSW (DECENOMY Standard Wallet), hosted on GitHub and recognized as the central hub for code updates, plays a pivotal role in the DECENOMY ecosystem. It is crucial for implementing enhancements, including new features, functionality upgrades, and critical bug fixes. Following the new implementations, a testnet deployment is a fundamental stage of the blockchain development process. This crucial step ensures that any new modifications are rigorously evaluated in an environment that closely emulates live blockchain conditions. DECENOMY's designated testnet, tKYAN, serves as the testing ground where developers critically examine the effects of updates, discover bugs, and suggest improvements. Designed to mimic the behavior of live blockchains accurately, it operates on the DSW codebase, ensuring consistency between testing phases and live environments. After a successful testing phase, the code is first rolled out to one DECENOMY blockchain, typically starting with KYAN. This initiation triggers a wider rollout to additional chains within the ecosystem, promoting a consistent codebase among DECENOMY blockchains. Despite the standardized codebase, some DECENOMY blockchains feature unique attributes distinguishing them from others. Although these specific cases may require adjustments or exceptions from direct testnet rollouts to maintain their unique features, the fundamental DSW code remains crucial. To learn more about each stage please follow the links:

One of the main functions of the masternode system is to distribute rewards to the masternodes (MN) that secure and support the DECENOMY network. The rewards are generated by the block creation process and are allocated to a specific MN at each block. However, the question of selecting which MN will receive the reward in each block is not trivial. Different methods can have different implications for the fairness and efficiency of the reward system.

Challenges and limitations of the voting mechanism

The previous inherited method of selecting the reward recipient is based on a voting mechanism. Each MN in the network casts a vote for another MN that it thinks should receive the next reward based on the criteria of the last paid value. The last paid value is an estimate of when an MN was last paid, calculated by counting the number of votes that it received from other MNs. The MN that receives the most votes in a given block is selected as the winner and receives the reward.

However, this voting mechanism has some drawbacks and limitations.

• It relies on the assumption that all MNs are online and voting correctly, which may not always be accurate. Some MNs may be offline, malfunctioning, or maliciously voting for themselves or other colluding parties.

• It does not account for the actual time when an MN was paid but only for the number of votes it received. This means that sometimes an MN may lose a reward round because it received fewer votes than another MN, even though it was truthfully waiting longer to be paid.

• It does not provide a clear and consistent way to measure the last paid value of an MN across different nodes in the network. Different nodes may have different views of the voting history and may disagree on which MN was paid and when.

Masternode Payment V2 is a blockchain-driven approach

The masternode payment v2 is a new feature that addresses these issues and replaces the old voting mechanism entirely. Instead of using votes to select the reward recipient, it uses a simple and objective rule: it pays the MN that is waiting longer to be paid.

• To determine which MN is waiting longer to be paid, it uses blockchain data as the source of truth. The blockchain records every payment that is made to an MN in a particular field called payee.

• The masternode payment v2 scans the blockchain from the most recent to the oldest block and looks for this field to identify when an MN was paid. It then assigns a last paid value to each MN based on its last payment's block height (or number).

This way, it can accurately and objectively determine which MN has been waiting longer to be paid and select it as the next winner.

Advantages of Masternode Payment V2

The masternode payment v2 has several advantages over the old voting mechanism.

• It does not depend on any external factors such as network connectivity, node availability, or voting behavior. It only relies on the blockchain data, which is immutable and verifiable by anyone.

• Reflects the actual time when an MN was paid, not just the number of votes that it received. This ensures that every MN has a fair chance to receive a reward based on its waiting time, not on its luck.

• Provides a consistent and transparent way to measure the last paid value of an MN across different nodes in the network. Every node can easily calculate and verify this value by scanning the same blockchain data.

The masternode payment v2 is a major improvement for the masternode system and for the DECENOMY coins. It simplifies and streamlines the reward system, increases its fairness and efficiency, and reduces its complexity and potential for errors. It also makes DECENOMY coins more attractive and competitive as a cryptocurrency that rewards its users for securing and supporting its network.

EBF system is still in the work-in-progress phase

Enhanced Blockchain Features (EBFs) refer to functional extensions of a regular UTXO-based blockchain, such as Bitcoin. Comparable to Ethereum contracts, EBFs are stateful and Turing complete, providing the ability to compose functionalities that complement and strengthen the regular stateless UTXO model. However, it is noteworthy that EBFs should not be authored or released by the general public since they will extend and interact with vital components of the blockchain. Such crucial components include the capacity for generating new coins, thereby rendering EBFs a high-security standard and sensitive element. EBFs amalgamate the practicability and determinism of a blockchain's UTXO model with the strengths of natively developed Turing complete functionalities.

Structure

Enhanced Blockchain Features (EBF) infrastructure comprises multiple platforms, each designed to accommodate a set of interrelated additional functionalities. Each platform comprises contracts with various methods, each being assigned specific and unique tasks. It is critical to ensure that each method is fully deterministic and adheres to the principles of single responsibility and separation of concerns to enhance the efficiency and reliability of the EBF platform. By adhering to these principles, the EBF platform can offer a stable and dependable environment for executing contracts, thereby ensuring the security and stability of the blockchain ecosystem.

Messaging

To invoke a contract method on an Enhanced Blockchain Features (EBF) platform, an EBF message must be issued. These messages are expressed as OP_RETURN script transaction outputs on regular transactions. To distinguish them from regular OP_RETURN scripts, EBF messages are identified by starting with an OP_RETURN opcode and two checksum bytes.

Digital signatures are utilized to ensure the authenticity and integrity of EBF messages. The signatures are generated using the sender's private key, and executed against the entire transaction, thereby preventing a replay attack and preventing the need for a nonce field. In this manner, the EBF platform ensures that the same message cannot be used to modify the blockchain multiple times.

The following fields describe the EBF message generic envelope:

Message Processing

The processing of EBF messages involves several steps. First, the transaction containing the EBF message must be validated according to the blockchain rules. This includes checking that the inputs are valid and that the sender has the necessary funds to cover the transaction fees. Once the transaction is validated, the EBF message is extracted from the OP_RETURN output script.

Next, the EBF message is deserialized, and the contract method specified in the message is located. The contract method is then executed, and any necessary state changes are made to the blockchain. This may involve modifying the balances of accounts or updating the state of smart contracts.

It is essential to note that EBF messages are executed deterministically, and any state changes must be consistent with the blockchain's current state. This ensures that the blockchain remains secure and that all nodes in the network can reach a consensus on the current state of the blockchain.

Due to blockchain technology's decentralized nature, blockchain network blocks may be subject to reorganization. Consequently, each contract method deployed on an Enhanced Blockchain Features (EBF) platform must have a robust process to handle reorganization events and restore the contract to its prior state in such an event. In the context of the EBF platform, a reorganization refers to a mechanism that restructures the blockchain network in response to a network-wide consensus failure, ensuring the integrity and consistency of the blockchain. The reorganization process is critical in enabling the EBF platform to maintain a reliable and secure environment for executing contracts, minimizing the risk of failure, data loss, inconsistency, or corruption during a blockchain reorganization.

In summary, the processing of EBF messages involves validating transactions, extracting and deserializing EBF messages, locating and executing contract methods, making necessary state changes to the blockchain, and preventing replay attacks through the use of transaction signatures.

Block Processing

The validation of transactions constitutes a critical step in processing blocks within the EBF infrastructure. Upon adding a new block to the blockchain, it is imperative to ascertain the validity of the transactions contained within it and to ensure they conform to the regulations stipulated by the EBF platform. This validation procedure comprises a comprehensive review of the EBF messages and the digital signatures embedded within them, an examination of the transaction inputs and outputs, and a check to ensure the absence of double-spending and invalid EBF states. The nodes within the network undertake the validation process and participate in the consensus protocol, arriving at a collective agreement on the veracity of the transactions within the block. Upon successful validation, the transactions are appended to the block and propagated to the other nodes within the network. The block processing mechanism within the EBF infrastructure closely resembles that of the conventional blockchain, with the additional layer of EBF validation superimposed upon it.

The proper execution of smart contracts constitutes another pivotal aspect of block processing on the EBF infrastructure. Smart contracts represent self-executing software programs that operate on the blockchain and automate the execution of predetermined rules and conditions. This feature is deemed essential for the EBF platform, as it facilitates the integration of more sophisticated features that can interact with the network in real-time. The execution of smart contracts entails the validation of the input data that is passed through messages, the execution of the underlying code, and the updating of the contract state. The nodes within the network undertake the task of executing smart contracts, where they execute the contract code and arrive at a consensus on the updated contract state.

State management

State management is another crucial aspect of block processing on the EBF infrastructure. State refers to the current state of the blockchain network, which includes the balances of accounts, the state of contracts, and the current state of the consensus protocol. State management involves updating the network state based on the transactions included in the block and the execution of smart contracts. Nodes in the network perform this process by maintaining a copy of the current state of the network and updating it as new blocks are added to the blockchain. State management plays a vital role in ensuring the consistency and integrity of the blockchain network by ensuring that the current state of the network reflects the latest valid transactions and contract executions.

Cryptocurrency networks, fueled by their underlying technologies, are in a perpetual state of innovation. Masternodes, critical in their functionality, play a significant role in ensuring the integrity and security of these networks. Recently, discussions have been made proposing a groundbreaking shift - implementing a progressive collateral model for masternodes.

Introduction

Restructuring the Landscape

This proposal aims to transform the conventional masternode operations by redefining reward distribution and operational functionality. At the heart of this change lies the intention to significantly lower entry barriers into the masternode ecosystem. By doing so, the proposal seeks to democratize participation and make the network more decentralized and inclusive.

Opening Doors to All

A crucial aspect of this proposed transformation is the vision to encourage broader participation. With reduced collateral requirements, this model intends to open doors to a broader spectrum of investors, fostering a more decentralized and democratic environment within the network.

Stability and Predictability

Moreover, the proposed system foresees a shift towards more regular and predictable masternode reward payments. This transition holds the potential to provide higher stability for masternode operators, enabling a more consistent flow of rewards and potentially encouraging increased engagement in the network.

Shaping the Future of Masternodes

These changes promise to redefine the dynamics of masternode networks, offering improved accessibility, decentralization, and more regularized rewards. However, these proposals have their challenges. The path to implementation requires careful consideration of the technical complexities, community consensus, and ensuring a secure and stable network.

Understanding Masternodes

In the realm of cryptocurrency networks, masternodes are pivotal entities that contribute significantly to the system's functionality and security. These specialized nodes perform various critical functions that underpin the network's operations.

A Cornerstone of Functionality

Masternodes serve as more than just validators of transactions; they actively participate in governing the network. Their responsibilities include ensuring the validity and efficiency of transactions, facilitating instant and private transactions, and contributing to the governance and decision-making processes of the blockchain.

Rewards and Operation

Masternode operators are rewarded for their services, typically receiving a portion of the block rewards for their contribution. This incentivizes users to commit and maintain collateral, creating a vested interest in the network's security and stability.

An Integral Component

They are a vital cog in the wheel, ensuring the smooth functioning of the blockchain and maintaining the integrity of the network. However, the conventional masternode setup often poses a significant entry barrier due to the high collateral requirements, limiting participation to a select few.

The Need for Evolution

The proposal for a progressive masternode collateral system aims to address these limitations, potentially reshaping the landscape by democratizing participation and fostering a more inclusive and decentralized network.

Proposed Feature: Fractioning Masternode Payments

The proposed evolution of masternode systems introduces a novel feature that redefines the way rewards are distributed among participants. This change involves the division of masternode payments into 16 slots, a departure from the traditional method of rewarding masternodes.

Enhancing Stability and Reward Distribution

The fundamental intention behind this feature is to enhance stability in reward distribution. By splitting the payment streams into multiple slots, the system aims to provide more consistent and predictable rewards for masternode operators.

Risk Diversification

One notable advantage of splitting payments into multiple slots is the diversification of risk. Rather than a single slot encountering issues and affecting the entire masternode operation, this feature mitigates risk by spreading payments across various slots.

Proposed Feature: Multi-Tiered Masternode System and Reward Slot Integration

The proposed evolution of masternode systems introduces a multi-tiered structure with varying collateral requirements and integrates the subdivision of rewards into 16 slots. Each tier is designed to encompass double the slots of the preceding tier, establishing a balanced and inclusive participation model within the network.

Diversified Participation and Tiered Collateral

The envisioned multi-tiered system segregates masternodes into distinct levels, each demanding specific collateral. The first tier introduces a collateral value equal to the base collateral, while each subsequent tier necessitates a collateral double that of the previous tier. Moreover, the balanced slot allocation - with each tier holding twice the number of slots as the tier before - allows for diverse participation, catering to investors with varying investment capabilities and fostering a more inclusive network.

Balancing Rewards and Network Stability

Coupled with this tiered system, the proposal introduces the subdivision of rewards into 16 slots. This balanced allocation aims to enhance stability in reward distribution, providing more consistency and predictability for masternode operators. Furthermore, the tiered structure incentivizes higher collateral commitments, potentially fortifying network security.

Proposed Feature: Sequential Reward Algorithm Based on Masternode Tiers

The proposed evolution of masternode systems introduces a sequential reward algorithm that allocates slots based on masternode tiers, redefining the reward distribution mechanism within the network.

Structured Reward Allocation

This novel approach establishes a sequential reward system where masternode tiers dictate the allocation of slots. Tier 1 masternodes receive one slot, Tier 2 two slots, and so forth, up to Tier 5, culminating in 16 slots. This structured approach ensures a clear and organized reward allocation, enabling masternode operators to anticipate and plan for their expected rewards.

Advantages of Predictability and Stability

The advantages of this sequential reward system are manifold. Structured slot allocation ensures predictability for masternode operators, allowing for more informed and strategic planning of their operations. Additionally, this method enhances stability in the reward mechanism, mitigating variance and providing a more consistent and regular reward pattern.

This sequential system aligns with the multi-tiered masternode structure, further reinforcing the network's balance and predictability. It aims to offer a more equitable and structured approach to reward distribution while fostering a transparent and organized system for masternode operators.

The introduction of this sequential reward algorithm is poised to revolutionize the reward distribution landscape within masternode networks, offering a more structured and predictable framework for masternode operators, thus bolstering the overall stability and reliability of the network's reward system.

Conclusion: Evolution of Masternode Systems - Forging a Balanced Future

The proposed transformation of masternode systems heralds a new era in cryptocurrency networks, introducing innovative features designed to redefine participation, reward distribution, and network stability.

Through the introduction of a multi-tiered masternode system with escalating collateral requirements and a balanced slot allocation, the initiative aims to foster inclusivity, encouraging diverse investor participation while incentivizing higher commitments for increased network security.

Integrated with this tiered structure is a sequential reward algorithm that allocates slots based on masternode tiers. This sequential approach offers structured and predictable reward distributions, providing masternode operators with a more transparent and more organized reward framework. The aim is to enhance stability, minimize variance, and provide a more consistent pattern of rewards.

The proposed changes, if realized, promise a more democratized and secure network, enhancing the engagement and experience of masternode operators while fostering a robust and reliable ecosystem. As we progress toward these transformative changes, meticulous planning, robust testing, and transparent community engagement will be pivotal for ensuring a successful evolution of masternode systems.

DSW stands for Decenomy Standard Wallet and is a cryptocurrency platform part of DECENOMY, a project network that shares the same wallet codebase and blockchain infrastructure, enabling cross-chain interoperability and governance among the DECENOMY projects. DSW is a PIVX fork based on DASH, which is also based on Bitcoin. One of the features that DSW supports is changing collateral values for masternodes, opposite to DASH and PIVX where the collateral is constant.

Fixed collateral value variation and their disadvantages

Masternodes are special nodes that provide services to the network. To run a masternode, one must lock a specific amount of DECENOMY coins as collateral. The collateral amount is currently determined by a fixed table specifying the collateral value for each block height range. However, this fixed system has some disadvantages, such as:

• It does not reflect the dynamic changes in the market conditions and user preferences, which may affect the supply and demand of DECENOMY coins and masternodes.

• It does not allow for fine-tuning of the collateral amount to achieve an optimal balance between risk and reward for masternode operators and investors.

• It may create barriers to entry or exit for masternode operators, who may need to acquire or dispose of a large number of coins to meet the collateral requirements or the assembly of an abnormal number of masternodes.

• It may cause an unbalance of masternode numbers on the network, creating an excess of computational weight on the normal network functioning, and an excess of operational costs for the masternode operator.

To overcome these limitations, a new feature called Dynamic Collaterals is proposed.

Introducing Dynamic Collaterals

Dynamic Collateral is a feature that will change the collateral value at every 100000 blocks, based in:

• evaluation of the current coin supply,

• a predefined target percentage of the supply locked in masternodes,

• desired number of masternodes in the network.

The idea behind Dynamic Collaterals is to adjust the collateral amount according to the market conditions and the network needs, ensuring a balance between supply and demand, security, and decentralization.

How Dynamic Collaterals Work

The change in collateral value will be limited by a minimum percentage and a maximum percentage, for example, if we have a percentage range of 10% and 20% means that in each collateral change the value will change only within that range or not at all. The changes are also valid for supply reduction in cases when a certain quantity of coins gets burned within the running period. These changes are also limited in terms of value steps, they will only change in steps of 1000 coins. The moment that this calculation takes place is on the block created 7 days before the collateral change, giving time for the investor to adjust their masternodes accordingly for the next epoch.

For example, suppose that:

• the current coin supply is 1 billion DSW,

• the target percentage of locked supply in masternodes is 70%,

• the desired number of masternodes is 2880, which means that each masternode should receive a reward every alternate day (assuming 60 seconds per block).

Then, the collateral amount can be calculated as follows:

Collateral = (Coin Supply x Target Percentage) / Desired Number of Masternodes Collateral = (1 billion x 70%) / 2880 Collateral = 243055 DSW

This means that to run a masternode, one needs to lock 243000 DSW coins as collateral (rounded down to a multiple of 1000 coins). This amount will be valid for 100000 blocks, after which it will be recalculated based on the new coin supply, target percentage, and desired number of masternodes.

Suppose that after 100000 blocks:

• the coin supply has increased to 1.3 billion DSW due to new minting,

• the target percentage and desired number of masternodes remain unchanged.

Then, the new collateral amount can be calculated as follows:

Collateral = (Coin Supply x Target Percentage) / Desired Number of Masternodes Collateral = (1.3 billion x 70%) / 2880 Collateral = 315972 DSW

This means that to run a masternode, one needs to lock 315000 DSW coins as collateral (rounded down to a multiple of 1000 coins). However, since this amount exceeds the maximum percentage change of 20%, it will be capped at 291600 DSW (243000 x 1.2); in this case, 291000 DSW coins a multiple of 1000 coins. This amount will be valid for another 100000 blocks.

The Benefits of Dynamic Collaterals

• It allows for more flexibility and adaptability of the network to changing market conditions and user preferences.

• It encourages more participation and investment in masternodes by adjusting the collateral amount to an optimal level that balances risk and reward.

• It creates more opportunities for masternode operators, who can benefit from price fluctuations and arbitrage possibilities.

• In the future, it will aid the adaptation of the DSW coins to the actual market, by using real-world metrics to fine-tune the algorithm's parameters.

Dynamic Collaterals is still a work in progress and a small component of the overall DECENOMY vision and may require further research and testing before implementation. However, it is an exciting and promising feature that may bring more value and utility to the DSW platform and the DECENOMY network.

• checkconnection RPC call: This call allows you to test the connectivity of your server with other nodes on the network.

• mnping RPC call`: This call allows you to send a ping message to your masternode and receive a pong response. It helps you verify that your masternode is online and responsive.

• reloadmasternodeconfig RPC call and a corresponding GUI element: This call and element allow you to reload your masternode configuration file from the command line or the user interface. It is useful if you want to make changes to your masternode settings without stopping or restarting them.

• setautocombinethreshold command and UI support: This command replaces the deprecated autocombinerewards command, which automatically combines small inputs into larger ones to reduce transaction fees and improve privacy. The new command allows you to set a threshold amount for auto-combining inputs and enable or disable this feature from the command line or the user interface.

• rewindblockindex command, start option, and the GUI element: This command allows you to rewind your block index in case of a fork or a corrupted database. It deletes all blocks after a specified height and re-syncs with the network from that point. It can help you recover from various issues that may affect your wallet functionality or integrity.

• getactivemasternodecount RPC/CLI command: The command reports the number of active masternodes of a wallet.