add option 2

docs/architecture/adr-009.md

@@ -29,33 +29,59 @@ An address in Cronos that carry no permissions.
 
 ## Decision
 
-For the above problem, we propose the following:
+### Option 1 : Create a permission system within cronos module for messages.
 
-- Keep the admin address in Cronos space. The admin has all the permissions and has the ability to change the permission of an address. 
+For the above problem, we propose the following:
 
+- Keep the admin address in Cronos space. The admin has all the permissions and has the ability to change the permission of an address.
 - By default, all addresses in Cronos are non-permissioned
-
 - Assign to each "restricted" messages in Cronos a permission (integer value) and create in Cronos module a mapping between addresses and permissions that is stored in memory. For now, there are only two messages that require permission : MsgUpdateTokenMapping and MsgTurnBridge.
-
 - Create a msg type "MsgUpdatePermissions" that only admin can use and allow to update the address permission mapping.
-
 - Change the logic to always check for the permission before processing the restricted messages.
 
-## Status
+### Consequences
 
-Proposed
+#### Positive
 
-## Consequences
+- Simple implementation self-contained in x/cronos module. Ability to be customized in the future if required.
+- It is still decentralized as the admin address is managed through governance. 
 
-### Positive
 
-- The admin address can share its power to other addresses. It becomes less vulnerable to exposure. 
-- Permissioned addresses can only carry few responsibilities. The damage is limited in case they are stolen. Could be used in a hot-wallet.
-- It is still decentralized as the admin address is managed through governance. 
+#### Negative
+
+- Require some change in the code.
+- Not flexible for potential future change which may require functionalities on the group module.
+
+
+### Option 2 : Use a subset of x/group module functionality to restrict some transactions in cronos
 
-### Negative
+For the above problem, we propose the following:
+
+- For each specific msg, we define a group and for the group, a group policy
+- Use the admin define in cronos space as general admin for the group
+- Set the policy of the group to ``threshold: "1"`` , ``min_execution_period: 0s`` and ``voting_period: 86400s``
+- The policy is associated to a group policy address, each permissioned msg within the proposal needs to be signed by the group policy address (TBD)
+- To be abe to execute a permissioned msg, one member of the group needs to send the msg ``Msg/SubmitProposal``
+
+In Cronos module, we need to restrict ``MsgUpdateTokenMapping`` and ``MsgTurnBridge`` msg to only specific "group policy address".
+
+- Store in the state a mapping between msg and group policy address that are allowed to trigger the msg
+- Only a governance proposal to be able to change the mapping
+
+#### Positive
+
+- Reuse of x/group module which is more flexible.
 
-- Require some change in the code
+#### Negative
+
+- Require some change in the code.
+- A bit overkill if we don't see the flexibility provided by the x/group module required in long term.
+- Admin of the group cannot be changed through governance.
+
+
+## Status
+
+Proposed
 
 ## References