~~~~# Timeline and options

- FBX: new Workspace (for new Partners)
- March-April: onboard Smartbroker (without ERC20) & Realport (with ERC20)
- build our Blockchain and Wallet infrastructure
- April (run out from Addresses) ??: Migrate Nuri our Blockchain and Wallet infrastructure
- Creating a new globally pooled wallet with all new partners (excluding Nuri)
- June FBX: kills Legacy Workspace

## Smartbroker

- July: onboard to new FBX Workspace

## Realport + 360x

- March-April: onboard with ERC20
- can we develop ERC20 support for FBX on time??

## Nuri

- addresses will run out in current Workspace
- will remain on the legacy root private key

## Blockchain and Wallet infrastructure

* Blockchain full nodes -- per blockchain, cluster of full/archiving nodes
* ETH + BTC, multiple nodes (fallback, load balancing, etc), back-up strategy, security, data storage
* Infrastructure: set-up final instance (terraform)
* running node easy on linux environment
* easy to interface with indexer that runs in the cluster
* set-up and running it is straight forward.
* BUT running outside of our infrastructure, not part of our cluster
* SHOULD find out whether can run it on EC-2 and make it part of kubernetes -> can re-use service discovery (between ETH node and Indexer) or use features of kubernetes
* SO THAT we have monitoring, alerting, back-ups
* Migrate to kubernetes is a PREREQUISITE by end of February
* REQ: Multiregion
* REQ: No stable outgoing IP Address
* Custody:
* ETH Track
* BTC Track
* Indexer -- tracks addresses and relevant blockchain txs, UTXOs , Fees, Account nonces etc, (broadcast?)
* need indexer to interface with nodes
* Part 1 (Support for Deposits)
* monitor Deposits for ETH
* monitor Deposits for BTC
* Part 2 (Support for Withdrawals, depends on 1)
* support for BTC Withdrawals (track and monitor UTXOs for BTC)
* support for ETH Withdrawals (track nonces of the accounts)
* estimate network fees
* address validation for destinations
* TX broadcasting
* Part 3 (Support for Address generation, independent)
* address generation using xpub (extended public key)
* ETH and BTC address generation are different

* Tx Constructor -- using data from Indexer, constructs an on-chain transaction
* Two independent constructors
* UTXO constructor: select UTXOs for BTC Withdrawals
* Accounts Constructor: create withdrawals for ETH

- Steps:
* Takes a request to create TX
* Creates a Blueprint of a TX
* Passes Blueprint, split into binary messages, to Signer
* Combines Blueprint + Signatures into a fully signed Blockchain TX

* Signer -- signs preconstructed transaction
* signs binary messages
* 1) simplistic: plaintext private key used to sign a message
* Pro: simple, not much effort
* Con: Not very secure
* 2) MPC w Fireblocks
~~ * 3) MPC in-house
* https://github.com/coinbase/kryptology
* https://github.com/binance-chain/tss-lib
* https://github.com/ZenGo-X/awesome-tss~~

Update from conversation with Julian:

- it does not make sense to build an inhouse-MPC solution that is attached to our own wallet infrastructure
- reason 1: we would have to build a new node, indexer, and all the functionality leveraged with fireblocks ourselves, including later on staking and DeFi
- reason 2: the only value is indepenendence from a wallet provider in the long run, but it creates huge amount of effort for us

conclusion: the cost-to-value relation does not justify the building of an in-house solution