# Welcome

The Blockchain For Staker

## Introduction <a href="#introduction" id="introduction"></a>

Welcome to the official documentation of DaVinci Chain, a **Layer 1 blockchain** built with **Ethereum Virtual Machine (EVM) compatibility** and an identical **consensus mechanism** to Ethereum. Our goal is to provide a seamless and efficient blockchain environment that maintains the decentralization, security, and flexibility of the Ethereum network while offering a dedicated infrastructure for developers and users.

### **Ethereum-Compatible Infrastructure**

DaVinci blockchain is **identical to Ethereum** in terms of its core architecture, consensus mechanism, and execution environment. It supports the same **consensus algorithm**, ensuring full compatibility with existing Ethereum-based tools, wallets, and smart contract deployments.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>DaVinci Chain</strong></td><td>DaVinci Chain is the EVM Blockchain Based Ethereum Layer One</td><td><a href="/files/xDjN5VZ7J53MdGKB0OJh">/files/xDjN5VZ7J53MdGKB0OJh</a></td><td><a href="/pages/xvkeiVUKZckBt3gGvrIX">/pages/xvkeiVUKZckBt3gGvrIX</a></td></tr><tr><td><strong>Learn</strong></td><td>DaVinci Chain is the EVM Blockchain Based Ethereum Layer One</td><td><a href="/files/QkfmvtUh91bAmaGGqEwg">/files/QkfmvtUh91bAmaGGqEwg</a></td><td><a href="/pages/FvWvqlGCMVet71BcpeNh">/pages/FvWvqlGCMVet71BcpeNh</a></td></tr><tr><td><strong>Developers</strong></td><td>DaVinci Chain is the EVM Blockchain Based Ethereum Layer One</td><td><a href="/files/KCxrLiMGCnQNuElDXdEJ">/files/KCxrLiMGCnQNuElDXdEJ</a></td><td><a href="/pages/LUPQH2DsWL30z5isTX1n">/pages/LUPQH2DsWL30z5isTX1n</a></td></tr></tbody></table>


# Learn

### **Why DaVinci Blockchain?**

As blockchain technology evolves, the need for **Ethereum-compatible** networks continues to grow. Our blockchain enables developers, businesses, and users to benefit from the vast ecosystem of Ethereum without dealing with congestion or high transaction fees. By mirroring Ethereum’s architecture, we ensure:

✅ **Full EVM Support** – Deploy smart contracts, dApps, and tokens (ERC-20, ERC-721, etc.) just as you would on Ethereum.\
✅ **Identical Consensus Mechanism** – Our blockchain employs the same consensus model as Ethereum, ensuring decentralization and security.\
✅ **Seamless Interoperability** – Compatible with Metamask, Web3.js, Hardhat, Truffle, and other Ethereum tools.\
✅ **Scalability & Customization** – While maintaining Ethereum’s architecture, our network allows for tailored optimizations and governance.

### **Core Features**

* **Proof Of Stake Consensus** – The network utilizes Ethereum’s well-established consensus algorithm, providing trust and reliability.
* **Smart Contract Execution** – Write and deploy smart contracts using Solidity without any modifications.
* **Native Token & Gas Fees** – Transactions and contract executions require gas fees, similar to Ethereum, ensuring network integrity.
* **Developer-Friendly Environment** – Familiar tools, frameworks, and libraries allow for quick and efficient development.
* **Secure & Decentralized** – By leveraging Ethereum’s security model, we ensure resistance to attacks and maintain network robustness.

### **Who Can Benefit from This Blockchain?**

🔹 **Developers** – Easily migrate existing Ethereum projects without rewriting code.\
🔹 **Businesses & Enterprises** – Build secure and transparent apps leveraging blockchain technology.\
🔹 **Crypto Enthusiasts** – Engage in decentralized finance (DeFi), NFTs, and more within a familiar ecosystem.

### What Should I Read?[​](https://docs.astria.org/overview/introduction#what-should-i-read) <a href="#what-should-i-read" id="what-should-i-read"></a>

Want to learn more about about DaVinci Chain? Check out the [How Validator Works](/learn/validator-mechanism) or [How Blockchain Works.](/learn/proof-of-stake-mechanism)


# Execution Layer

## **Introduction**

