Testnet DayLight | Release Cycle Update #9


Our development planning features a Release Cycle of three weeks, providing a consistent stream of updates to the community, developers, and businesses relying on Dusk technology.

The publicly available Dusk Network GitHub contains over 18 active
repositories, each focused on a different technical subject. Progress in
each is ongoing and can be followed in real-time. The Release Cycle
process is currently applied to some of our most active repositories.

Release Cycle planning has not yet been applied to all repositories.
When they are, future installments of the Release Cycle updates will see
an expansion of repositories in the spotlight.

For the community’s benefit, we’ve chosen a selection of some (but not
all) of the work that is being done in our repositories, including
recent advancements.


Open issues

Create Badge component #736

Create a new atom component that presents text in a Badge.

The Badge must support a standard set of variants: ‘success’, ‘warning’,
‘danger’ and ‘brand’.

Reinstate Draw component #735

This is needed for developing applications with slide-out sidebar menus.

Add cms-connector models and schemas in published UI Kit__ #719__

The models and schemas that are generated and maintained in the
cms-connector repository are to be published with the UI Kit packages.
This can be achieved by removing the private property from the

Improve and expand test coverage__ #715__

The goal is to increase the number of tests that we run on the
components. This will result in the ability to see property values
changing and testing for the correct output. Testing for visual
differences can also be explored with Chromatic (or alternative, if
deemed more suitable).

Closed issues

Navbar needs to support networks and navigation props #712

The Navbar component needs to support networks and navigation as
additional props and render the appropriate UI when these values are

DateText component throwing errors #737

The underlying date library (dayjs) throws errors relating to commonJS
loading. Attempts to exclude the library from the optimized dependencies
have failed.


Closed issues

Remove genesis consistency checks #1464

At the moment of writing, dusk-blockchain repo is used to hardcode the
values of rusk’s state-root and the derived genesis-hash.
These were introduced in order to mitigate the possibility of being
error-prone after a breaking change upgrade.
Since we introduced the protocol and rusk versions, the genesis
consistency checks should not be required anymore.


Open issues

Panics should propagate to the caller #79

When performing an inter-contract call, a panic occurring in the called
module should inform the caller that the module panicked, as opposed to
stopping the execution.

This ensures the calling module is able to handle panics of modules
whose code it has no control over.

Missing features and improvements #76

This issue is meant to describe the things still missing from this VM
implementation vs. the previous implementation at rusk-vm, and remaining
necessary improvements.

Closed issues

Do not mandate weealloc #68

At the moment weealloc is hardcoded in the uplink communication library,
this is unnecessarily restrictive and it should be up to module authors
to choose allocation strategy.

Provide debug information to be easily used in modules. #53

Tools for debugging running modules.


Open issues

Implement interactive mode for staker allow transaction__ #98__

Since #85 is merged, we should allow the user to do the same operation
in interactive mode

Add _context___ to errors____ #95__

By Providing the user with more specific error context, the reason why
the program fails will be more understandable for the non(technical)

Notify the user if he tried to create more than 256 addresses for one
wallet__ #92__

We decided to support a maximum of 256 addresses for each wallet (seed),
however there is no error message once the user reaches such a limit.

Document more in detail the configuration for multiple networks__ #89__

To let the user understand how to configure the wallet’s network –
however the default values are the one used the most.

Prover and State server should have the capability to have different ipc
method #77

The prover and state server should have the capability to have different
ipc methods.

Closed issues

no cancel option available__ #97__

When an action is initialized, users can’t cancel it. The only possible
way to come back is to close the wallet, reopen it, unlock it, then
retry the action.

Implement _stake allow___ command__ #83

This is required in order to support by dusk-network/rusk#732.

Quit program if 3 times wrong recovery phrase is given during recovery
process #49

The program should quit after 3 times a wrong phase phrase

If the user is not able to fill in the correct recovery phrase, the
program will exit

Option to correct/ re-enter password if 3x wrong recover wallet__ #46__

Implement an option to correct the password / re-enter password.

Wrong _refund_addr___ description____ #86__

The argument refund_addr for the withdraw command has the following

“Address to which the reward will be sent to”

Implement anyhow and thiserror__ #87__

Implementing anyhow and this error into the error handling.

