boostryjp / ibet-wallet-api Goto Github PK

テストケースを作成する。

node, list, bank の３つに分割する。

■入力
※検討中

■出力
※検討中

/v1/User/PaymentAccount

config.pyに今回のプロジェクトでは不要な設定値が存在しそうなので、不要なものは削除する。

作成済みのAPI仕様書を作成する

発行者から依頼があった場合に限り、トークンの格付け登録を行う業務が存在する。
格付けのオペレーションで利用する更新系のAPI

■入力
※検討中

■出力
※検討中

pip freeze で作成したが、最新の状態ではうまく動かにようです。修正します。

現状、MyTokeで固定になっているので、動的に変えられるようにする。

Testnetでテストするためのデフォルト値であるので、全て削除する。

キャンセル状態の注文が板に残ってしまっている。

約定結果を登録するためのAPI（約定確定・約定取消）

■入力
※検討中

■出力
※検討中

発行者から依頼があった場合に限り、トークンの格付け登録を行う業務が存在する。
格付けのオペレーションをミスした時などに登録内容を削除する際に利用する更新系のAPI

■入力
※検討中

■出力
※検討中

• blockに取り込まれるまでの時間をどうするか？
  • 通知画面にプログレスバーとかを出す？
  • 平均ブロック取り込み時間から算出する？

eth.GetTransactionCount()
eth.SendRawTransaction()

全体で発行されているトークンの一覧参照用API

■入力
なし

■出力
以下のリスト
　・トークンアドレス
　・トークン名
　・発行体名
　・商品区分（トークンテンプレート名）

収納代行ノードの公開鍵を参照するためのAPI
※投資家の個人情報を秘匿化する用途で利用

■入力
収納代行アドレス
　※収納代行ノードの向き先にリクエストを投げるので本来的には入力パラメータは必要ないと思うが、
　　念のためリクエスト先が誤りではないことを確認する意味でも入力するようにする。

■出力
　公開鍵（RSA）

RawTransaction作成時のGasEstimate用のAPIを作成する

■入力

{  
   "account_address_list": ["0x12345"]
}

■出力

{
    "meta": {
        "code": 200,
        "message": "OK"
    },
    "data": {
        "order_list": [
            {
                "token": { 
                   tokenJSON
                },
                "order": {
                   orderJSON
                }
            }
        ],
        "settlement_list": [
            {
                "token": { 
                   tokenJSON
                },
                "agreement": {
                    "orderId": 0,
                    "agreementId": 0,
                    "amount": 500,
                    "price": 12000,
                    "isBuy": false
                }
            }
        ],
        "complete_list": [
            {
                "token": {
                   tokenJSON
                },
                "agreement": {
                    "orderId": 0,
                    "agreementId": 0,
                    "amount": 500,
                    "price": 12000,
                    "isBuy": false
                }
            }
        ]
    }
}

RelatedTo:
#14
#21

保有トークン一覧及び、発行済トークン一覧でトークンの詳細情報（年利や発行体名など）を返さない場合、詳細画面のデータソースがないため、詳細情報取得APIが必要ではないでしょうか。
（ウォレットから直接callをするのは微妙だと思うので…）

マーケットに表示するトークン画像の保存場所を検討する必要がありそうです。

案)

• リスト会社のノード
• 分散DBを持たせる
• 発行体会社にアップロードしてもらいスマコンにURLを貼る

■入力

{  
   "token_address":"0x12345",
   "token_template":"IbetStraightBond",
   "order_type":"buy",
   "price":1000,
   "amount":20
}

■出力

{  
   "meta":{  
      "code":200,
      "message":"OK"
   },
   "data":[  
      {  
         "order_id":1,
         "price":20,
         "amount":100
      },
      {  
         "order_id":2,
         "price":20,
         "amount":4
      },
      {  
         "order_id":5,
         "price":100,
         "amount":50
      }
   ]
}

収納代行アカウントに対して、取引参加の認可を申請するAPI（いわゆるホワイトリストコントラクト）

■入力
・署名済トランザクション

　※コントラクトの入力
　　・収納代行アカウントアドレス
　　・銀行口座情報：JSON文字列（収納代行が公開している公開鍵で暗号化済）

■出力
・トランザクションID

■入力
※検討中

■出力
※検討中