The **DaVinci Chain Execution Layer** is responsible for processing transactions, executing smart contracts, and maintaining the state of the blockchain. As a fully **DaVinci Virtual Machine (DVM) Layer 1 blockchain**, DaVinci Chain follows the same execution model as Ethereum, ensuring compatibility with existing Ethereum-based tools and applications.

### **Overview of the Execution Layer**

The Execution Layer is a crucial component of DaVinci Chain, responsible for handling:

* **Transaction Processing** – Validating and executing user transactions.
* **Smart Contract Execution** – Running decentralized applications (dApps) and executing Solidity-based smart contracts.
* **State Management** – Updating account balances, contract storage, and network state after transaction execution.
* **EVM Compatibility** – Ensuring seamless interaction with Ethereum-based wallets, tools, and protocols.

### **Core Components of the Execution Layer**

1. **DaVinci Virtual Machine (DVM)**
   * Executes smart contracts and processes transactions within the DaVinci Chain network.
   * Fully compatible with Solidity, Vyper, and other Ethereum-based development languages.
2. **Transactions & Gas Fees**
   * Transactions require gas fees, similar to Ethereum, to prevent spam and allocate network resources efficiently.
   * Gas fees are paid in the native token of DaVinci Chain.
3. **Smart Contract Execution**
   * Developers can deploy and interact with smart contracts using Ethereum-standard tools like **Remix, Hardhat, Truffle, and Web3.js**.
   * Supports ERC-20, ERC-721, and other Ethereum token standards.
4. **State Management**
   * The Execution Layer updates the blockchain state by processing transactions and storing contract states.
   * Utilizes Merkle Patricia Tries for efficient storage and retrieval of account data.
5. **Interoperability**
   * DaVinci Chain’s Execution Layer is designed for seamless integration with existing Ethereum infrastructure.
   * Supports Ethereum’s JSON-RPC API, allowing easy interaction with wallets like **Metamask, Trust Wallet,** and other.

### **How the Execution Layer Works**

1. **Transaction Submission** – Users submit transactions through wallets or dApps.
2. **Transaction Validation** – Transactions are verified by the network’s nodes.
3. **Execution in the EVM** – The smart contract code is executed within the EVM environment.
4. **State Update** – The blockchain state is updated based on the execution results.
5. **Block Finalization** – Valid transactions are added to new blocks and propagated across the network.

### **Developer Tools & Integration**

To build on DaVinci Chain, developers can use:

* **Solidity & Vyper** for smart contract development.
* **Truffle & Hardhat** for contract deployment and testing.
* **Web3.js & Ethers.js** for blockchain interactions.
* **Metamask & WalletConnect** for user authentication and transactions.


# Proof Of Stake Mechanism

## What is proof-of-stake (PoS)? <a href="#what-is-pos" id="what-is-pos"></a>

Proof-of-stake is a way to prove that validators have put something of value into the network that can be destroyed if they act dishonestly. In DaVinci proof-of-stake, validators explicitly stake capital in the form of DCOIN into a smart contract on DaVinci. The validator is then responsible for checking that new blocks propagated over the network are valid and occasionally creating and propagating new blocks themselves. If they try to defraud the network (for example by proposing multiple blocks when they ought to send one or sending conflicting attestations), some or all of their staked DCOIN can be destroyed.

### Economic security <a href="#crypto-economic-security" id="crypto-economic-security"></a>

Running a validator is a commitment. The validator is expected to maintain sufficient hardware and connectivity to participate in block validation and proposal. In return, the validator is paid in DCOIN (their staked balance increases). On the other hand, participating as a validator also opens new avenues for users to attack the network for personal gain or sabotage. To prevent this, validators miss out on ETH rewards if they fail to participate when called upon, and their existing stake can be destroyed if they behave dishonestly. Two primary behaviors can be considered dishonest: proposing multiple blocks in a single slot (equivocating) and submitting contradictory attestations.

The amount of DCOIN slashed depends on how many validators are also being slashed at around the same time. This is known as the "correlation penalty", and it can be minor (\~1% stake for a single validator slashed on their own) or can result in 100% of the validator's stake getting destroyed (mass slashing event). It is imposed halfway through a forced exit period that begins with an immediate penalty (up to 1 DCOIN ) on Day 1, the correlation penalty on Day 18, and finally, ejection from the network on Day 36. They receive minor attestation penalties every day because they are present on the network but not submitting votes. This all means a coordinated attack would be very costly for the attacker.

