OST' Composer contract

[deepesh-kn]

I am not sure if this ticket needs to be broken into the smaller ticket.

Composer contract: Please note: the contract is referred to Composer, but this is not final name. Suggest a better name.

• Composer contract will be Organized

• Single Composer contract must work for arbitrary gateway.

• Any address(user) must be able to request stake for OST on origin chain by calling requestStake function.

  function requestStake(
      address _gateway,
      uint256 _amount,
      address _beneficiary,
      uint256 _gasPrice,
      uint256 _gasLimit,
      uint256 _nonce
  )
      external
      returns (
          bytes32 stakeRequestHash_
      )

• Composer should have a function that returns the current nonce for the given address that can be used for stakeRequest

  function getNonce(
      address _account,
      address _gateway
  ) 
      external 
      view
      returns (uint256 nonce_)

• Facilitators (whitelisted, for now, later it can be open) can facilitate the stake and mint process on behalf of the user by providing the hash lock. A whitelisted address can call acceptStakeRequest to facilitate stake and mint.

  function acceptStakeRequest(
      bytes32 _stakeRequestHash,
      bytes32 _hashLock
  )
      onlyWorker // only whitelisted address can call this
      external
      returns (bytes32 messageHash_)

• The staker can revoke the stake request any time unless it has been accepted and processed by the facilitator. Staker can call revokeStakeRequest() function to revoke the stake request. Staker can revoke only its own stake requests.

  function revokeStakeRequest(
      bytes32 _stakeRequestHash
  )
      external 

• A facilitator can reject the stakeRequest by calling rejectStakeRequest. We should evaluate if this function is needed. If the facilitator pool will be open then we may not need this function.

  function rejectStakeRequest(
      bytes32 _stakeRequestHash
  )
      onlyWorker // only whitelisted address can call this
      external

• All events of the composer contracts must be sufficient for the facilitator to decide if they want to accept or ignore the facilitation.

  <To be added>

• Currently, there is a limitation of one stake request at a time in the Gateway contracts. This must be gracefully handled in the composer contract. One of the proposals is given below that uses proxy contract for staker.

• The organization can deactivate the new stake requests. By doing this no one can call stakeRequest. Facilitators can still accept stake requests. Staker can still revoke the stake requests.

[abhayks1]

Was going through the epic 📔 . Few comments:

• Since there will be external calls in multiple methods(Proxy, Gateway), we can evaluate if we should use mutex wherever necessary.

  Reference: https://github.com/OpenST/brandedtoken-contracts/blob/develop/contracts/GatewayComposer.sol#L193

• All events of the composer contracts must be sufficient for the facilitator to decide if they want to accept or ignore the facilitation.

Not all methods of Composer need events. In acceptStakeRequest Gateway.stake is called which already emits StakeIntentDeclared event. Facilitators can listen to this event and take appropriate actions. Similarly for revertStake.

[deepesh-kn]

Was going through the epic 📔 . Few comments:

• Since there will be external calls in multiple methods(Proxy, Gateway), we can evaluate if we should use mutex wherever necessary. Reference: https://github.com/OpenST/brandedtoken-contracts/blob/develop/contracts/GatewayComposer.sol#L193

👍 We can use mutex where ever it is necessary.

• All events of the composer contracts must be sufficient for the facilitator to decide if they want to accept or ignore the facilitation.

Not all methods of Composer need events. In acceptStakeRequest Gateway.stake is called which already emits StakeIntentDeclared event. Facilitators can listen to this event and take appropriate actions. Similarly for revertStake.

To be more specific, an event from requestStake should have all parameters so that facilitator can decide if it needs to acceptStakeRequest or ignores it. revokeStakeRequest and rejectStakeRequest should also have events. It will be fine for acceptStakeRequest to not have an event as StakeIntentDeclared will be emitted

[schemar]

@deepesh-kn should I add a mutex to the proxy's stake method?