---
# System prepended metadata

title: Untitled

---

~~~~# 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