Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Project: Teller-JSON #37

Open
IronBrotherz opened this issue Feb 12, 2018 · 2 comments
Open

New Project: Teller-JSON #37

IronBrotherz opened this issue Feb 12, 2018 · 2 comments
Assignees

Comments

@IronBrotherz
Copy link
Collaborator

teller-json

  • create repo/folder called teller-json
  • put documentation in README.md

The teller-json daemon will expose an HTTP API for:

  • binding a SKY address to a BTC address
  • binding a SKY address to a ETH address
  • (possibly binding SKY to other currencies)
  • checking the status of a bound SKY address

The two buy methods for binding a SKY address are:

  • direct: fixed-price purchase from wallet
    • when a deposit event is received, calculate amount based off fixed-price from wallet
  • passthrough: variable-price purchase through exchange
    • when a deposit event is received, send to external api

The daemon will continually watch bound BTC/ETH addresses and watch for deposits, and then execute purchases and deposit SKY to the user's address.

More requirements for the daemon:

  • use JSON storage
  • HTTP API respond with JSON

OTC flow/stages with JSON format

Stage 1
skycoin address:
time:

Stage 2 (deposit address)
btc address:

Stage 3 (transaction detected event, but not executed)
time:
btc tx id:

Stage 4
Buying the coins from c2cx

Stage 5
Wait for the BTC TX confirmation

Stage 6
Withdrawal and track withdrawal if its from our OTC wallet and not C2CX

Storage

Teller-json will use a JSON-flatfile database for storage. Here's an overview of the filenames and their contents:

db/bound/[sky address].json

Created: when /api/bind is called for the first time with [sky address].

Appended: successive calls to /api/bind with a [sky address]. Appends to dropoffs field.

{
  "address": "...sky address...",
  "dropoffs": [
    {
      address: "...dropoff address...",
      type: "...dropoff currency..."
    },
    {
      address: "...dropoff address...",
      type: "...dropoff currency..."
    }
  ]
}

db/status/[sky address].json

Created: when /api/bind is called.

Appended: successive calls to /api/bind with a [sky address].

[
  {
    "seq": ...dropoff sequence number...,
    "updated_at": ...unix time...,
    "status": ...dropoff status...
  }
]

status:

  • waiting_deposit
  • waiting_send
  • waiting_confirm
  • done
@nutmix
Copy link
Contributor

nutmix commented Feb 26, 2018

From Brandon:

  1. the otc/teller does not ask how much is to be transferred. It just waits for a transfer to the BTC account, and converts whatever is in there into SKY at the price at that point in time.
  2. If the amount is less than a configurable amount, set to 0.5 BTC initially, then it does not wait for confirmation before sending the SKY.
  3. If the amount is over the limit, it must wait for confirmation.
  4. Admin panel features:
    1. Secured by user login (config file) or admin network (port/ip)
    2. There is a configurable flag to switch on and off the "dont wait for confirmation" feature.
    3. "pause everything" button, and "pause this transaction" feature.
    4. The admin panel has an option to switch between auto price and fixed price.
    5. option to change the fixed price.
    6. option to change the skycoin source address (local mode)

@nutmix
Copy link
Contributor

nutmix commented Feb 26, 2018

Questions to be answered:

  1. Is there a timeout waiting for BTC to be deposited?
  2. Should we build a job which checks to see if additional BTC was deposited after the transfer, or after the deadline (and flat it or send it back)
  3. What stats are required?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants