JP@jpthor
Monero is super hard, but it's all coming together. Here are some nuances.
1) All XMR vaults will have a deterministic private view key, which is stored on chain and anyone can review to see inbounds.
2) All vaults carry a "birthday" height to allow fast scanning from the moment the vault was generated. This is stored on-chain, and is also used in a xmr-rescan tool to repair vaults with bad scans.
3) FROST keyshares are passed back to the main bifrost, encrypted and stored onchain for disaster recovery (alongside ECDSA and EDDSA keyshares)
4) The FROST engine runs in a sidecar with its own auth'd api to the Bifrst.
5) After an inbound is made, the system waits 1-conf and vault-nodes enters a "key-image" generation that extracts a key that can reveal if the inbound is spent later or not. This key-image needs to be gossiped to other nodes and verified, and stored on-chain.
this key-image is used to audit vault balances and feeds into the solvency checker.
6) All signed outbounds, nodes extract and gossip a tx-key alongside tx details. the tx-key allows anyone to verify the transaction has the right to_address, amount and gas. This has to be gossiped from signing-nodes to signing nodes (nodes in other vaults).
This tx-key is stored onchain and is used to audit outgoings
7) All inbounds have to wait 10-blocks before they can be spent, so the system smartly waits until 10-blocks before trying a TSS key-sign.
8) The system can estimate gas deterministically, so if the FROST-signer errors out from gas too low, the system does an on-demand gas hike that lifts the entire gas budget for 1 hour to help get the retry through.
9) deposits to inactive vaults cannot be refunded, so they are forwarded to the active vault and sit there in the system outside the pool for manual protocol refunds (if needed).
This is definitely the hardest integration ever for thorchain.
Let's get it! $XMR