Going to start sharing things I find interesting while researching stuff 📝 First post - looking at @thetnetwork’s tBTC implementation on @starknet. tBTC is a wrapped bitcoin asset on Ethereum that is moved onto Starknet via StarkGate. The core trust assumptions are: - Trust the Threshold Network to keep tBTC on Ethereum backed 1:1 with BTC - Trust the underlying StarkGate bridge contract to keep tBTC on Starknet backed 1:1 with tBTC on Ethereum - Trust the core Starknet systems contracts and their upgrade mechanisms (i.e. the 9/12 Starknet security council) - Users trust that a single signer does not execute malicious upgrades to the tBTC StarkGate contract. There’s a three day delay to upgrades. - If a malicious upgrade is implemented, users trust that the Starknet minority security council (3/12 threshold) will propose their withdrawal requests to exit StarkGate prior to the exit window passing Blog-ish version👇 Threshold Network’s tBTC is a wrapped bitcoin asset. The bitcoin backing tBTC is secured by 35 signers participating in the Threshold Network. tBTC is an ERC-20 token that is backed 1:1 by BTC secured by the Threshold Network. Starknet is an Ethereum rollup - a network that posts its state data to Ethereum. Starknet uses validity proofs to ultimately finalize L1 bridge programs. tBTC’s bridge contract, a StarkGate implementation, is one of these programs. To mint tBTC onto Starknet, users lock funds into the tBTC StarkGate bridge contract. The bridge contract then passes a message to Starknet to mint the corresponding amount of tBTC tokens on Starknet. To facilitate withdrawals, STARK proofs come in. STARKs are cryptographic proofs that essentially convince bridge programs of the current state of the Starknet network. After the bridge is convinced of this state, users can withdraw from the bridge. If users wanted to fully withdraw to native BTC, they would have to go through the Threshold Network’s signers. Still, users must keep in mind the various upgrade mechanisms around this implementation 🙂 All in all, I think this implementation will be pretty sound once governance controls are distributed. If they upgrade governance controls to the Threshold Committee signer set, then a 6/9 federation would be responsible for executing upgrades. It’s my understanding that this committee is currently being updated/reelected, so that may be why the committee doesn’t currently oversee governance upgrades.