Staking and governance

Equity pledge and on-chain governance

APoS realizes decentralized community governance. You can see similar ideas from other networks, notably Cosmos and EOS. Its core logic can be summarized as follows.

  1. Token holders, including validators, can “lock” their tokens into staking. Token holders can delegate their tokens to any validator or a validator candidate. They can then reselect a different validator or candidate to delegate their tokens to.

  2. All validator candidates will be sorted by the number of delegated tokens they have received, and the top ones will become the real validators.

  3. The verifier and the delegator can release the pledge at any time through the verifier’s rights.

FSC equity pledge

Ideally, such staking and reward issuance logic should be included in the blockchain and executed automatically when new blocks are produced. This is how the Cosmos Hub, which uses the Tendermint consensus library like the FON smart chain, works.

FSC wants to be as compatible with Ethereum as possible, and implementing APoS directly on it is a huge challenge and pressure. This is especially true when you consider that Ethereum itself may be migrating to a PoS consensus protocol in short order (or longer). In order to maintain the compatibility of Ethereum, our staking logic in FSC is:

  1. The pledged currency is FON because it is the native currency on FSC.

  2. In FSC’s equity pledge and delegation behavior, the FSC validator set is determined by its equity pledge and delegation logic. The equity pledge module built on FSC rewards distribution on FSC occurs every 3 hours.

FON is the token for FSC equity pledge.

To maintain compatibility with the Ethereum consensus protocol, including upcoming upgrades, FSC has chosen independent staking management. In the FSC stake staking module. It will accept FSC stakes from FON holders and calculate the set of nodes with the largest stakes. Every 3 hours, the ranking of block producers is refreshed and FSC is notified to update its validator set.

Before generating a new block, existing FSC validators regularly check whether there is a "ValidatorSetUpdate" message forwarded to FSC. If so, they will update the validator set after a certain height (i.e. a predefined block interval). For example, if FSC generates a block every 5 seconds and the check period is 240 blocks, then the current validator set will check and update the validator set for the next period in 1200 seconds (20 minutes).


Validator set updates and reward distribution both occur every 3 hours. This can better make the FSC network validators healthier and also make the validators more active. Rewards will be issued directly to the validator address.

Last updated