stakefunction. They should do this from their KSA.
stakedAmountmap on the contract.
stakeAddressis the KSA that the Keeper used to stake the Rook and that they plan to have sign commitments.
stakeSpentis how much of the Rook that the Keeper has staked has been spent. This will increase when the Keeper makes bids and decrease when the Keeper is issued refunds.
stakeNonceis an increasing number used to prevent replays of previously used commitments.
channelNonceis an increasing number that is incremented every time a Keeper closes their payment channel.
datawill contain arbitrary information depending on the type of stake commitment.
coordinatorSignatureis an Ethereum signature from the Coordinator using the hash from the function
stakeCommitmentHashas the message.
paymentfield. The relevant fields are
stakeSpent. It is initialized to 0 and should be incremented relative to the latest value by an amount equal to the desired bid. So if the current value of
stakeSpentis 100, to create a payment that bids 50,
stakeSpentshould be set to 150.
stakeSpentcan only be set as high the amount of Rook the keeper has staked. The Coordinator will reject any bids that attempt to bid higher than the staked amount.
stakeNoncemust be incremented by 1 in each new commitment.
channelNonceshould always match the current on-chain value
previousCommitmentHashis used by the Coordinator as a validation mechanism. This is the
datafield in the commitment definition in the staking contract. When creating a new bid commitment,
previousCommitmentHashmust be set to the output of
stakeCommitmentHashon the preceding commitment. Important: If it is the first bid commitment and there is no preceding commitment,
previousCommitmentHashshould be set to
"0x0000000000000000000000000000000000000000"as in the example above.
stakeNoncefor their payment channel, and a
stakeAddressSignatureis an Ethereum signature on the message hash returned by the /refundRequestMessageHash endpoint. The coordinator will create a new commitment using the same rules the Keeper uses to create a bid commitment except that the value for
stakeSpentis determined by subtracting the total refundable ROOK from the current latest commitment's
stakeSpentwill be reduced. This means the Keeper must generate new bid commitments using the refund commitment as the latest commitment state. For example: say a keeper's
stakeSpentis 150 and they have accumulated a refund of 50. They request and are issued a refund. Their
stakeSpentis now reduced to 100. Now let's say another profit opportunity appears and they place another bid. The keeper must bid based on the most recent commitment, which is the refund commitment. So if the keeper wants to bid 25, they will bid with a stakeSpent of 125.
/keeperStakeChannelendpoint. The commitment may or may not have the KSA signature on it already depending on if it's a bid or a refund commitment. Since the Coordinator generates the refund commitment, it will not have the KSA signature on it. The Keeper should use
StakeCommitment. This will begin a 7 day timelock where the Coordinator can challenge the withdrawal by submitting a commitment with a higher stake nonce using the same function. Once the 7 day timelock has concluded, the Keeper can complete their withdrawal using
/instantWithdrawalRequestMessageHashendpoint, generating an Ethereum signature on it using their KSA, and then submitting it to the
/initiateInstantWithdrawalendpoint. Once the Coordinator sees this instant withdrawal request, it will no longer allow the KSA to bid on auctions and then it will wait some amount of time to allow all active auctions containing a bid from the KSA to conclude. After the auctions have concluded, it will issue any outstanding refunds and generate an instant withdrawal signature. The latest commitment and the instant withdrawal signature on it can be retrieved using the
/keeperStakeChannelendpoint. The Keeper should then generate their own instant withdrawal signature. They should generate an Ethereum signature on the output of
stakePaymentHashusing the latest commitment and the stake contract constant
INSTANT_WITHDRAWAL_COMMITMENT_DATAas the value for the
dataparameter. They can then complete the withdrawal using the
executeInstantWithdrawalfunction on the stake contract.
datashould be the stake contract constant