Features and Activation#
Note
Verified against node-scala v1.8.0.
Protocol changes ship as numbered blockchain features. A feature is not active just because a node supports it: it must be activated on the network, either by a generator vote or because the network defaults pre-activate it.
How activation works#
Generators signal support for features they implement in the blocks they produce.
At the end of each voting period, a feature that reached the voting threshold is scheduled for activation.
After activation, the new rules apply to every node.
Inspect the current state at any time:
curl -s http://localhost:6869/activation/status
The response includes height, votingInterval, votingThreshold, nextCheck and a features list with each feature’s status.
Unsupported features#
By default dcc.features.auto-shutdown-on-unsupported-feature = yes: if the network activates a feature your node does not know, the node shuts down rather than follow a chain it cannot validate. The fix is to upgrade. Generators can list the features they vote for in dcc.features.supported.
Feature list in v1.8.0#
ID |
Feature |
|---|---|
1 |
Minimum generating balance of 1000 DCC |
2 |
NG protocol |
3 |
Mass Transfer transaction |
4 |
Smart accounts |
5 |
Data transaction |
6 |
Burn any tokens |
7 |
Fee sponsorship |
8 |
Fair PoS |
9 |
Smart assets |
10 |
Smart account trading |
11 |
Ride 4 dApps |
12 |
Order version 3 |
13 |
Reduced NFT fee |
14 |
Block reward and community-driven monetary policy |
15 |
Ride V4, VRF, Protobuf, failed transactions |
16 |
Ride V5, dApp-to-dApp invocations |
17 |
Ride V6, MetaMask support |
18 |
Consensus and MetaMask updates |
19 |
Block reward distribution |
20 |
Capped buy-back and DAO amounts |
21 |
Cease buy-back |
22 |
Light node |
23 |
Boost block reward |
24 |
|
25 |
Deterministic finality and Ride V9 |
26 |
Adjusted block reward distribution |
27 |
Continuation transaction (not exposed) |
28 |
Lease expiration (not exposed) |
Important
Since v1.8.0 the numbering of the last features differs from v1.7.0: 26 = Adjusted Block Reward Distribution, 27 = Continuation transaction, 28 = Lease expiration, and the Groth16 verifier is no longer a feature. Only feature 26 is votable and reported in /activation/status; 27 and 28 are defined in the source but not exposed.
Which of these are active on a given network is a runtime fact — read it from /activation/status rather than from this table.
Finality and HotStuff#
Finality is provided by Deterministic Finality (feature 25). The node also contains a HotStuff BFT fast-finality engine, controlled by dcc.hotstuff.enabled. It is off by default and gated on an external audit before any Mainnet use. Do not enable it on a Mainnet node. When it is enabled, /node/status additionally reports hotStuffFinalizedHeight.
Note
On the public Testnet, HotStuff is enabled and authoritative. The Testnet’s own nodes run dcc.hotstuff.enabled = true and dcc.hotstuff.authoritative = true, so a HotStuff commit certificate raises the finalized height that /blocks/height/finalized reports. That is why Testnet finality runs only a few blocks behind the tip (hotStuffFinalizedHeight in /node/status). Mainnet does not run HotStuff. Integrators should not expect Testnet finality latency on Mainnet.