# Bridge UI Admin View

This is a proposal on how to implement an admin view for the Bridge UI app. The link to this view will only be shown to users that can modify parameters in the bridge contracts.

## Parameters that can be updated

The methods that will be callable from this view are:

- **ERC20 to ERC20**
- Home
- `setDailyLimit`
- `setGasPrice`
- `setRequiredBlockConfirmations`
- `setMinPerTx`
- `setMaxPerTx`
- Foreign
- `setGasPrice`
- `setRequiredBlockConfirmations`
- **ERC20 to Native**
- Home
- `setDailyLimit`
- `setGasPrice`
- `setRequiredBlockConfirmations`
- `setMinPerTx`
- `setMaxPerTx`
- `setBlockRewardContract`
- Foreign
- `setGasPrice`
- `setRequiredBlockConfirmations`
- **Native to ERC20**
- Home
- `setDailyLimit`
- `setGasPrice`
- `setRequiredBlockConfirmations`
- `setMinPerTx`
- `setMaxPerTx`
- Foreign
- `setDailyLimit`
- `setGasPrice`
- `setRequiredBlockConfirmations`
- `setMinPerTx`
- `setMaxPerTx`
- **Bridge Validators**
- `addValidator`
- `removeValidator`
- `setRequiredSignature`
- `transferOwnership`

## Detecting if the user is allowed

The mentioned methods can only be called by the owner of the validators contract. So, the easiest way to detect if the view should be available is to get the validator contract (using the `validatorContract` method in the `BasicBridge` contract), calling the `owner` function and comparing this address to the address of the current user.

Note that if the owner of the contract is a multisig wallet, then the view will not be available to anyone. A possible future improvement is to allow this, but in this case calling the setter functions **will not** call the functions directly; instead, it should submit this call to the multisig contract. This raises the question of what to show to subsequent members of the multisig wallet: if they want to approve this update, they should approve that submission instead of creating a new one.

## Upgrading the contract

There are two alternatives here. In both cases, the user can only do this if their address is the same as the one returned by the `proxyOwner` method.

- Deploy the new contract manually and call the `upgradeTo` function of the `OwnedUpgradeabilityProxy` contract (instantiated with the same address than the bridge). This function should be called with the new version and the new address of the contract. This new version could be inferred from the current one (current + 1), or the current version could be shown to the user to let them decide the new one.
- Allow the user to input the bytecode of the new contract. Then deploy this contract and use its address in a call to `upgradeTo`. Again, the new version number can be inferred or decided by the user.

While the first option only needs one transaction, it also implies a non-trivial change in the deploy script. With that in mind, the second option is actually easier: the user should compile the contracts manually (just `truffle compile`), use the bytecode in the truffle artifact as input and then approve the two transactions (the deploy and the upgrade).

## Support for multisig wallet

It's likely that the owner of the validator contract is not a single account, but a multisig wallet owned by several people. In this case, the transactions to the bridge can't be sent directly; instead, the transactions must be submitted to the multisig wallet for the rest of the owners to approve.

_Note: We'll suppose that the multisig wallet being used is the [Gnosis MultiSigWallet](https://github.com/gnosis/MultiSigWallet), or at least that it has the same interface._

First we must detect if the owner is an account or a multisig wallet. This is simple: we just see if the address has associated code (i.e.: if it's a contract).

Then we need to know if the connected user is part of the multisig wallet. This can be done with the `isOwner` method.

To update values, we'll have some modified components that, instead of sending a transaction to update a value, will create a transaction in the multisig wallet. To allow other owners to approve this transaction, the components will also show the transactions pending for approval, along with how many approvals they already have.

For example, the component for the daily limit will show the current limit and will have an input for changing it. After typing a new value and sending it, a transaction will be submitted to the multisig and this proposed transaction will be shown below the input. There may be more than one proposed update: the component will list all of them. Then, each validator will see a button next to each proposed transaction to approve it (if they haven't done it yet) or to reject it (if they had approved it before). When enough approvals are sent, the multisig will send the transaction. After this happens, the component will no longer show this transaction.

To implement this we can use the `getTransactionIds` method of the multisig wallet, and then filter the transactions that have the bridge address as destination and whose data starts with the four bytes that correspond to the method associated with the component.

A final requirement is to show the date in which the transaction was submitted. While the multisig wallet doesn't have that information, it can be obtained this way:

- First, get the Submission event for that transaction id (the event is indexed so it should be fast).
- Use the event to get the transaction.
- Use the transaction to get the block.
- Use the block to get the timestamp.