Zedxion Smart Chain(Zed20) Documentation
Choose Language
Zedxion Smart Chain(Zed20) Documentation
  • Summary
  • DOCUMENTATION
    • Learn about the ZEDXION Platform
      • ZEDXION Overview: vision, strategy and platform components
      • The ZEDXION Blockchain
        • Discovering the Network
        • ZEDXION Consensus
        • Delegation through Staking with Validators
        • Ethereum (EVM) Compatibility and Smart Contracts
        • Boosting ZEDXION’s Scalability
      • ZEDX Сoin
        • ZEDX Coin Economics
        • ZEDX Coin Wrappers
        • ZEDX on Other Chains
      • Interoperability
      • ZEDXION Governance and Development
        • ZEDXION Assembly
      • Wallets supporting ZEDXION
    • ZEDXION for Business
    • Things you can do on ZEDXION
      • Interacting with the ZEDXION Blockchain
      • ZEDXION Ecosystem
      • Community
      • Grants and Bounties
    • ZEDXION Mobile Infrastructure Use Cases
  • Developers
    • Network Details
      • ZEDXION Mainnet
      • ZEDXION Testnet
      • ZEDXION Faucet
      • Network Upgrades
        • Upgrade Guide
        • Upgrade Guide (explorer nodes)
        • Block 13,800,000 Fork
        • FIP's
    • Consensus
      • Stake, Delegate and Withdraw
      • Vote
      • End-of-Cycle Flow
      • Contract Addresses
    • Resources & Tools
      • TheGraph
      • WalletConnect on Zedx
    • Important smart contracts
      • Zedx Token
      • Zedx Dollar
      • Major Deployed Contracts
      • Bridges
        • Ethereum ↔ Zedx GoodDollar Token
        • Ethereum ↔ Zedx ZED20 Tokens
        • BSC ↔ Zedx BNB
        • BSC ↔ Zedx Native
        • BSC ↔ Zedx ZED20
        • Ethereum ↔ Zedx Native
    • How to become a validator
      • Getting started as a validator
    • Zeddex Contracts v2-v3 Zedx
    • Zeddex Contract v2-v3 BSC
    • API of ZedDex
  • Links
    • Discord
    • Facebook
    • GitHub
    • LinkedIn
    • Medium
    • Telegram
    • Twitter
    • YouTube
    • instagram
    • Slack
    • Zedxion Coin
    • Zedxion Exchange
    • Zedcex Exchange
Powered by GitBook
On this page
  1. Developers
  2. Consensus

End-of-Cycle Flow

This is a description of the End-of-Cycle flow that completes the Cycle and handles rewards and enforces the consensus

  1. BlockReward.reward is called every block and when the cycle ends calls the Consensus.cycle

  2. Consensus.cycle is responsible for several functions. Eventually does the following two actions:

    1. Sets the boolean Consensus.ShouldEmitInitiateChange to true

    2. Calls BlockReward.onCycleEnd which sets the boolean BlockReward.shouldEmitRewardedOnCycle to true as well

  3. The zedx-validator-app (zedxapp container on validator vms) checks the value of the above two booleans and when true calls the following two functions (two separate transactions):

    1. Consensus.emitInitiateChange

    2. BlockReward.emitRewardedOnCycle

Note that only one validator can make this call successfully so the 1st one succeeds and all others fail. But it’s ok because those are 0-gas transactions. So actually the validator who is the next one to validate a block is the one who is successful in making those calls.

  1. The above calls emit the following events:

    1. Consensus.InitiateChange

    2. BlockReward.RewardedOnCycle

  2. The bridge oracles zedxoracle-initiate-change and zedxoracle-rewarded-on-cycle are responsible for listening to above events.

  3. Those oracles should run on all validators and call submitSignature on the HomeBridgeNativeToErc contract in ZEDXION network - each validator should submit the signature for each of the oracles (events).

  4. Once enough validators have submitted their signatures (majority of the current validators), an event CollectedSignatures is emitted by the home bridge (again one event for each one of the previous events in section 4).

  5. The bridge oracle zedxoracle-collected-sigantures is responsible for listening to the CollectedSignature events and all validators should get it. The validator responsible for transmitting the transaction to mainnet is actually the last one to submit the signature in section 7 and its address is part of the event details so other validator oracles “know” it’s not their turn and skip the event. If a validator is down or out of money or infura is deaf - the next one in line (in the ValidatorSet) is responsible for transmitting to mainnet.

  6. Eventually on mainnet we are supposed to see two transactions to the ForeignBridgeNativeToErc each cycle - one updating the new validators and one minting the ZEDX tokens which were created during this cycle on ZEDXION.

Note that if the new validator set transactions fail on mainnet there’s a chance the minting will fails as well, because before transmitting it checks if all signatures are valid and there can be a situation where new validators were added on a cycle and were fast enough to submit their signatures on zedx end-of-cycle transactions but weren’t updated on mainnet due to failure of the 1st transactions so the 2nd one will actually contain “invalid” signatures from the mainnet perspective.

Example for a successful flow (from 7/6/2020)

PreviousVoteNextContract Addresses

Last updated 6 months ago

Consensus.emitInitiateChange transaction on ZEDXION -

BlockReward.emitRewardedOnCycle transaction on ZEDXION -

https://zedscan.net/tx/0x441e2cb5f4aa20948c51020ebd8f7fba7c33cf909e31c66d0aff4a11e79ce13d
https://zedscan.net/tx/0x34cf4ddfc8afa6154e8c0d5f1de3b7d756b1b0517e8f0efd5794bde40983ba64