Skip to content

Specification

Jump to bottom
Richard Ramos edited this page Jan 10, 2019 · 4 revisions

Teller Network Specifications

User Stories

License acquisition

  • Requires SNT to buy License for selling crypto to fiat
  • License is bought via approveAndCall on SNT contract to avoid having to create two transactions (one to approve SNT expense, one to buy license)
  • Buying a license allows sellers to set an area on the map to indicate where they're located.
  • Licenses can be released after N days have passed. SNT used for license is refunded back to the seller

Questions / Consideration

  • Where is the information of the seller stored?
  • Indicate via FAQ (similar to voting dapp) how can a seller acquire SNT
  • Once a license is bought, Sellers will appear permanently in the map. Possible solution:
    • License is automatically released once a time has passed (similar to ENS?)
    • Buying a license grants you access to sell crypto. But they need an additional stake that determines the max amount a seller can sell.
    • Part of stake is used as bond when there's an arbitration case opened
    • Harbinger tax. Acquiring a license incurs in a periodic tax depending on the amount of crypto the seller is willing to sell.

Buying crypto

  1. Buyer browses the map or list of sellers, and picks one based in the location / token sold / exchange_rate / reputation.
  2. Buyer proceeds to communicate with seller to determine Terms and Conditions of sale 1.1. If seller wishes to meet the buyer in a location, no escrow is created, and once the buyer and seller meet, seller sends tokens and receives the FIAT in exchange (END OF USECASE)
  3. If the seller wants to use Status for selling crypto, they proceed to create an escrow for their tokens, and exchange_rate
  4. Buyer sends the FIAT to the seller (bank/wire transfer, deposit, etc.) and marks transaction as paid if he has ETH for paying the gas. 4.1 If buyer does not have ETH, there's a function that receives a signature and can be used by a relayer or any third party to mark the transaction as paid on behalf of the buyer. This can be the same seller, and the gas cost is deducted from the crypto the buyer would receive
  5. Seller is notified of the payment. Proceeds to release the funds from the escrow
  6. Buyer proceeds to rate the transaction

Questions / Considerations

  • There's a high chance of buyers not having ETH to pay for transactions. Someone needs to act as a relayer for this operation, and receive a reward for this (Can gas relayer be used for this?)
  • Transaction rating should go both ways. Both the buyer and the seller should be able to see each other rate

Buyer does not pay

From step 3 3.1. Seller waits for expiration of the escrow, and cancels it. 3.2. Funds are returned to the seller, and escrow canceled.

Questions / Considerations

  • Escrows can only be canceled after they expire. If buyer pays and does not have enough time to mark a transaction as paid, it will be expired.
  • Cases can only be opened on Paid transactions.
  • If a transaction is expired, should a buyer be able to open an arbitration case, and if it's determined that the buyer did pay, what will happen? Maybe for buyers the expiration period should appear on the UI as being less than the real expiration time, so the buyer is still able to open a case while the transaction is still open.

Buyer pays and escrow is not released by the seller (NEEDS DISCUSSION)

Step 5 is never completed 5.1. Buyer attempts to communicate with seller 5.2. Buyer opens a case for arbitration

Questions / Considerations

  • Should the buyer be able to release a escrow if the transaction is marked as paid by the buyer and some time has passed after the agreed expiration time?
  • Buyer might not have ether for processing the transaction. Function should be able to receive a signature and be relayed by anyone (Relayer should receive a reward for this)

Buyer pays, seller verifies and they did not receive payment

Step 5 is never completed 5.1. Seller attempts to communicate with buyer 5.2. Seller opens a case for arbitration

Arbitration

Arbitration can be opened by the buyer or seller. Current implementation expects the escrow transaction to be marked as paid. End result of the transaction is the release of funds to the buyer or to the seller.

  1. Actor invokes openCase. If user does not have ETH for this operation, he can use a signed message and a relayer. Arbitrator(s) are notified.
  2. Arbitrator(s) reviews documentation / transaction details and determine the result
  3. Arbitrator(s) invoke setArbitrationResult and funds are released to the buyer or to the seller.

Questions / Considerations

  • Opening a case should require a bond. In the case of a seller it's easy because we can require an amount of SNT / ETH to open the case, or if using the stake in case we decide for that idea. For buyers, however, the situation is more complicated when they do not have ETH to pay gas and bond. How to solve this issue? possible solutions:
    • Documentation that backs the payment done by the buyer is shown publicly so anyone can open the case on behalf of the buyer, and receive a reward if the case goes to the buyer, and if the case goes to the seller, they lose the bond. (The third party here would act as curator to determine which cases are opened or not)
    • Other alternative is that buyers sign the message, the third party opens the case in behalf of the buyer and earn the reward which is deducted from the buyer's purchase, however losing the arbitration only incurs in gas cost.
  • Idea for notification: create a private group automatically between the buyer, seller, and arbitrator. Arbitrator is admin of the group
  • Arbitrators need a way to know their presence is required to solve a case. - Can Aragon Court be used for the arbitration process? Current implementation of the contract might be compatible if we set an Aragon DAO as arbitrators.
Clone this wiki locally