$DUSK Dusk has a modular architecture with:
DuskDS – the settlement and data layer (consensus, data availability, native transaction models, protocol contracts, DuskVM).
DuskEVM – the EVM execution layer where most smart contracts and dApps live.
🤖🤖Now comes the dry, professional facts and opportunities that Dusk offers to those interested.🤖🤖
As a builder you usually:
write and deploy contracts on DuskEVM, and
rely on DuskDS for finality, privacy and settlement under the hood.
Expecially for Developers 💪🎉💪:
Developers can deploy smart contracts on DuskEVM using Solidity and familiar tools like Hardhat or Foundry. This is a guide covering the essential information required to deploy smart contracts on DuskEVM.
DuskDS is for advanced builders who want to write Rust/WASM smart contracts directly on DuskDS, the settlement and data layer.
For most dApps, you should deploy on DuskEVM and use DuskDS indirectly.
Smart contracts on DuskDS are used for low‑level protocol logic and specialised applications that need direct access to the settlement layer. If you just want to build a “normal” DeFi, NFT or application contract, prefer DuskEVM.
To develop DuskDS contracts you need:
a recent Rust toolchain with the wasm32-unknown-unknown target;
the tools and versions listed in the Rusk README;
a Rust‑capable editor (VS Code + Rust Analyzer, RustRover, Vim + Rust Analyzer, etc.).
Transactions on Dusk follow a specific lifecycle. Here’s a basic overview:
Creation: The process begins when a wallet or similar software generates a new transaction.
Broadcasting: The transaction is sent out to the Dusk network and broadcast within it.
Validation: Each node receiving the transaction verifies its validity before adding it to the Mempool.
Inclusion in Mempool: The transaction is added to the Mempool (transaction included event).
If the transaction expires before being added to a block, it is removed from the Mempool (transaction removed event).
If the transaction is replaced by another transaction with higher gas price, it is removed from the Mempool (transaction removed event)
Inclusion in candidate block: A block generator includes the transaction from the Mempool into a candidate block.
If the transaction is discarded during the block generation, it is removed from the Mempool (this event is currently not emitted1)
Acceptance: The block containing the transaction is accepted into the blockchain (block accepted event).
Execution: When accepting the block, the transaction is executed (transaction executed event).
Successful Transaction: No errors available
Reverted or Failed Transaction: Errors available (transaction executed event with error field available). This is contract-specific and indicates a revert (panic) or other error that was returned.
Removal from Mempool: The transaction is removed from the mempool (transaction removed event).
Confirmation: The block is confirmed, making the transaction unlikely to be reverted (block state-change event with state changed to confirmed).
Finalization: The block reaches finality, making the transaction immutable and irreversible. (block state-change event with state changed to finalized).
Failed Transactions
Failed transactions are defined here as a concept at the contract level. DUSK assume that each contract, just like the transfer contract or other genesis contracts, makes use of proper error handling and panics:
If a contract panics, the transaction is reverted and there will be an error to look at.
If a contract returns a result that contains an error, there will also be an error to look at.
Both of these are contract specific, the chain still executed the transaction successfully - according to the code of the smart contract.
A failed or reversed transaction has nothing to do with Dusk itself directly. The transaction was successfully executed according to Dusk’s rules and recorded on the blockchain, hence the transaction executed event.
Before reaching finality, blocks sometimes revert according to consensus rules.
This can happen during steps 6 and 7, (block reverted event). In such cases, you need to re-listen for transaction events to get the required information.
What is a DIP on #Dusk ?
A Dusk Improvement Proposal (DIP) is a formal document that proposes a new feature, standard, or protocol adjustment within Dusk. DIPs are the primary mechanism for proposing new features, collecting community input on an issue, and documenting the design decisions that have gone into the Dusk protocol architecture. They are meant to be the source of truth for Dusk protocol improvements, serving both as a historical document and a detailed explanation of the feature and its purpose.
A DIP may be required to enable specific use-cases, as the Dusk protocol encompasses all rules that nodes must follow in order to:
Achieve consensus
Achieve synchronism
Create, validate, and process transactions
Purpose
The DIP repository is intended to provide a structured process for making substantive changes to the Dusk protocol. Its goals are to:
Ensure that proposed improvements are thoroughly discussed and evaluated
Create a transparent and inclusive process for governance
Facilitate the collection and documentation of a coherent and comprehensive history of governance and feature proposals
Encourage active community participation and collaboration
If You really are intrested in building and developing, follow this link to learn : https://docs.dusk.network/developer/overview/
