Staking and Delegation via Smart Contract

Currently most of the platform support staking by the individual accounts. As far as I know none of the current platforms support staking from a smart contract.

On the other hand, there is interest in delegating of the stake to existing node operators / validators. Again, this feature implemented either on the protocol layer or is not provided at all. Because desire to delegate is still there, platforms that don’t support it just push this outside of the blockchain to less secure methods.

At the same time, delegation of the stake is a complicated question. On one side, the validator that got delegated stake confirming with their authority / reputation that they will follow protocol and not abuse this stake which may result in it’s slashing. Which can be considered an economic reason as future reward stream from running validator service, but doesn’t provide very high game theoretic incentives there.

On the other side, there a lot of different forms how delegation can be done. Including can the delegated stake be sold? Can we sell the future reward stream from the delegated stake? There is an interesting taxation questions and forms that this can take. Additionally, all of that stake is a capital sitting there that is non operational.

At NEAR we have an extremely flexible account model, where every account is a smart contract. Each account can have various keys that provide different way of operating this account.

Specifically, one create an account / contract that only has a staking key without any fund withdrawal keys. Code deployed to this contract can accept funds into this contract and employ these funds for the staking.

Now, this is just a basic delegation contract now, where validator when creating this contract can decide on rules how to split reward: reinvest? send back to delegators? employ to buy other tokens via Uniswap to hold (for example buy automatically buy DAI as rewards come in).

I can imagine a multitude of various delegation contracts:

  • Allow float of tokens in the contracts to improve liquidity of staking. For example keep 10% unstaked in the contract, such that if some people need to undelegate on the short notice, they don’t need to wait for the unbonding period.
  • Issue a “delegation” token when one deposits into the contract. This delegation token now can be passed / sold between accounts. This allows to make delegated stake liquid.
  • Control how the proceeds from the staking are split. Fee to the validator, immediate pay out to the delegates or reinvesting back into the staking.
  • Split control over where reward is going from the owner of the delegated stake.
  • Use stake that is locked in the contract to issue loans. For example as CDP contract, where stake is used as collateral for issued loan and can automatically maintain various operations to maintain the collateralization as price changes.

Additional possibility is to organize a set of sub-contracts which are controlled by one staking “pool” contract. Each of these sub-contracts can be run by a separate validator and the master contracts can define amounts of the stake allocated to them and define how reward is split.

The point here is that NEAR protocol itself doesn’t define how the delegation will happened, instead allow for validators and stakeholders to decide how they want to engage with their capital.

1 Like

I agree that we’ll probably see markets develop around staked tokens, eg. using them as collateral. I wonder what the security discount will be (since this is effectively an asset with a lein against it by the staker where there is a nonzero chance that the asset gets slashed and loses all value).

Selling a future reward stream from stake as a derivative smells a lot like structured finance in the bond markets, eg. when they started securitized the interest and principal components of mortgages separately and sold them off during the late 80’s. It worked out pretty well as an idea (I’ll save commentary about the effects on the economy).

About keys – how do we (or how can we) not allow for overlapping key permissions? For example, what says I can’t create two staking keys? Or, for something less fundamental, create two leins against the same token?

So for all the new capabilities that contract accounts create, they still also create problems of a new sort. And I do think they’re solveable – for instance the keys can be set up so it’s very clear there’s a hierarchy of who has the “title” to the underlying tokens first, who has it second, etc. if something happens where they get slashed or taken. But it’d have to be standardized and inspectable easily to create any sort of fungibility in lending markets (otherwise someone accepting a key that appears to give them staking access needs to verify that no other keys have been or can be created which take this stake).

All the delegation contracts mentioned above represent workarounds to pretty much any system that creates nonlinear staking curves. For example, giving longer-duration staking a bigger “vote” or participation can be circumvented with the liquidity-providing contract you mention.

While this is really desirable, this would push a lot of work to delegators, delegators would have to verify the rules of the contract they are getting into, make sure they are dealing with audited contracts. While this allows for a lot of flexibility it becomes harder for delegators to delegate. However, I can see a future where we can have a set of audited and widely used delegation contracts and delegation contract standards.

Agreeing with @vaibhavchellani here, due to the same reason we’ve implemented delegation in protocol while also keeping the option of smart Contract based delegation as well(any validator can have their own smart contract and rules for delegation and start accepting delegation).