Magi 0.12: BTC Vault v2, POA seats.

 The biggest Magi upgrade so far is rolling out. Mainnet moves from consensus 0.3 straight to 0.12 in one step, covering Bitcoin custody, how the witness committee is formed, how HIVE is staked behind nodes, and how the network's threshold keys are kept healthy. ## Why this release - **Bitcoin custody stays with the current committee.** After every election the vault key's shares are reshared to the new committee. Vault v2 adds full key rotation: a brand-new key is generated by the current committee and proven, then the coins move to it on-chain automatically, so key shares from former members end up guarding an empty vault. - **POA.** Witnesses now hold ratified seats, admitted by a vote of the existing seats, with equal weight per seat and collateral that stays bonded after a witness leaves for 3 days. - **Steadier threshold signing.** Key resharing and signing keep going when a node is slow or unreachable: an unresponsive node is left out of the next attempt instead of stalling the rest. ## At a glance | | Node (go-vsc-node) | BTC contract (utxo-mapping) | |---|---|---| | Range | main (consensus 0.3) -> develop b10d0fab | vault v2 (#29) -> main 23ff9b8 | | Commits | 361 | 21 | | Code | +22,787 / -2,422 lines, 181 files | +7,036 / -386 lines, 19 files | | Tests | +56,143 / -982 lines, 372 files | +10,317 / -64 lines, 64 files | | Files changed | 563 | 88 | Together that is about **29,800 lines of code** and **66,500 lines of tests** added, more than two lines of tests for every line of code. | Consensus version | Theme | |---|---| | 0.4 | Election safety and ledger fixes | | 0.7 | Proof-of-Authority seats, TSS session and key lifecycle rules, BTC signing safety halts | | 0.8 | BTC Vault v2, BLS and commitment hardening | | 0.9 | POA and TSS refinements, gateway weights, reward scoring | | 0.10 | Proof verification pricing, block apply hardening | | 0.11 | Vault key custody | | 0.12 | New vault keys reshared into the committee before activation, peer identity proofs, deposit memo improvements | ## BTC Vault v2 The vault can now move to a brand-new key. The contract owner starts a rotation, the current committee generates the new key, and the previous vault keeps serving until the new one is ready. A new key goes live only after it has produced a verified signature, and coins move to it only after it has been reshared into the committee, so every new vault is shown to work before it holds funds. The mapping bot then sweeps the coins from the old vault to the new one in batches that run in parallel, older coins included. Miner fees for the migration come from a dedicated fee reserve, so user balances are not touched, and small coins are swept at a fee that fits their size. A withdrawal that cannot be built right away, for example mid-rotation, is queued in order and paid once the vault can build it. Deposits to a previous vault address keep being credited for about 30 days after that vault is emptied, and an old vault is retired only once it is empty. A retiring vault key can only sign transfers to its successor vault. If anyone proves that a vault coin moved outside the contract's own spends, vault signing pauses, and governance can pause it as well. | Feature | What it does | |---|---| | Key rotation | The contract owner starts a rotation and the current committee generates a new vault key. The previous vault keeps serving until the new one is ready. | | Proven before activation | A new key goes live only after it has produced a verified signature and been reshared into the committee, so every new vault is shown to work before any funds move to it. | | Automatic migration | The mapping bot sweeps coins from the old vault to the new one in parallel batches, older coins included. | | Fee reserve | Migration miner fees come from a dedicated fee reserve. User balances are never touched. | | Adaptive sweep fees | Small coins are swept at a fee that fits their size instead of holding up the migration. | | Withdrawal queue | A withdrawal that cannot be built right away, for example mid-rotation, is queued in order and paid automatically. | | Deposit grace period | Deposits to a previous vault address keep being credited for about 30 days after that vault is emptied. | | Retirement only when empty | An old vault is retired only once it is empty. | | Scoped signing | A retiring vault key can only sign transfers to its successor vault. | | Safety halt | Vault signing pauses if a vault coin is shown to have moved outside the contract's own spends, and governance can pause it as well. | ## Proof-of-Authority witness seats This is about who gets to run the network and hold a share of the vault key. Until now, the committee was formed mostly by stake weight: put up enough HIVE and you could be voted in. For a system guarding real Bitcoin, that is risky — a well-funded newcomer could buy their way onto the committee quickly. Proof-of-Authority replaces that with "seats." A seat is an approved spot on the committee, and you only get one if the witnesses who already hold seats vote you in (two thirds have to agree). Every seat counts equally in elections, no matter how much HIVE is behind it, so no one can dominate by sheer size. Just as important, leaving is not instant: your collateral stays bonded for a few days after you step down, and stays locked entirely while any vault you helped guard still holds funds. That means a witness cannot grab a key share and immediately walk away — their money is on the line until the coins they were trusted with are safe. Proof of authority is a transitional step and will be loosened over time. | Feature | What it does | |---|---| | Seats | Only witnesses holding a ratified seat can be elected to the committee. | | Admission vote | New seats are admitted by two thirds of existing seats (`vsc.admit_vote`). | | Equal weight | Every seat carries the same election weight. | | Churn cap | Limits how many new members can join in a single election. | | Exit halt | A departing witness's collateral stays bonded for 3 days after it leaves the committee. | | Bond backs custody | A witness's bond stays locked while a vault it holds a key share of still holds funds, and is released once that vault has been emptied. | | Smooth transition | Founding seats are seeded from the current committee, and each founding member proves its consensus and gateway keys. | ## TSS and consensus hardening TSS (threshold signature scheme) is the technology behind the shared vault key. The key is split into pieces held by the committee members, and a signature needs enough of them to cooperate, so no single member, and no small group, can sign alone. Consensus is the separate process by which nodes agree on the state of the chain. Both are plumbing most users never see, but they matter in different ways. If consensus stalls, everything on Magi waits. If TSS stalls, BTC withdrawals wait for their signature, while deposits keep being credited, because crediting a deposit needs consensus, not a signature. This release is a batch of reliability and safety fixes for that plumbing. The headline: a key reshare no longer stalls when one or two nodes fail to take part. A reshare needs every listed member to answer, so a single silent node fails the attempt for everyone. Now, when at least two thirds of the committee confirm that a node did not take part, the next attempt goes ahead without it, up to two nodes per attempt, and never so many that the committee drops below its minimum. The rest are guardrails against dangerous edge cases. A reshare can never produce a key that less than a majority of the committee can sign. An election can never shrink the committee below its safe minimum. Holders of the live vault key stay available to sign after they leave the election, so the key keeps its signers while the committee changes. A node banned for repeated failures is let back in when a session would otherwise be short of members, so a ban alone never leaves a key unable to sign. Several ways to game the committee are closed off. | Feature | What it does | |---|---| | Unresponsive nodes skipped | If one or two nodes fail a key reshare, the committee leaves them out of the retry so the reshare completes. A key is never reshared below its signing threshold. | | Signing threshold kept | A reshare never leaves a key that less than a majority of the committee can sign. | | Quorum first | Bans yield when a session would otherwise lack the members it needs. | | Committee floor | An election can never produce a committee below the minimum size. | | Key holders stay available | Holders of the active vault key can still sign after leaving the election. | | Peer identity proofs | A witness announcing a P2P identity must prove it owns that key. | | BLS weight dedup | Duplicate keys in a committee count once. | | Commitment size cap | Oversized TSS commitment bundles are rejected up front. | | Safer version upgrades | A forced consensus version floor still needs the outgoing committee's quorum. | | Duplicate-safe block apply | A transaction already handled by an earlier block is never applied twice. | | Proof verification pricing | SP1 Groth16 verification is charged by the work it does, ready for proof-based bridges. | ## Gateway, ledger and API These are the parts users actually touch. The gateway is how value moves in and out — deposits and withdrawals between Hive and Magi. The ledger is the running record of everyone's balances. The API is the set of queries that wallets, dashboards and apps read from. The fixes here are smaller and more concrete than the deep protocol work above: unstaking HBD from savings now releases the stake the way you would expect, deposit memos accept a `to=hive:` tag for any valid Hive account, and when a transaction fails it now keeps a readable reason that apps can show you instead of a silent error. Nothing here changes how the network is secured — it just makes the everyday experience smoother and clearer. | Feature | What it does | |---|---| | HBD savings unstake | Unstaking HBD from savings releases the stake as expected. | | Deposit memos | `to=hive:` memos are accepted for every valid Hive account name. | | Gateway weights | Gateway multisig keys get equal weight under POA. | | Clearer errors | A failed transaction keeps its reason, visible through the API. | | Reward scoring | Pendulum rewards score only fully closed block slots. | ## How it was tested - About 66,500 lines of new tests, including full-network devnet scenarios covering rotation, seats, staking and fault conditions. - Repeated live BTC vault rotations on testnet. After 12 of them, a full funds audit found every vault coin on chain and matching the books, and HIVE and HBD gateway balances reconciled against Hive L1. - The first mainnet migration was rehearsed in tests shaped on the live mainnet vault. - Delegations, races between concurrent transactions, deposit memos, withdrawals and invalid inputs were all exercised live on testnet. ## Rollout 1. Node operators update to the new build. Nodes on watchtower update automatically; manual operators pull the new image and restart (stop, wait a minute, start). 2. Once the committee runs the new build, consensus 0.12 is proposed and activates on-chain. 3. The BTC contract is upgraded. Contract updates take effect 48 hours after submission, a built-in safety window. 4. The first vault rotation moves the BTC to a new key generated by the current committee. ## Next: EVM Ethereum is next. The EVM bridge is built on the same committee-secured model, and its mapping bot is already part of this build, waiting for launch. Proof verification pricing in 0.10 is part of that groundwork. More soon. Thanks to every witness operator and tester who ran the testnet builds. This release is the foundation for bringing more chains to Magi. --- *Posted via Lumen*</div> </div>