Axe Core has published an extensive Developer Guide to help new developers get started with the Axe code base, and as a reference for experienced developers. This guide can be leveraged to quickly and efficiently integrate external applications with the Axe ecosystem. Anyone can contribute to the guide by submitting an issue or pull request on GitHub. The documentation is available at: https://axerunner.github.io/en/
The Axe Core Team also maintains the Axe Roadmap, which sets out delivery milestones for future releases of Axe and includes specific technical details describing how the development team plans to realise each challenge. The Axe Roadmap is complemented by the Axe Improvement Proposals, which contain detailed technical explanations of proposed changes to the Axe protocol itself.
The remaining sections available below describe practical steps to carry out common development tasks in Axe.
A multi-phased fork, colloquially known as a “spork”, is a mechanism unique to Axe used to safely deploy new features to the network through network-level variables to avoid the risk of unintended network forking during upgrades. It can also be used to disable certain features if a security vulnerability is discovered - see here for a brief introduction to sporks. This documentation describes the meaning of each spork currently existing on the network, and how to check their respective statuses.
Sporks are set using integer values. Many sporks may be set to a particular epoch datetime (number of seconds that have elapsed since January 1, 1970) to specify the time at which they will active. Enabled sporks are set to 0 (seconds until activation). This function is often used to set a spork enable date so far in the future that it is effectively disabled until changed. The following sporks currently exist on the network and serve functions as described below:
- Governs the ability of Axe clients to use InstandSend functionality.
- If enabled, masternodes will reject blocks containing transactions in conflict with locked but unconfirmed InstandSend transactions.
- Enforces the maximum value in Axe that can be included in an InstantSend transaction.
- Enables a new signature format for Axe-specific network messages introduced in Axe 12.3. For more information, see here and here.
- If enabled, miners must pay 50% of the block reward to a masternode currently pending selection or the block will be considered invalid.
- If enabled, superblocks are verified and issued to pay proposal winners.
- Controls whether masternodes running an older protocol version are considered eligible for payment. This can be used as an incentive to encourage masternodes to update.
- Forces reindex of a specified number of blocks to recover from unintentional network forks.
- Deprecated. No network function since block 614820.
- Toggles whether masternodes with status are eligible for payment if status is WATCHDOG_EXPIRED, i.e. Sentinel is not running properly.
- Controls whether deterministic masternodes are required. When activated, the legacy masternode list logic will no longer run and non-updated masternodes will not be eligible for payment.
- Enables automatic transaction locking for transactions with less than a specified number of inputs, and removes the legacy InstantSend fee. Allows any node to request the transaction lock, not just the sending node.
- Enables the DKG process to create LLMQ quorums. At the moment, this only activates a dummy DKG on testnet, which will later be replaced by the real DKG for mainnet and testnet. When enabled, simple PoSe scoring and banning is also active.
Viewing spork status¶
spork show and
spork active commands issued in the debug
window (or from
axe-cli on a masternode) allow you to interact with
sporks. You can open the debug window by selecting Tools > Debug
Full release notes and the version history of Axe are available here: