Depositor Journey

Prerequisites:

Before depositing into the dedicated smart contract, make sure to review the Access Controlsdocumentation. Access Controls prevent unauthorized parties from operating and transacting with your dedicated smart contract.

1. Depositing into the Smart Contract

To get started, the wallet with the depositor role, should deposit 32 Ether into the dedicated smart contract. The smart contract will automatically emit a deposit event and create an Ethereum validator on the Beacon Chain.

📘

It is possible to deposit ETH in multiple batches to create multiple validators. The depositor could also deposit 2 x 16 ETH & generate 1 validator

Once the validator(s) become active, depositors consensus, execution and MEV rewards are collected within the contract and made available to depositors.

2. Claiming validator rewards

Before claiming any staking rewards, users must set the reward recipient wallet where rewards will be transferred to once claimed. The reward recipient address can be set directly in the smart contract by either the Default Admin or a Depositor via the function ()setRewardRecipient. To learn more about roles, check out: Access Controls

Once reward recipient address has been established. The owner of the address can claim rewards via the function ()collectRewards

📘

Anyone can call the function, but the rewards will always be transferred to the reward recipient address

3. Creating an RFQ

Users can submit a Request-For-Quote (RFQ) for a set of validators. Validators are sold in full and quotes in response to RFQ are All-or-None (AoN). When selling a large number of validators, we recommend submitting multiple quotes if possible. In addition, Northstake provides estimates of the next full withdrawal for each validator and we recommend to sell those validators whose next full withdrawal is closest to the time the RFQ is submitted. See [Submitting an RFQ to Validator Marketplace]

📘

Before initiating validator sales, make sure to have subscribed to all the necessary webhooks

The first step to submit an RFQ is to list the current validators owned by the depositor (or seller). The list of validators will provide you with the following info for each validator:

• Validator index: The index of the validator
• Balance: Total balance on Beacon Chain
• Estimated exit time: The estimated time for the validator to exit the Beacon Chain in case of a withdrawal

Using the information above, depositors / sellers can request a quote for a single or multiple validators up. When creating an RFQusers need to specify the validator/s they wish to sell by providing the validator index/indices.

In addition, the seller needs to supply the Ethereum wallet address where they wish to receive the liquid ETH if a quote is accepted and a sale is settled.

📘

It is possible to create multiple RFQs. However, it is not possible to include the same validator in multiple concurrent (active) RFQs

4. Accepting or rejecting quotes

Once the RFQ is created, liquidity providers submit bids in response to the RFQ. Bids are denominated in ETH.

Depositors / sellers can see active bids via a the webhook "RFQBidReceived". The webhook shows the following information for each bid:

• RFQ ID:: ID of the RFQ
• Quote_ID: ID of the Quote
• Amount: Amount offered, denominated in ETH
• Timestamp of quote:

If a quote meets the requirements of the depositor, they can choose to "Accept the Quote. At any time, only the best (i.e. highest) quote is presented for each active RFQ. When accepting a quote, sellers automatically accept the highest quote.

Once a quote has been accepted, buyers and seller the trade (notice that accepting a quote in response to an RFQ is legally binding).

Buyers settle first and sellers await for the liquidity providerto provide the agreed upon amount of ETH into the escrow wallet. Once the escrow wallet is funded with the ETH amount submitted in the quote, the webhook RFQEscrowEvent is triggered. The webhook shows the following:

• RFQ ID: ID of the RFQ
• Timestamp: Time of transaction
• Transaction hash: transaction hash of the ETH transferred by the LP
• Amount: Amount transferred, denominated in ETH

5. Accept proposal, show exiting validator

Once the escrow is funded, an Exit Proposal transaction is created and signed by the Operator for the acceptance of the depositor. Seller receives a message via the webhook called: RFQTransferProposalReceived which contains the following:

• Timestamp: Time of transaction
• Transaction hash: hash of the exit proposal
• Proposal id: unique identifier of the proposal.

To accept the exit proposal, depositors call the smart contract method ()acceptExit and enter the proposal id received from the webhook.

📘

Each proposal has a deadline of 20 minutes, beyond which it cannot be accepted. Depositors must accept exit proposals within the 20-minute deadline.

Once the exit proposal is accepted by the depositor, the funds in the escrow wallet will be transferred to the wallet chosen by the depositor/seller when the RFQ was initially created. The depositor will also be notified of escrow releases via the webhook RFQEscrowReleased which contains the following:

• Timestamp Time of transaction
• Transaction hash: hash of the escrow wallet transfer to the depositor wallet
• Amount: ETH amount
• Gas cost: Gas cost of performing transaction.