unnawut
commented
6 years ago Initial thoughts from 3 months ago by @mederic-p:
A private contract can be created between 2 wallets using the following process:
Step 1: eWallet A wants to establish a contract with wallet B.
Wallet A will go to the admin panel where a list of the existing (and registered in a private contract) ewallet can be found. This list will be pulled from a private contract that contains a map of each wallet public address and its associated domains. If the Wallet B is not registered in the private contract, Wallet A can input its address and domain manually.
The complete list of attributes is to define, but the contract will at least contain:
- The external id of the contract
- A list of exchange pair with their associated conversion rate (and daily/monthly/… limit?)
- The address and domain of both wallet
- ...
A submits the contract to B
Step 2: eWallet B receives a pending contract in its database and can approve it (make a call to A). The contract is then active
Upon approval, a new address is generated in each wallet containing the balances corresponding to the pairs defined in the contract (with no value for now).
Step 3: Each wallet preload their contract balances in the opposite wallet.
An endpoint should be available to allow a wallet to credit a contract balance in the other wallet. This will allow each wallet to have a stock of the opposite wallet tokens and thus allow transaction to happen only inside the wallet without the need of transferring currency out of the wallets.
The final setup with eWallet A connected to eWallet B and eWallet C with private contracts would look like this:
And the transaction process between users from 2 different wallets would be as follow with:
- User A -> user from wallet A
- User B -> user from wallet B
- User A wants to send 50 ETH to user B, but user B wants to receive OMG with a ratio of 2:1 for the pair OMG/ETH defined in the private contract (user B should receive 100 OMG).
User A creates a transaction request of type send a generate a QR code from it. The encoded data in the QR Code should contain the id of the request (defined in Wallet A only) and a way to identify in which wallet the transaction request exist.
This means that we need to have a way to uniquely identify a wallet across the network. A suggested way to do this in this proposal is to use an ethereum address that should be bound to each wallet. This address should also be the one used to key the domains in the domain name smart contract.
So the suggested encoded data in the QR code would be: address|id (ie: 0x74660414dFae86b196452497A4332bD0E6611e82|txr_01cbfg8mafdnbthgb9e68nd9y9)
Then User B scans the QR code, decrypts it, and make a transaction_request.get request to get the request detail to its own wallet including the address parameter.
In general there are 3 possible cases here:
- The address sent is the address of wallet B -> The transaction is an intra wallet basic transaction
- Wallet B doesn’t know about the address sent (doesn’t appear in any of its private contract) -> Should render an error
- Wallet B has a private contract set up with the address sent (Wallet A) -> Wallet B should make a contract call to Wallet A forwarding the transaction_request.get request and returning the transaction_request to User B.
For this example we are in the case 3).
User B can then consume the transaction by making a call to its wallet, we have again the same 3 cases as above. Wallet B will forward a transaction_request.consume call to Wallet A. 2 cases here:
- The request requires a confirmation:
A web socket should be sent to User A similarly to intra wallet transactions and Wallet B should NOT proceed to the transaction immediately, but wait for the confirmation.
When User A confirms the consumption, Wallet A should forward the transaction_request.approve or transaction_request.reject call to Wallet B.
If the transaction was approved by User A, the transaction should happen and Wallet B should send 100 OMG to User B from the private contract balance and notify the finalized transaction. Wallet A should debit 50 ETH from User A and credit the contract balance by 50 ETH.
If the transaction was rejected by User A, the transaction should NOT happen and Wallet B should notify User B that his consumption was rejected.
- The request doesn’t require a confirmation:
The transaction should happen immediately and so when the consume call is made Wallet A should move 50 ETH from User A to the contract balance and notify User A, then Wallet B should move 100 OMG from the contract balance to User B.
This issue tracks the progress of the OIP for setting up and running private contracts on the OmiseGO eWallet.
Note that the content of this issue is more of a scratchpad for collecting initial thoughts than an actual OIP. The actual OIP will be submitted as a pull request.