# Multisig Tinlake Proxy
:::info
This document is publicly shared.
:::

## Goal
We want to reduce the risk that an asset originator can mistakenly loose fund by sending them to the wrong address or losing access to their wallet. The risk speifically is in how they withdraw funds from the proxy (currently it's just sent to the owner) and then how they convert DAI to USDC and USDC to fiat and vice versa.

## Proxy Architecture & Changes

Tinlake Proxy allows us to trigger different batch transactions that interact with the tinlake contract and is currently owned by a single address (most often a ledger hardware wallet).

This means that this single hardware wallet has control over all of the funds that are in the pool by triggering transactions that the proxy executes. Requiring every proxy transaction to be executed by a multisig is a gas cost and operational complexity that is not bearable by our users.

Most transaction in Tinlake however don't need to allow arbitrary execution of functions that could lead to loss of funds and in fact never require withdrawal of the funds from the proxy. There is a very simple solution that we can use to significantly increase the security of the contract by simply creating a two-tiered access control: users who can interact with a limited set of approved transactions and admins who can execute arbitrary code.

The `execute` function of the proxy as it stands today is implemented in [tinlake-proxy](https://github.com/centrifuge/tinlake-proxy/blob/master/src/proxy.sol#L46).

It relies on a library-like contract to be deployed at `_target` that has the methods that the proxy executes defined. These are in [tinlake-actions](https://github.com/centrifuge/tinlake-actions/blob/master/src/actions.sol#L97).

We can extend the proxy functionality to:
* allow the `admin` to call any `_target` and execute arbitrary function
* allow the `admin` to maintain a list of `safe actions` and users who can trigger actions
* allow users to submit any action considered safe.

### Pseudo Code Implementation

contract Proxy extends TinlakeProxy{
    mapping (address => uint256) public users;
    mapping (address => uint256) public targets;
    mapping (uint256 => uint256) public data;
    
    
    event Rely(address indexed usr);
    event Deny(address indexed usr);

    function rely(address usr) external owner(accessToken) {
        users[usr] = 1;
        emit Rely(usr);
    }
    function deny(address usr) external owner(accessToken) {
        users[usr] = 0;
        emit Deny(usr);
    }
    modifier user {
        require(users[msg.sender] == 1, "not-authorized");
        _;
    }

    function file(bytes32 key, bytes32 data) owner(accessToken) {
        data[key] = data;
    }

    function safe(address target) external owner(accessToken) {
        targets[target] = 1;
        emit Safe(target);
    }

    function unsafe(address target) external owner(accessToken) {
        targets[target] = 0;
        emit Unsafe(target);
    }

    function userExecute(address _target, bytes memory _data)
    public
    payable
    user
    returns (bytes memory response)
    {
        require(_target != address(0), "tinlake/proxy-target-address-required");
        require(targets[_target] == 1, "tinlake/proxy-target-not-safe");
        execute(...); // matches current proxy implementation
     }
}

## Miscallenous Changes
### Off chain events & proxy discovery
How we currently look for proxies in the subgraph via the proxy registry is known to be slow and should be changed to look at NFT minting events instead.

## Controlled fiat off ramp
### Tinlake to "wallet"
When users borrow DAI we can ensure that they can never withdraw from the proxy. This means that funds can only go to controlled offramps.

### DAI->USDC
Most users offramp DAI to fiat using Circle and thus need to first turn their DAI into USDC. There are two options to do this:
1) OTC Desks: as long as an OTC desk has a standard address they use we could allow users to withdraw funds to this address at any point knowing that the OTC desk would always require the funds to be returned to the same address.
2) Curve: we could create a target contract that can trade usdc with curve.

### USDC->Circle/Fiat
Circle gives us a fixed address we can send USDC to. This allows us to similarly only approve USDC ERC20 transfers to this address to ensure that the crypto will never end up in a wallet the AO doesn't control or deems safe.

### Library Contract Example

contract NewSilverActions is  {
    address circleWallet = 0x0000....;
    address otcWallet = 0x1111....;
    TokenLike usdc = TokenLike(0xaaaa...);
    TokenLike dai = TokenLike(0xbbbb...);
    
    function transferToCircle (uint wad) public {
        usdc.transferFrom(address(this), circleWallet, wad);
    }
    
    function transferToOtc (address token, uint wad) public {
        TokenLike(token).transferFrom(address(this), otcWallet, wad)
    }
}