Wrong condition involved `gas.is_enough()__ #91__

gas.is_enough() will always return Error::NotEnoughGas.

Restoring a wallet prints an unexpected message__ #78__

Recovering a wallet works but prints an unexpected message at the end.

BLS keys exported with wrong extensions__ #84__

When exporting the bls keys, 2 different file should be produced

-   .key - Encrypted BLS key pair for provisioners in dusk-blockchain
   compatible format
-   .cpk - Binary file with the Consensus Public Key

Currently, the extensions are switched

Move focus to single wallet creation__ #72__

Direct the user to create one single wallet, instead of multiple

Improve config.toml__ #57__

A better configuration file for the wallet.


Open issues

Use _tar___ to handle state’s compression instead of ____zip____ #740__

Our servers are *nix base and there is no reason to use zip instead of
tarball files, plus the ergonomics of the tar crates is better than zip

Allow to export a state from rusk-recovery__ #738__

After that rusk is able to get a custom state as input [#734] there is
the need to generate such a state.

Closed issues

Instruct rusk-recovery to generate custom genesis state #737

rusk-recovery should be able to receive a struct containing the desired

rusk: Allow to run rusk in “ephemeral” mode #734

Rusk should be able to run in a sort of ephemeral mode, deleting every
change applied to the state after it quit.

This means that if the user launches rusk twice in a row using this
custom state, any change performed by the first execution should be

In addition, the user should be able to pass a “custom” state to use
(without using a different rusk_profile_dir). The custom state should be
a single file.

stake-contract: implement allowlist #732

An on-chain mechanism to handle staking allowlist.


Open issues

Store the root of a branch separately to the levels #189

At the moment the root of the PoseidonBranch is stored in the last level
of the branch at index 1. Ideally we want the root stored separately to
the levels and not as an additional level.

This is also an issue due to the rkyv implementations. Since it is now a
Vec, PoseidonBranch<17> would parse in the exact same way as
PoseidonBranch<16> for example.

Use _component_boolean___ in the our merkle opening circuit__ #188

Use component_boolean to check for the index bits in our merkle opening

Restructure crate features #184

The features of a crate should be named according to the features they
enable, and not the names or technicalities of its dependencies. I
propose a restructuring of the features of this crate.

Closed issues

Update CHANGELOG__ #191__

Some versions are not properly tagged and fix other minor issues.

Implement _rkyv___ for ____PoseidonBranch__ #186

The rkyv-related traits should be implemented for PoseidonBranch, and
the resulting types be made public.

Fix merkle opening circuit #181

Fix the merkle opening circuit and add tests that catch this in the
future. For people using the repository please be aware of this fix.

PoseidonTree is only available behind __canon__ #180

The PoseidonTree struct - one of the main features of this library, and
a very important component for the genesis contracts - is only available
behind the canon feature.

This means to write a smart contract one is required to bring in the
canonical library even though this is in principle not required.

As you can see, development is continuous and this list is not
exhaustive. For example, minor issues and advancements concerning the
Kadcast element have also been opened and resolved.__ The complete
series of repositories can be found on GitHub.__

Breakthrough developments will receive a separate spotlight, such as our
latest deployment of Daylight__. __Thank you very much for your
understanding and feedback as we continue to find the best way to
provide the community with transparency and development information.

In A Nutshell: Release Cycle planning

Release Cycle development planning has been adopted by major companies
including Google, Mozilla, and during the development of products such
as Ubuntu, Kubernetes, and many more. The reason for this is clear:
Release Cycle planning improves the predictability of software
development for developers and the community alike.

For a more detailed explanation of the concept (along with frequently
asked questions) please scroll down to the bottom of this article.


We’ve included a small FAQ section below to make sure the community
understands our intention with Release Cycles.

What is Release Cycle planning?

Release Cycle planning means that developmental updates are published at
consistent intervals on GitHub; in the case of Dusk Network, every three
weeks. These releases describe the latest additions, changes, fixes, and
assets added to the tech stack by the development team.

Dusk Network currently has over 18+ active repositories on GitHub, each
repository covering a different technical project. Release Cycle
planning has not yet been applied to all repositories; the current focus
on a single GitHub repository for clarity does not mean there are no
ongoing developmental efforts occurring in other areas.

Does being featured in a Release mean Deployment?

The Release Cycle updates does not mean immediate deployments on our
testnet. It is a release detailing additions, changes, and fixes to the
repositories that we are ready to share with the public. All released
content is considered stable, consistent, reviewed, and cross-checked
with other repositories.

Are Release Cycle updates a spotlight for major deliverables?

No. The Release Cycle approach is strictly a way to provide a consistent
shape for publication of our work in the clearest terms possible. They
are not deadlines to be made, nor are they tied to specific development
sprints. Release Cycle updates aim to raise attention with the
community, and give proper coverage to, publishable GitHub releases.
Major deliverables will be given their proper publication in dedicated