https://github.com/N-Village/tmr-node/blob/master/app/api/v1/position.py#L60
上記の変換は不要。

注文完了時や、通知画面で見せる文面に使うデータのソースがないため、
作る必要があるかと思われます。

• 入金期限（売買価格によって変える？）
• 手数料

etc...

tmr-app: https://github.com/N-Village/tmr-app/issues/274

• revert()で失敗した場合
  • 途中で切ってしまうか、他の注文は実行するのか？
• トランザクション送信後に失敗した場合
  • revertを用いていた場合、なぜ失敗したかがわからない　→　全部eventにして、revertは用いない？

transferだけ成功した場合、取引所に預かりが残ったままになってしまう

※途中まで実装済み
保有トークン一覧のAPIを追加する。

■入力
・アカウントアドレスのリスト　※一つのウォレットで複数アカウントを保持している想定

■出力
以下のリスト
　・トークンアドレス（コントラクトアドレス）
　・トークン名
　・保有数量

　※トークンの画像も必要だが、画像についてはデザイン確定後に実装する。

■入力
　・アカウントアドレスのリスト　※一つのウォレットが複数のアドレスを保有している想定。

■出力
　以下のリスト
　・コントラクトアドレス
　・商品分類（テンプレート名）
　・トークン名

平均取得単価の算出、APIでの返却を行う

/v1/OrderListと/v1/OrderBookでResponseのオーダIDの命名が揃っていない

コントラクトのデプロイ時、

• クライアントではgasLimitを決められないため、直近のblockのgasLimitを返してほしい
  • blockが更新されて、BlockGasLimitが変わった場合はクライアントでリトライ？
  • それともestimateGasをする？
• chainIdも返してほしい

Quorumの場合は、ブロック生成スピードがかなり速いがこの設計で大丈夫か？

■入力
トークンコントラクトのアドレス一覧

{
  "address_list":["0x1e770b6e52ddbee99209db0ef73fe7c18a119ed0","aaaaaa"]
}

■出力

{
    "meta": {
      "code": 200,
      "message": "OK"
    },
    "data": [
      {
        "token_address": "0x0",
        "last_price": 240000
      },
      {
        "token_address": "0x1",
        "last_price": 240000
      },
      {
        "token_address": "0x2",
        "last_price": 240000
      }
    ]
  }
}

紆余曲折を経て、最終的に使わなくなったモジュールが存在するため削除する。

エラーハンドリングを追加する。
※どこまで厳密にエラーハンドリングするかは悩みどころ。

現状、http://localhost:8545 でベタ書きになってしまっているので環境変数化する。

Upgrade the exchange contract in relation to the following two modifications.

BoostryJP/ibet-SmartContract#9
BoostryJP/ibet-SmartContract#10

発行体情報を登録・参照するAPIの仕様修正

アドレス指定の参照時に投資家の秘匿情報を暗号化するための公開鍵（RSA）も返すようにする。

■やりたいこと

• トークン一覧のページング機能
  マーケット画面で、下までスクロールすると自動で伸びるページネーションを実装しようとしています。
  現在はマーケット画面でトークンすべてを返却する仕様ですが、
  下記のように取得する件数を指定されてそれを返却する仕様に変更したいです。
  APIの修正と複数データの投入、よろしくお願いします。

■懸念点（→仕様として説明する？）
表示されるトークンが重複する可能性がある。例

1. マーケット画面一番上に最新のトークンがあり、合計3件表示されている。(画面上からB,C,D)
2. その間に新たなトークンがでてくる（A）
3. ページング機能利用時に、4件～6件を取得する（D,E,F）
4. 画面の表示は、（B,C,D,D,E,F）となり表示されるトークンが重複する

■入力
11件目から20件目を取得する時
/v1/Contracts?offset=1&limit=10

■出力
以下のリスト
　・トークンのアドレス：コントラクトアドレス
　・トークン名
　・商品分類：テンプレート名

https://github.com/N-Village/tmr-app/issues/274

現状、PublicのEthereumを利用して開発しているが、Quorum利用に切り替える。

普通社債トークンの標準テンプレートを確定し、各APIの出力仕様に追加するものは追加する対応を行う。

現状、認定フラグを返していない？

■入力
※検討中

■出力
※検討中

約定済みのトレード情報を参照するAPI

■入力
※検討中

■出力
※検討中