deployments & proxy & ui - change suggestions (centrifuge#159)

* chore: add suggestions for ui & contracts
* fix: safe last changes

docs/tinlake/contracts/deployments.md

@@ -4,7 +4,7 @@ order: 2
 title: Deployments
 category: 2. Contracts
 ---
-The Tinlake contracts are intended to be deployed once for every asset class. There are is no shared code between any deployments to allow for a maximum of flexibility. We intend for users to customize and modify the codebase to better suit their needs. The codebase is clearly split into components that could and should be adjusted and core contracts. The core contracts enforce fairly basic rules (such as making sure a borrower can only unlock their NFT if they repaid their entire debt) while allowing other behaviors to be configured (such as how much interest the borrwer needs to pay).
+The Tinlake contracts are intended to be deployed once for every asset class. There is no shared code between any deployments to allow for a maximum of flexibility. We intend for users to customize and modify the codebase to better suit their needs. The codebase is clearly split into components that could and should be adjusted and core contracts. The core contracts enforce fairly basic rules (such as making sure a borrower can only unlock their NFT if they repaid their entire debt) while allowing other behaviors to be configured (such as how much interest the borrwer needs to pay).
 
 The architecture for the contracts is built to make sure that the contracts intended to be customized have extremely simple interfaces and are purely limited to that functionality. By making these contracts small and simple, the amount of code that needs to be modified is minimized and thus the risk of bugs being introduced through that code is too.
 
@@ -18,7 +18,7 @@ The downside of deploying an entire set of new contracts every time is that the
 There are three components used in the deploy process.
 
 ### Fabs
-To deploy each contract, a contract factory, called `fab`, is created first. The fabs are created beceause uploading the complete byte code for all contracts in one transaction exceeds the gas limit. Fabs can be deployed in separate transactions to allow for smaller transactions.
+To deploy each contract, a contract factory, called `fab`, is created first. The fabs are created because uploading the complete byte code for all contracts in one transaction exceeds the gas limit. Fabs can be deployed in separate transactions to allow for smaller transactions.
 
 A fab typically adheres to the following pattern:
 
@@ -85,7 +85,7 @@ contract Deployer {
 
 
 ### TinlakeRoot Contract
-The `TinlakeRoot` takes both the lender and borrower deployer as arguments. It does the last step of connecting lender and borrower contracts and authorizing certain calls. It also has
+The `TinlakeRoot` takes both the lender and borrower deployer as arguments. It does the last step of connecting lender and borrower contracts and authorizing certain calls.
 
 
 ```

docs/tinlake/contracts/proxyactions.md

@@ -15,7 +15,7 @@ The proxy contract enforces access control through the same way that the core co
 
 
 ## Proxy Registry
-To interact with Tinlake through a proxy, the user first needs to deploy a proxy by calling the ProxyRegistry.build() method. This method mints an NFT that into the sender's wallet that is then used to verify access to the contract.
+To interact with Tinlake through a proxy, the user first needs to deploy a proxy by calling the ProxyRegistry.build() method. This method mints an NFT into the sender's wallet that is then used to verify access to the contract.
 
 The `ProxyRegistry` implements an ERC721 NFT interface. To transfer ownership over a proxy contract you can use a standard NFT token transfer (`transferFrom(from, to, tokenId)`).
 
@@ -28,7 +28,8 @@ Returns the proxy contract address for a given `id`. The `id` is the id of the t
 ### `ownerOf(uint id) public returns (address)`
 Returns the owner of the corresponding NFT.
 
-The contract also implements all other ERC721 standard methods as defined in [...] TODO: link
+The contract also implements all other ERC721 standard methods as defined in 
+[https://eips.ethereum.org/EIPS/eip-721](https://eips.ethereum.org/EIPS/eip-721).
 
 ## Proxy
 The proxy contract allows execution of arbitray code using the `execute(bytes memory _code, bytes memory _data)` method. This method deploys a contract with the provided code, if it is not already cached and executes it with delegate call.

docs/tinlake/ui/overview.md

@@ -8,12 +8,20 @@ category: 4. Tinlake UI
 Tinlake UI provides a simple interface for Admins & Borrowers to interact with Tinlake Contracts. The UI supports the following set of features:
 
 **Admins’ perspective**
-- Whitelisting loans
-- Managing loans
+- Set maximum borrow amounts for loans
+- Set thresholds for loans
+- Create interest rate groups
+- Set interest rates for loans
+- Whitelist investors to supply funds into tranches
+- Whitelist investors to redeem funds from tranches 
 
 **Borrowers’ perspective**
-- Borrowing loans
-- Repaying loans
+- Borrow loans
+- Repay loans
+
+**Lenders’ perspective**
+- Supply funds into tranches
+- Redeem funds from tranches 
 
 
 ![Tinlake UI](../../../src/images/tinlake/tinlake-ui.png)