Staking to Endorse Data

Endorsement is a two-step process that begins with staking. Once collateral is staked the staked user is eligible to endorse data, provided the dataset is open (not in the pre-data staking period immediately before the dataset opens). Staking reserves a spot for a limited amount of time, so there’s no need for the staked user to worry about someone else taking their spot before they’ve had the opportunity to endorse data.

It is not, strictly-speaking, necessary to have a two-step process for endorsing the data because the staking and endorsement transactions could be wrapped in a single transaction. The reason for not using this simpler model was that there are two downsides. The first downside is this complicates the system a bit, either requiring wiring the functionality through other contracts, adding an additional inter-contract dependency (which makes changing this harder and often requires the use of additional storage), or introducing a new contract to bridge the dependency gap. In any case, it was a little more costly to deploy and run than the two-stage process. The other problem, which was of more concern, was that there are more chances for people to make mistakes when racing to enter the data. The endorsement model helps greatly with this problem, but for the user providing the actual data, racing against all other users in the system is more likely to lead to mistakes and slashes. By reserving a spot, there is less pressure to submit as soon as possible, pressure which could cause people to potentially skip double and triple-checking their data is correct, which is what increases the likelihood of being slashed.