stake
function. They should do this from their KSA. stakedAmount
map on the contract.stakeAddress
is the KSA that the Keeper used to stake the Rook and that they plan to have sign commitments.stakeSpent
is 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.stakeNonce
is an increasing number used to prevent replays of previously used commitments.channelNonce
is an increasing number that is incremented every time a Keeper closes their payment channel.data
will contain arbitrary information depending on the type of stake commitment.stakeAddressSignature
is an Ethereum signature from the KSA using the hash from the function stakeCommitmentHash
as the message.coordinatorSignature
is an Ethereum signature from the Coordinator using the hash from the function stakeCommitmentHash
as the message.payment
field. The relevant fields are stakeAddress
, stakeSpent
, stakeNonce
, channelNonce
, previousCommitmentHash
, and stakeAddressSignature
.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 stakeSpent
is 100, to create a payment that bids 50, stakeSpent
should be set to 150. stakeSpent
can 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. stakeNonce
must be incremented by 1 in each new commitment.channelNonce
should always match the current on-chain valuepreviousCommitmentHash
is used by the Coordinator as a validation mechanism. This is the data
field in the commitment definition in the staking contract. When creating a new bid commitment, previousCommitmentHash
must be set to the output of stakeCommitmentHash
on the preceding commitment. Important: If it is the first bid commitment and there is no preceding commitment, previousCommitmentHash
should be set to "0x0000000000000000000000000000000000000000"
as in the example above.stakeAddressSignature
should be an Ethereum signature from the KSA over the output of stakeCommitmentHash
on the new commitment./keeperStakeChannel
endpoint./keeperStakeChannel
endpoint.stakeAddress
, channelNonce
, and stakeNonce
for their payment channel, and a stakeAddressSignature
. The stakeAddressSignature
is 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 stakeSpent
is determined by subtracting the total refundable ROOK from the current latest commitment's stakeSpent
. stakeSpent
will 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 stakeSpent
is 150 and they have accumulated a refund of 50. They request and are issued a refund. Their stakeSpent
is 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. initiateTimelockedWithdrawal
function./keeperStakeChannel
endpoint. 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 previousCommitmentHash
for the data
field in 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 executeTimelockedWithdrawal
./instantWithdrawalRequestMessageHash
endpoint, generating an Ethereum signature on it using their KSA, and then submitting it to the /initiateInstantWithdrawal
endpoint. 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 /keeperStakeChannel
endpoint. The Keeper should then generate their own instant withdrawal signature. They should generate an Ethereum signature on the output of stakePaymentHash
using the latest commitment and the stake contract constant INSTANT_WITHDRAWAL_COMMITMENT_DATA
as the value for the data
parameter. They can then complete the withdrawal using the executeInstantWithdrawal
function on the stake contract.data
should be the stake contract constant INSTANT_WITHDRAWAL_COMMITMENT_DATA
./keeperStakeChannel
endpoint.