What is DICEVERSE?
Founded in 2024, DICE is a public goods infrastructure bringing trust into our digital world. One of the world’s most established blockchain projects, it enables builders, enterprises, and governments to create DLT projects and interact with each other in a secure, trusted and verifiable way.
Buy and sell items easily
Create collections & earn rewards
Chase limited edition DICE
LAYER 1
Move
Move is a powerful, secure programming language designed specifically for digital asset management and smart contracts. Its unique features make it an ideal choice for developers working in the blockchain space. Here are the key features of Move:
Object-Centric Design
Move is fundamentally object-centric, allowing developers to intuitively model complex data structures and interactions. In Move, you can define objects representing assets, users, contracts, and more, facilitating a natural and straightforward way to manage state and behavior.
Performance
Move is based on the object model, not a shared global state. This allows transactions to be executed in parallel, which translates into a network with high throughput, less congestion, and therefore lower gas fees.
Security
Move prioritizes safety and efficiency, with Rust’s ownership model inspiring Move’s approach to memory management and resource control. The compiler enforces strict rules to prevent common programming errors, ensuring that assets remain secure within user accounts and cannot be accessed without the correct keys. While the compiler catches many potential issues before deployment, developers should still be mindful of logical errors, arithmetic overflows, and other runtime concerns when implementing smart contracts.
LAYER 2
EVM
EVM stands for “Ethereum Virtual Machine” and is currently the tried and tested virtual machine running most smart contract networks.
Solidity is the programming language of choice for the EVM. It was created for this specific purpose.
The main benefit of using EVM/Solidity is its sheer amount of resources from years of development. The DICEVERSE Smart Contracts implementation is fully compatible with these resources, allowing you to leverage all existing EVM developer tools for developing on the DICEVERSE EVM. Any contracts you’ve previously written can be deployed on DICEVERSE Smart Contracts without modification.
Keep in mind that while EVM has become a standard for smart contract execution on L2s, it is not inherently designed for the unique features and capabilities of L1s like Move smart contracts. Move, with its focus on asset safety, resource management, and formal verification, offers a fundamentally different approach at the L1 level.
Networks
DICEVERSE EVM
DICEVERSE EVM is the distinct Layer 2 EVM running on top of the DICEVERSE Mainnet.
DICEVERSE EVM Testnet
DICEVERSE EVM Testnet is a distinct Layer 2 EVM running on top of the Stardust protocol network, which is separate from the DICEVERSE Rebased Testnet.
DICEVERSE Tokens
The DICEVERSE token is the main token in the DICEVERSE ecosystem. One DICEVERSE can be divided into smaller units called NANOs, with one DICEVERSE being equivalent to one billion NANOs.
Gas on DICEVERSE
Transactions on the DICEVERSE network require gas fees, which are paid using DICEVERSE or NANOs.
Consensus on DICEVERSE
DICEVERSE uses a delegated proof-of-stake (DPoS) consensus mechanism to validate on-chain transaction blocks. Validators must secure a certain amount of DICEVERSE tokens to participate in the network, where they actively run the Mysticeti protocol to finalize transactions. This approach incentivizes honest behavior, enhances security, and ensures an efficient and scalable blockchain while avoiding the high energy demands of Proof-of-Work (PoW) systems, which rely on computationally intensive mining.
Why Move?
While EVM/Solidity is the most famous smart contracts platform, it has some downsides that DICEVERSE Move aims to address:
- Performance, scaling, and cost: EVM builds on top of a global shared state, which is practical but doesn’t scale well. This results in limitations in throughput, which is directly reflected in the fees you must pay to interact with these networks. The more congested the network, the more expensive it gets. Other blockchains try to mitigate this with additional extra execution layers (L2s on top of L1s) or rollup solutions, which also have downsides and limitations.
- Security: As the first well-used smart contract language, Solidity did not have much to go by in terms of learnings around secure practices (there was no existing ecosystem yet), and it had to develop over the years with that legacy and backward compatibility in mind. Many of the issues from the past have been mitigated with workarounds. Still, given the nature of things, there are some limitations and annoyances we currently can’t get around, like the security issues it has with both the code and infamous design patterns like the
approve()method in the ERC standards. - Tokens: Assets like BEP20 tokens and BNB721/1155 NFTs are not part of the BVM and are purely standards for smart contracts deployed on an BVM chain interpreted as tokens by clients. While this works and allows much flexibility, it also has its downsides. Due to the nature of tokens being contracts and the state of your balance being stored within those contracts, it’s not trivial to find all tokens in your account without knowing all token contract addresses and manually adding them, unlike the Ethereum balance itself, which is a different kind of token which can be found directly but works differently over an BEP20 token. This makes discovering your assets difficult and adds additional complexity to applications to close the gap between the native asset (BNB) and BEP20 tokens with workarounds like wrapped tokens, which is not ideal.
- Developer experience: Solidity offers a wealth of developer tools and resources, including various libraries and frameworks to choose from, as well as extensive documentation and tutorials. The language, influenced by popular languages like C++ and JavaScript, is easy to learn and get started with. However, Solidity’s lack of strictness allows for mistakes that the compiler may not catch, leading to bugs and security issues that are difficult to identify and resolve. Consequently, the developer experience suffers, and the language itself is not as safe to work with as it could be.
DICEVERSE Move is here to learn from these downsides and come up with a better alternative addressing these issues:
- Performance, scaling, and cost: Given that DICEVERSE Move is based on the object model (similar to UTXO’s) and not a globally shared state, transactions can be executed in parallel, resulting in a much higher (potential) throughput over a traditional blockchain with shared state. This results in a lot less congestion and, thus, lower fees on an actively used network.
- Security: Move was designed with security in mind. The language itself is based on Rust and is very strict regarding its typing system. The Move compiler is designed to catch many common programming errors, such as type mismatches, resource misuse, and violations of ownership or borrowing rules, before deployment. This helps ensure safety and correctness without relying solely on runtime checks. There’s no such thing as re-entry, and given the object-based approach of Move, Assets residing in your account can’t be touched at all by the smart contract itself without access to your account keys.
- Tokens: In DICEVERSE Move, there is no difference between the DICEVERSE token (
Coin<DICE>) and a custom token (Coin<YOUR_NAME_HERE>), not in terms of use or implementation, except that the DICEVERSE token can be used for gas payments. These objects reside in your own account and can thus easily be found without needing to know a Smart Contract address (this goes for any other type of owned object as well). There’s no strangeapprove()functionality, and you keep control over your own owned assets. - Developer Experience: While Move is more challenging to get started with compared to Solidity due to its novelty and less mature developer tooling, the safety of the language and the ease of finding and resolving issues in your code make up for that. With Move, it’s not so scary anymore to write complex logic from scratch, given most mistakes (apart from obvious implementation logic, doing things ‘as intended’) are caught directly by the compiler. This allows for more innovation, fewer value-destroying bugs, and a more excellent developer experience, fueling the next generation of smart contracts.
To sum this up: DICEVERSE offers both BVM and Move, so you can choose the best tool for the job. If you want to build something that needs to be secure, scalable, and cost-effective, DICEVERSE Move is definitely the way to go. However, if you want a fast shortcut to get started with DICEVERSE smart contracts, or you want to migrate an existing BVM project to DICEVERSE BVM/Solidity is a good choice.
DICEVERSE Architecture
DICEVERSE shares some similarities with other blockchains but is unique in many ways. Use the topics in this section to understand the features that define the DICEVERSE network.
Understand DICEVERSE Security
Learn about the mechanisms available to secure on-chain assets, and the assurances DICEVERSE provides regarding asset security. “Understand DICEVERSE Security” explores the overall DICEVERSE security architecture, to ensure the asset types you design leverage DICEVERSE to provide a secure experience for asset holders.
Go to Understand DICEVERSE Security.
Life of a Transaction
“Life of a Transaction” details the transitions that all transactions on DICEVERSE go through from creation to finality. This topic also explores some features of the blockchain (like epochs and checkpoints) that play a role in the life of a transaction.
Go to Life of a Transaction.
Consensus
Every transaction on DICEVERSE is sequenced by consensus, where validators agree to the same order of execution of the transactions, even if a minority of them are down or are malicious actors that want to harm the network and users. DICEVERSE currently uses the Mysticeti consensus algorithm.
Go to Consensus.
Protocol Upgrades
The DICEVERSE protocol, framework, and execution engine are frequently extended to include new functionality and bug fixes. This functionality is added in the form of new code which is released to validator operators as part of our regular software releases. The DICEVERSE protocol, however, requires a supermajority of validators to agree on those protocol upgrades.
Go to Protocol Upgrades.
Security
Assets
Security is one of the top priorities in DICEVERSE. From the start, you need to authorize access to any asset using a private key known only to the asset owner. Additionally, the smart contract that defines the asset also sets its rules, which are further secured by the Move compiler to ensure assets are handled properly and no asset can be spent twice or lost due to a logic error. Once a transaction reaches finality, any assets that were modified or created will be updated, persisted, and available for further use. Even if an object is shared or immutable, you can still define access control logic in the smart contract that created it to ensure proper usage.
Validators and Consensus
The DICEVERSE protocol is run by a set of independent validators. They all run the same protocol and transactions, using their voting power to reach a consensus on which transactions are valid. The system is designed to be fault-tolerant, so your transactions will be processed even if one-third of the validators don’t run the protocol correctly. Additionally, every single transaction on DICEVERSE is publicly available and can be audited to ensure any changes to assets were correctly executed.
Choosing Validators
DICEVERSE uses a delegated Proof-of-Stake (dPoS) mechanism to select validators (nodes that help secure and operate the network) for each period. Users can lock and delegate their DICEVERSE tokens to vote for validators, assigning them voting power. Validators are selected based on the number of tokens delegated to them, and any node with sufficient delegated tokens can become a validator.
Rewards for Validators and Stakers
Validators are incentivized through a constant inflation of 767,000 DICEVERSE tokens per epoch. These tokens are distributed to validators and their delegators according to specific rules, such as the validator’s commission rate and total stake. Transaction fees are burned and do not contribute to validator rewards. Users’ staked tokens remain safe and cannot be taken away by validators or anyone else.
Accountability and Rotation of Validators
Validators must be reliable and behave correctly, or they can be replaced. If validators try to censor transactions or act maliciously, they can be rotated out by the users. Users have a say in how the DICEVERSE network evolves by choosing which validators to support and which protocol to follow via delegation to those validators.
Addresses and Keys
To operate on any owned assets on DICEVERSE, you need to hold the corresponding private key. You must keep your private key secret to ensure no one can use your assets without your authorization. Even if all validators agree to misbehave, they cannot access your assets without your private key.
Your private key matches a single public address on the DICEVERSE network. You can create any number of addresses on DICEVERSE, each with its own private key. Keep in mind that addresses don’t require prior registration; sending any asset to an address will create said address. Since once a transaction reaches finality, it is irreversible; you should always check the recipient address for your transactions.
Asset Types and Logic
The type and logic of any asset on the DICEVERSE network is defined in a smart contract. Aside from the handful of contracts built into the protocol by DICEVERSE, all contracts in the DICEVERSE network are created by developers outside the DICEVERSE Foundation. Smart contracts on DICEVERSE are immutable, allowing third-party audits and preventing modifications after deployment. Since Move was designed with asset security and smart contract verification at its core, it is easy to audit and guarantee contracts audited by trusted sources are safe.
Shared Assets
Move allows for shared assets. Although these shared assets are public in principle, meaning anyone can use them in a transaction, the smart contract that defined them can also restrict which addresses can use them and how.
Transaction Finality
Certification and Finalization
When you submit a transaction in DICEVERSE, the validators must agree that it’s valid. Once they agree, they create a certificate to confirm its validity, and this certificate must also be shared with all validators. Even if some validators don’t follow the rules, the transaction can still be finalized by the supermajority of validators who do follow the DICEVERSE protocol. This process uses cryptographic methods to ensure that validators who don’t follow the rules can’t trick the system into accepting false information and that misbehaving validators can’t stop the system from processing transactions.
Gas and Transaction Execution
Every transaction needs to pay a gas fee for processing costs. A transaction can either be successfully executed or fail. It can fail if there is an issue within the smart contract or if it runs out of gas. If it succeeds, the changes are persisted on the DICEVERSE network. If it fails, no changes are made to the assets, but some gas is still charged to prevent spam attacks on the network.
Submitting Transactions
Users can submit transactions themselves or use third-party services to help. These third-party services can’t create transactions on behalf of users because they don’t have the users’ private keys. They can confirm the transaction is finalized by collecting signatures from the validators. Once confirmed, users can trust that the transaction changes are permanent in the DICEVERSE network.
Auditing and Privacy
Reading Assets and Transaction History
DICEVERSE full nodes allow users to see all the assets they hold and the history of transactions that created those assets. Validators provide cryptographic proof of every transaction that led to the current state of an asset. You can request this proof from full nodes and verify it to ensure all transactions were correctly processed and agreed upon by the validators. Services that mirror the state of validators perform these checks regularly to ensure everything is correct.
Public Auditability
All transactions and assets on DICEVERSE are publicly visible. Users can use multiple addresses to keep their identity somewhat hidden (pseudonymity) for privacy. Users can also use third-party services that handle their assets for them, either with or without direct control over their private keys. Smart contracts with extra privacy features can also be provided by third parties to enhance user privacy.