### Rewards <a href="#rewards" id="rewards"></a>

Validators receive rewards when they make votes that are consistent with the majority of other validators, when they propose blocks, and when they participate in sync committees. The value of the rewards in each epoch are calculated from a `base_reward`. This is the base unit that other rewards are calculated from. The `base_reward` represents the average reward received by a validator under optimal conditions per epoch. This is calculated from the validator's effective balance and the total number of active validators as follows:

{% code overflow="wrap" %}

```
1base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))
```

{% endcode %}

where `base_reward_factor` is 64, `base_rewards_per_epoch` is 4 and `sum(active balance)` is the total staked ether across all active validators.

This means the base reward is proportional to the validator's effective balance and inversely proportional to the number of validators on the network. The more validators, the greater the overall issuance (as `sqrt(N)` but the smaller the `base_reward` per validator (as `1/sqrt(N)`). These factors influence the APR for a staking node.

The total reward is then calculated as the sum of five components that each have a weighting that determines how much each component adds to the total reward. The components are:

```
1. source vote: the validator has made a timely vote for the correct source checkpoint
2. target vote: the validator has made a timely vote for the correct target checkpoint
3. head vote: the validator has made a timely vote for the correct head block
4. sync committee reward: the validator has participated in a sync committee
5. proposer reward: the validator has proposed a block in the correct slot
```

The weightings for each component are as follows:

```yaml
1TIMELY_SOURCE_WEIGHT uint64(14)
2TIMELY_TARGET_WEIGHT uint64(26)
3TIMELY_HEAD_WEIGHT   uint64(14)
4SYNC_REWARD_WEIGHT   uint64(2)
5PROPOSER_WEIGHT      uint64(8)
```

These weights sum to 64. The reward is calculated as the sum of the applicable weights divided by 64. A validator that has made timely source, target and head votes, proposed a block and participated in a sync committee could receive `64/64 * base_reward == base_reward`. However, a validator is not usually a block proposer, so their maximum reward is `64-8 /64 * base_reward == 7/8 * base_reward`. Validators that are neither block proposers nor in a sync committee can receive `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`.

An additional reward is added to incentivize rapid attestations. This is the `inclusion_delay_reward`. This has a value equal to the `base_reward` multiplied by `1/delay` where `delay` is the number of slots separating the block proposal and attestation. For example, if the attestation is submitted within one slot of the block proposal the attestor receives `base_reward * 1/1 == base_reward`. If the attestation arrives in the next slot, the attestor receives `base_reward * 1/2` and so on.

Block proposers receive `8 / 64 * base_reward` for **each valid attestation** included in the block, so the actual value of the reward scales with the number of attesting validators. Block proposers can also increase their reward by including evidence of misbehavior by other validators in their proposed block. These rewards are the "carrots" that encourage validator honesty. A block proposer which includes slashing will be rewarded with the `slashed_validators_effective_balance / 512`.

### Penalties <a href="#penalties" id="penalties"></a>

So far we have considered perfectly well-behaved validators, but what about validators that do not make timely head, source and target votes or do so slowly?

The penalties for missing the target and source votes are equal to the rewards the attestor would have received had they submitted them. This means that instead of having the reward added to their balance, they have an equal value removed from their balance. There is no penalty for missing the head vote (i.e. head votes are only rewarded, never penalized). There is no penalty associated with the `inclusion_delay` - the reward will simply not be added to the validator's balance. There is also no penalty for failing to propose a block.


# Validator Mechanism

## **Blocks**

The basic primitive that underlies blockchain technology is, of course, the block.

A block comprises a set of transactions that a leader (the block proposer) has assembled. A block's contents (its payload) may vary according to the protocol.

* The payload of a block on DaVinci execution chain is a list of user transactions.
* The payload of a block on the pre-Merge proof of stake beacon chain was (mostly) a set of attestations made by other validators.
* Post-Merge beacon chain blocks also contain the execution payload (the user transactions).

Except for the special Genesis block, every block builds on and points to a parent block. Thus, we end up with a chain of blocks: a blockchain. Whatever the contents of blocks, the goal of the protocol is for all nodes on the network to agree on the same history of the blockchain.

<figure><img src="/files/Lvlaqk7q6dgAuVFisW3T" alt=""><figcaption><p>A blockchain time moves from left to right and, except for the Genesis block, each block points to the parent block it builds on.</p></figcaption></figure>

The chain grows as nodes add their blocks to its tip. This is accomplished by temporarily selecting a "leader", an individual node that has the right to extend the chain. In proof of work the leader is the miner that first solves the proof of work puzzle for its block. In DaVinci proof of stake the leader is selected pseudo-randomly from the pool of active stakers.

The leader (usually known as the block proposer) adds a single block to the chain, and has full responsibility for selecting and ordering the contents of that block, though its block must be valid according to the protocol rules otherwise the rest of the network will simply ignore it.

### **Block Trees**

Our neat diagram of a nice linear chain will for the most part reflect what we see in practice, but not always. Sometimes, due perhaps to network delays, or a dishonest block proposer, or client bugs, any particular node might see something more like the following.

<figure><img src="/files/7u4yInqectYs63Zc0KPH" alt=""><figcaption><p>In general, we might end up with a block tree rather than a block chain. Again, time moves from left to right and each block points to the parent block it builds on.</p></figcaption></figure>

In real networks we can end up with something more like a block tree than a block chain. In this example very few blocks are built on their "obvious" parent.

Why did the proposer of block $$C$$ build on $$A$$ rather than $$B$$?

* It may be that the proposer of $$C$$ had not received block $$B$$ by the time it was ready to make its proposal.
* It may be that the proposer of $$C$$ deliberately wanted to exclude block $$B$$ from its chain, for example to steal its transactions, or to censor some transaction in $$B$$.
* It may be that the proposer of $$C$$ thought that block $$B$$ was invalid for some reason.

The first two reasons, at least, are indistinguishable to the wider network. All we know is that $$C$$ built on $$A$$, and we can never know why for certain.

Similarly, why did the proposer of block $$D$$ build on $$B$$ rather than $$C$$? Any of the above reasons apply, and we can add another:

* The proposer of $$D$$ may have decided on some basis that there was more chance of the wider network eventually including $$B$$ than $$C$$. Thus, building $$D$$ on $$B$$ gives it more chance of making it into the eventual block chain, than building $$D$$ on $$C$$.

The various branches in the block tree are called "forks". Forks happen naturally as a consequence of network and processing delays. But they can also occur due to client faults, malicious client behaviour, or protocol upgrades that change the rules, making old blocks invalid with respect to the new rules. The last of these is often called a "hard fork".

### Finality

Finality is an existing block proposal mechanism, by which we mean that it takes an existing block tree and prunes it in some way. Finality modifies the branching options of the underlying block tree by making some of its branches inaccessible.

Consider this block tree produced by some underlying consensus mechanisms

<figure><img src="/files/bcBJZgKOnNXuXMWrVV15" alt=""><figcaption><p>An arbitrary block tree with three forks (branches). Any of blocks <span class="math">I</span>, <span class="math">E</span>, or <span class="math">M</span> could be the tip of the chain. (The block labels are for convenience and do not imply a particular ordering.)</p></figcaption></figure>


# Staking Mechanism

## Overview <a href="#overview" id="overview"></a>

As a proof of stake protocol, DaVinci depends on stakers locking up capital within the protocol (deposits), and, eventually, receiving that capital back along with the rewards they have earned (withdrawals).

The form of capital that is staked is DaVin (DCOIN), DaVinci native currency. DaVin on the consensus layer exists separately, and is accounted for separately, from DaVin in normal DaVinci accounts and contracts. DaVin on the consensus layer is in the form of balances of validator accounts. Validator accounts are extremely limited: they have a balance that increases due to deposits and rewards, and decreases due to withdrawals and penalties. You cannot make transfers between validator accounts or run any kind of transaction on them. Validator account balances are tracked as part of the beacon state, and do not form part of the normal DaVinci execution state. Note that execution balances are denominated in Wei ($$10^{-18}$$ DCOIN), whereas validator balances are denominated in Gwei ($$10^{-9}$$ DCOIN).

{% hint style="info" %}
**For Your Information**
{% endhint %}

* Deposits are transfers of DCOIN from the execution layer to the consensus layer.
* Withdrawals are transfers of DCOIN from the consensus layer5 to the execution layer.
* Accounting on each layer is completely separate.
* Stakers send transactions to the deposit contract in order to stake.
* Staking is permissionless.
* Withdrawals are periodic and automatic.
* Withdrawals are either partial or full.

### The Deposit Contract <a href="#the-deposit-contract" id="the-deposit-contract"></a>

The deposit contract is the means by which stakers commit their DCOIN to the protocol in order to gain the right to run a validator.

The deposit contract is a normal DaVinci smart contract running on the execution layer. Anyone wishing to place a stake in order to run a validator may send 32 DCOIN to the deposit contract via a normal DaVinci transaction.

In addition to the DCOIN transferred, the deposit transaction must contain further data as follows.

First, the public key of the validator. A validator's public key is derived from its secret signing key, and is its primary identity on the consensus layer. The staker will provide the secret signing key separately to the consensus client for normal operational use.

Second, withdrawal credentials specifying which DaVinci account rewards earned will be sent to. This will also be the address that receives the validator's full balance when it eventually exits.&#x20;

Third, a signature over the public key, the withdrawal credentials, and the deposit amount, using the normal signing key. This signature's main role is to serve as a "proof of possession" of the secret key of the validator, which side-steps a nasty rogue public key attack.

Fourth, the deposit data root, which is an *SSZ Merkleization* of all of the above data that serves as a kind of checksum that the contract can verify.

The deposit contract does some verification on these parameters. In particular, the deposit amount is subject to checks, and the deposit data root is verified. If either of these fails then the deposit will be rejected - that is, the deposit transaction will be reverted.

However, the deposit contract does not validate the signature - the EVM does not yet have the elliptic curve apparatus to do this, and it would be prohibitively expensive to do in normal bytecode. The signature will be validated later by the consensus layer, and if found to be incorrect (for new validators) the deposit will fail, and the DCOIN will be lost.

Once the deposit contract is as satisfied as it can be that the deposit is valid, it issues [a receipt](https://eth2book.info/capella/part2/deposits-withdrawals/contract/#deposit-receipts) (an EVM log event) containing the deposit data. This receipt will later be picked up by the consensus layer for processing.

### Code Of Contract

```solidity
contract DepositContract is IDepositContract, ERC165 {
    uint constant DEPOSIT_CONTRACT_TREE_DEPTH = 32;
    // NOTE: this also ensures `deposit_count` will fit into 64-bits
    uint constant MAX_DEPOSIT_COUNT = 2**DEPOSIT_CONTRACT_TREE_DEPTH - 1;

    bytes32[DEPOSIT_CONTRACT_TREE_DEPTH] branch;
    uint256 deposit_count;

    bytes32[DEPOSIT_CONTRACT_TREE_DEPTH] zero_hashes;

    constructor() public {
        // Compute hashes in empty sparse Merkle tree
        for (uint height = 0; height < DEPOSIT_CONTRACT_TREE_DEPTH - 1; height++)
            zero_hashes[height + 1] = sha256(abi.encodePacked(zero_hashes[height], zero_hashes[height]));
    }
```

The `DEPOSIT_CONTRACT_TREE_DEPTH` specifies the number of levels in the internal Merkle tree. With a depth of 32, it can have $$2^{32}$$ leaves, allowing for up to 4.3 billion deposits (`MAX_DEPOSIT_COUNT`). A deposit is a minimum of DCOIN, so there's sufficient space for every DCOIN in existence to be deposited 35 times over.

The underlying data structure of the deposit contract is an incremental Merkle tree. This is a Merkle tree that supports only two operations, (1) appending a leaf, and (2) calculating the root. Constraining the data like this allows us to avoid storing the entire Merkle tree, which would be huge. Instead the contract stores only the last `branch` – a mere 32 nodes – which is all the information that's needed to calculate the Merkle root.

To gain this efficiency, we need an array of `zero_hashes`. At any given level of the tree, the zero hash is the value the node would have if all of the leaves under it were zero. Since we assign leaves sequentially, huge parts of the tree can be represented by the zero hashes.

The `constructor()` (which takes no arguments) only initialises the `zero_hashes` structure, taking advantage of the DVM's default that the uninitialised `zero_hashes[0]` storage value will be zero.

<figure><img src="/files/Yk77d2AKaiPgyPfIw1Zc" alt=""><figcaption></figcaption></figure>

```solidity
  function deposit(
        bytes calldata pubkey,
        bytes calldata withdrawal_credentials,
        bytes calldata signature,
        bytes32 deposit_data_root
    ) override external payable {
        // Extended ABI length checks since dynamic types are used.
        require(pubkey.length == 48, "DepositContract: invalid pubkey length");
        require(withdrawal_credentials.length == 32, "DepositContract: invalid withdrawal_credentials length");
        require(signature.length == 96, "DepositContract: invalid signature length");

        // Check deposit amount
        require(msg.value >= 1 dcoin, "DepositContract: deposit value too low");
        require(msg.value % 1 gwei == 0, "DepositContract: deposit value not multiple of gwei");
        uint deposit_amount = msg.value / 1 gwei;
        require(deposit_amount <= type(uint64).max, "DepositContract: deposit value too high");
```

This is the business part of the contract - where stakers' deposits are made.

A deposit comprises the following items.

* The public key of the validator: `pubkey` is the 48 byte (compressed) BLS public key derived from the staker's secret signing key.
* The withdrawal credentials: `withdrawal_credentials` is 32 bytes of either `0x00` BLS credentials or `0x01` credentials. Apart from their length, the withdrawal credentials are not validated anywhere in the contract, or even on the consensus layer.
* The `signature` is a 96 Byte BLS signature. It is generated by signing the hash tree root of a `DepositMessage` object (`public_key`, `withdrawal_credentials`, and `deposit_amount`), with the validator's signing key.
* The `deposit_data_root` is basically a form of checksum. See below for how it is verified.
* Finally, a `msg.value`. The message value is the amount of DaVinci (denominated in Wei, which are $$10^{-18}$$ DCOIN) that was sent with the transaction. This will normally be 32 DCOIN for a new validator, but can be more or less. It must be,
  * at least one DCOIN,
  * a whole number of DCOIN, and
  * less than $$2^{64}$$ Gwei $$^4$$ , which is 18.4 Billion DCOIN.

The very last condition is formally to avoid overflowing a consensus layer `uint64`, but seems kind of redundant in practice.

```solidity
// Emit `DepositEvent` log
        bytes memory amount = to_little_endian_64(uint64(deposit_amount));
        emit DepositEvent(
            pubkey,
            withdrawal_credentials,
            amount,
            signature,
            to_little_endian_64(uint64(deposit_count))
        );
```

### **Deposit Receipts**

For every deposit accepted by the deposit contract it issues a receipt (also called a log or event[6](https://eth2book.info/capella/part2/deposits-withdrawals/contract/#fn-6)), which is generated via an EVM `LOG1` opcode.

The receipt has a single topic, which is the `DepositEvent` signature: `0x649bbc62d0e31342afea4e5cd82d4049e7e1ee912fc0889aa790803be39038c5`, equal to `keccak256("DepositEvent(bytes,bytes,bytes,bytes,bytes)")`.

The receipt's data is the 576 byte ABI encoding of `pubkey`, `withdrawal_credentials`, `amount`, `signature`, and `deposit_count`, converted to little-endian where required.

The first column is the hexadecimal byte position of the start of the data in the second column.

<details>

<summary>Example Receipt Data</summary>

```none
# Pointer to pubkey: 0x0a0
000  00000000000000000000000000000000000000000000000000000000000000a0

# Pointer to withdrawal_credentials: 0x100
020  0000000000000000000000000000000000000000000000000000000000000100

# Pointer to amount: 0x140
040  0000000000000000000000000000000000000000000000000000000000000140

# Pointer to signature: 0x180
060  0000000000000000000000000000000000000000000000000000000000000180

# Pointer to deposit_count: 0x200
080  0000000000000000000000000000000000000000000000000000000000000200

# Length of pubkey: 48 bytes
0a0  0000000000000000000000000000000000000000000000000000000000000030

# Pubkey data, padded with 16 zero bytes
0c0  b73fe99acbf91f0032ae95c3ed0d663ea246d02332373e101ff5c7ed520ce098
0e0  652de3eab056a9889bb3d05d734be21400000000000000000000000000000000

# Length of withdrawal_credentials: 32 bytes
100  0000000000000000000000000000000000000000000000000000000000000020

# Withdrawal credentials (0x01 type)
120  010000000000000000000000e637a2acbc531531700fcb7d2ed7e6d96ed8bbe8

# Length of amount: 8 bytes
140  0000000000000000000000000000000000000000000000000000000000000008

# Amount, little-endian encoded. 0x0773594000 = 32,000,000,000
160  0040597307000000000000000000000000000000000000000000000000000000

# Length of signature: 96 bytes
180  0000000000000000000000000000000000000000000000000000000000000060

# Signature data
1a0  b4a7e1546b13be69d31849b4302d870a04867b9de73a973794f8be88c25dc71f
1c0  c3440141c33cf3fbf2dea328179c89550f4e19cad118dd962b07a7c40a3aa8ac
1e0  eaded660edb6e030df48074ddfbe70b26d0e9db1c3be28afc0b47096aab7a616

# Length of deposit_count: 8 bytes
200  0000000000000000000000000000000000000000000000000000000000000008

# Deposit count, little-endian. 0x0a7b1a = 686,874
220  1a7b0a00000000000000000000000000000000000000000000000000000000
```

</details>

A consensus client can request these receipts from its attached execution client via the standard [`eth_getLogs`](https://docs.infura.io/infura/networks/ethereum/json-rpc-methods/eth_getlogs) RPC method, filtering by the deposit contract address, block numbers, and event topic. This is how the consensus layer becomes aware of the details of new deposits.

The use of event logs here is an optimisation. The deposit contract could instead store all the Merkle tree's leaves and make them available via an `eth_call` method. However, since logs are not stored in the chain's state, only in block history, it is much cheaper to use them than it would be to store the leaves in the contract's state. However, this places a constraint on the amount of history we must keep around - we cannot now discard block history from before the deployment of the deposit contract. A newly activated consensus client needs access to the full receipt history in order to rebuild its internal view of the Merkle tree, even if it is able to checkpoint sync its beacon state. For convenience, some clients now support starting from a [deposit snapshot](https://github.com/ConsenSys/teku/pull/5954) of the Merkle tree that can be shared with other clients in much the same way as [checkpoint states](https://eth-clients.github.io/checkpoint-sync-endpoints/). This allows aggressive pruning of block history for those who want to do that.


# Technical Network

## Differences between Ethereum and DaVinci

DaVinci is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) and introduces as few changes as possible to the Ethereum protocol. However, there are some minor differences between the behavior of Ethereum and DaVinci that developers should be aware.


# Mainnet


# Accounts

## Accounts

An DaVinci account is an entity with an ether (DCOIN) balance that can send transactions on DaVinci. Accounts can be user-controlled or deployed as smart contracts.

### Account types <a href="#types-of-account" id="types-of-account"></a>

DaVinci has two account types:

* Externally-owned account (EOA) – controlled by anyone with the private keys
* Contract account – a smart contract deployed to the network, controlled by code.&#x20;

Both account types have the ability to:

* Receive, hold and send DCOIN and tokens
* Interact with deployed smart contracts


# Transaction

## Transactions

Transactions in DaVinci Chain are digital messages that enable users to transfer assets, interact with smart contracts, and execute various operations on the blockchain. These transactions are processed, validated, and recorded on-chain to maintain network integrity.

A submitted transaction includes the following information:

* `from` – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions
* `to` – the receiving address (if an externally-owned account, the transaction will transfer value. If a contract account, the transaction will execute the contract code)
* `signature` – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction
* `nonce` - a sequentially incrementing counter which indicates the transaction number from the account
* `value` – amount of DCOIN to transfer from sender to recipient (denominated in WEI, where 1 DCOIN equals 1e+18wei)
* `input data` – optional field to include arbitrary data
* `gasLimit` – the maximum amount of gas units that can be consumed by the transaction. The DVM specifies the units of gas required by each computational step
* `maxPriorityFeePerGas` - the maximum price of the consumed gas to be included as a tip to the validator
* `maxFeePerGas` - the maximum fee per unit of gas willing to be paid for the transaction (inclusive of `baseFeePerGas` and `maxPriorityFeePerGas`)

Gas is a reference to the computation required to process the transaction by a validator. Users have to pay a fee for this computation. The `gasLimit`, and `maxPriorityFeePerGas` determine the maximum transaction fee paid to the validator.&#x20;

**The transaction object will look a little like this:**

```json
{
  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  gasLimit: "21000",
  maxFeePerGas: "300",
  maxPriorityFeePerGas: "10",
  nonce: "0",
  value: "10000000000"
}
```

But a transaction object needs to be signed using the sender's private key. This proves that the transaction could only have come from the sender and was not sent fraudulently.

**JSON-RPC Example**

```json
{
  "id": 2,
  "jsonrpc": "2.0",
  "method": "account_signTransaction",
  "params": [
    {
      "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
      "gas": "0x55555",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "input": "0xabcd",
      "nonce": "0x0",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "value": "0x1234"
    }
  ]
}
```

**Example Response**

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
    "tx": {
      "nonce": "0x0",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "gas": "0x55555",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "value": "0x1234",
      "input": "0xabcd",
      "v": "0x26",
      "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
      "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
      "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
    }
  }
}
```

* the `raw` is the signed transaction in Recursive Length Prefix (RLP) encoded form
* the `tx` is the signed transaction in JSON form


# Onchain Gas Transaction

## Types of transactions <a href="#types-of-transactions" id="types-of-transactions"></a>

On DaVinci there are a few different types of transactions:

* Regular transactions: a transaction from one account to another.
* Contract deployment transactions: a transaction without a 'to' address, where the data field is used for the contract code.
* Execution of a contract: a transaction that interacts with a deployed smart contract. In this case, 'to' address is the smart contract address.

### On gas <a href="#on-gas" id="on-gas"></a>

As mentioned, transactions cost gas to execute. Simple transfer transactions require ***21000 units*** of Gas.

So for Bob to send Alice 1 DCOIN at a `baseFeePerGas` of 190 gwei and `maxPriorityFeePerGas` of 10 gwei, Bob will need to pay the following fee:

```mathematica
(190 + 10) * 21000 = 4,200,000 gwei
--or--
0.0042 DCOIN
```

* Bob's account will be debited **-1.0042 DCOIN** (1 DCOIN for Alice + 0.0042 DCOIN in gas fees)
* Alice's account will be credited **+1.0 DCOIN**
* The base fee will be burned **-0.00399 DCOIN**
* Validator keeps the tip **+0.000210 DCOIN**

<figure><img src="/files/KwI7cEDZ7fgs2uckm4sc" alt=""><figcaption><p>DaVinci Virtual Machine Ilustrated</p></figcaption></figure>

### Block size <a href="#block-size" id="block-size"></a>

Each block has a target size of 15 million gas, but the size of blocks will increase or decrease in accordance with network demand, up until the block limit of 30 million gas (2x the target block size). The protocol achieves an equilibrium block size of 15 million on average through the process of *tâtonnement*. This means if the block size is greater than the target block size, the protocol will increase the base fee for the following block. Similarly, the protocol will decrease the base fee if the block size is less than the target block size. The amount by which the base fee is adjusted is proportional to how far the current block size is from the target. More on blocks.

### Base fee <a href="#base-fee" id="base-fee"></a>

Every block has a base fee which acts as a reserve price. To be eligible for inclusion in a block the offered price per gas must at least equal the base fee. The base fee is calculated independently of the current block and is instead determined by the blocks before it - making transaction fees more predictable for users. When the block is created this **base fee is "burned"**, removing it from circulation.

The base fee is calculated by a formula that compares the size of the previous block (the amount of gas used for all the transactions) with the target size. The base fee will increase by a maximum of 12.5% per block if the target block size is exceeded. This exponential growth makes it economically non-viable for block size to remain high indefinitely.

### EIP-1559

The base fee on DaVinci is, like Ethereum, computed via the [EIP-1559](https://notes.ethereum.org/@vbuterin/eip-1559-faq) mechanism. The EIP-1559 parameters used by DaVinci differ from those used by Ethereum as follows.

<table><thead><tr><th width="251" align="center">Parameter</th><th align="center">DaVinci Value</th><th align="center">Ethereum Value </th></tr></thead><tbody><tr><td align="center">Block gas limit</td><td align="center">30,000,000 gas</td><td align="center">30,000,000 gas</td></tr><tr><td align="center">Block gas target</td><td align="center">5,000,000 gas</td><td align="center">15,000,000 gas</td></tr><tr><td align="center">EIP-1559 elasticity multiplier</td><td align="center">6</td><td align="center">2</td></tr><tr><td align="center">EIP-1559 denominator</td><td align="center">250</td><td align="center">8</td></tr><tr><td align="center">Maximum base fee increase (per block)</td><td align="center">2%</td><td align="center">12.5%</td></tr><tr><td align="center">Maximum base fee decrease (per block)</td><td align="center">0.4%</td><td align="center">12.5%</td></tr><tr><td align="center">Block time in seconds</td><td align="center">2</td><td align="center">12</td></tr></tbody></table>


# Developer Hub