RFC 3, discusses the architectural tradeoffs to be considered for the stake delegation design. That document concludes with the preferred architectural approaches, and the remainder of this section describes a subset of these. The approaches in RFC 3 that are not detailed below are omitted in the interests of a simpler initial implementation, but may be layered on in later RFCs. For now, this document focuses on a system that uses multi operation with static minimum stake and delayed undelegation with consequent penalisation.
The goal of this proposal is to specify a simple and secure stake delegation mechanism. It should enable Keep users to have their wallets offline and their stake operated by operators on their behalf. The Keep client software should be able to run without exposing Keep operator’s private key and should not require any owner’s keys at all. The stake delegation should also optimize the network throughput without compromising the security of owners stake.
- owner
-
The address of an owner of the staked tokens.
- operator
-
The address of a party authorized to operate a stake on behalf of a given owner.
- beneficiary
-
The address where the rewards for participation are sent, earned by an operator, on behalf of an owner.
- delegated stake
-
An owner's staked tokens, delegated to the operator by the owner.
- on-stake
-
Refers to the type of operations performed by an operator on a delegated stake.
- operation
-
A set of interactions with the system with a defined start and finish, executed entirely by an operator, during which the operator does tasks on behalf of all or part of a delegated stake.
In this proposal, we are specifying three roles: owner, operator, and beneficiary. They are briefly characterized in this section.
The owner is the ultimate holder of the tokens. Before stake delegation, the owner has full control over the tokens, and the tokens are returned to the owner after stake delegation has finished. The owner’s participation is not required in the day-to-day operations on the stake, so cold storage can be accommodated to the maximum extent.
The owner can delegate its stake, undelegate its stake and restore the delegated tokens.
The operator handles the everyday operations on the delegated stake without actually owning the staked tokens. While this enables third-party delegation without, e.g., making it possible for the operator to simply transfer away tokens, it should be noted that a malicious operator can exploit stake slashing to destroy tokens and thus the entire staked amount is indeed at stake.
The operator address is used to provide network functionality by participating in various operations.
The operator can unilaterally finish delegation and restore the tokens to the owner.
The beneficiary collects rewards earned from stake delegation and participation in the network. The beneficiary doesn’t sign or publish any protocol-relevant transactions, but any currency or tokens earned by the operator will be transferred to the beneficiary.
Following is a high-level description of each of the features in that sentence:
- Multi Operation
-
A feature that enables a virtually unlimited number of operations on a delegated stake. It allows operators to operate on a delegated stake without any limits (except the minimum stake requirements).
- Static Minimum Stake
-
A feature that determines the value of the minimum stake will be constant through the network lifetime. It can only be changed during a hard-fork.
- Delayed Undelegation
-
A mechanism for revoking a delegation. Undelegation starts when an undelegation request is submitted, and lasts through the undelegation period. During this period, the operator has time to end all ongoing operations. During the undelegation period, the delegated stake is locked and no new operations are allowed. Already-started operations may be continued. After the undelegation period timeout, the delegated stake is released to the owner, and the bond between operator and owner is removed.
- Consequent Penalization
-
Is the way undelegation is penalized. When an undelegation happens during an operation and the operation terminates successfully, then there is no penalty. If the operation terminates unsuccessfully, then the penalties are imposed. This the same way as standard penalization happens for an inactive peer.
The contract should include the following information:
-
owner address,
-
operator address,
-
beneficiary address,
-
bond indicator between an operator and an owner,
-
amount of delegated tokens,
-
state of the agreement between an owner and an operator,
-
agreement state change time.
The contract should also have the following discrete pieces of functionality:
delegation, undelegation,
restoration, penalization,
and rewarding.
-
The owner chooses the number of tokens to delegate, operator, and beneficiary and creates a delegation order containing this information.
-
The contract receives the delegation order and verifies the following (if any condition is unfulfilled, processing aborts):
-
beneficiary address is set,
-
operator is not involved in another active delegating contract,
-
amount of delegated tokens is lower or equal to the owner staked tokens.
-
-
If all conditions are satisfied the contract processes the delegation order and sets the variables accordingly to the delegation order, and binds the owner with the operator. The state of agreement between the owner and the operator is set to
active, and the agreement state change time is set to current time.[1] -
The operator can now use this delegated stake for operating.
-
The owner or operator chooses to undelegate the stake, and creates an undelegation order.
-
The contract receives the undelegation order and verifies that the agreement exists.
-
If the conditions are satisfied, the contract processes the undelegation order and sets the following:
-
contract state is set to
undelegating, -
contract state change time is set to current time.
-
-
The operator cannot enter new operations until the undelegated stake is restored and the owner cannot delegate the delegated stake to a new operator.
-
After undelegating delay timeout since the undelegation order has been processed, the owner or operator creates a stake restoration order.
-
The contract receives the stake restoration order and verifies the following:
-
the agreement exists,
-
the contract state is set to undelegating,
-
undelegation timeout has passed.
-
-
The contract processes the stake restoration order and sets the following:
-
returns delegated stake to the owner (minus any undelegation penalties if applicable),
-
removes the bond between the operator and the owner.
-
-
The operator is now free to start operating for a new owner.
-
When the operator tries to join operation (e.g., present a ticket for beacon group selection) they should create an operation initialization order, signed by the operator.
-
The operation initialization order is published along with any other data required to join the operation, after which the following should be checked:
-
the agreement exists,
-
the state of the agreement is
active, -
the request is signed by the operator.
-
-
If the checks pass, the operator may join the operations.
If the operator is awarded a reward of currency, the reward should be paid to beneficiary address. In this document, we are not specifying how rewarding should be done.
-
If the operator is to be punished by stake slashing, the penalizing contract should call the delegation contract with the penalty. The penalty should contain the following:
-
the penalty amount,
-
the operator address.
-
-
The delegation contract should then check the penalty amount is not higher than the minimum stake.
-
If the penalty is valid, the delegation contract will subtract the penalty amount from the delegated stake. If the penalty amount is higher than the delegated stake then the delegated stake should be set to zero.