CubeSigner now protects finality providers! Our new release supports Extractable One-Time Signature (EOTS) keys, which Babylon finality providers use to sign validation messages for proof-of-stake chains. This means validators <a href="/blog/staking-keys-status-quo" target="_blank">never load secret keys into memory</a>; it also allows CubeSigner to enforce an anti-slashing policy that ensures the validator cannot sign two conflicting messages (e.g., because of bugs in client software or operator mistakes) that would result in slashing. <br> ## Locking down validator operations After depositing (and before unbonding), Babylon finality providers (validators) sign finalized blocks for proof-of-stake chains. Like Ethereum, Babylon’s Bitcoin staking protocol includes a slashing mechanism to penalize safety violations. While there are some technical differences between how slashing works on Ethereum versus on Babylon, the concept is the same: if a finality provider double signs or otherwise behaves maliciously, they will be slashed to preserve the integrity of the system. <br> <a href="/blog/cubist-babylon-partner-on-anti-slashing-for-bitcoin-stakers" target="_blank">Last October we announced our collaboration with the Babylon team</a> on an anti-slasher to prevent honest Babylon stakers from double signing; the anti-slasher is a core security feature of CubeSigner’s Babylon support. <br> In CubeSigner, Babylon EOTS keys—like Ethereum validator keys—have an always-enabled anti-slashing policy, which guarantees that the EOTS cannot sign two conflicting messages at the same block height. This policy cannot be disabled, meaning that even an attacker who steals the finality provider's credentials cannot double sign. As Babylon gets ready for mainnet, we're excited to be running the first finality provider with such strong guarantees—and looking forward to onboarding other teams who are gearing up for the launch. <br> ## Locking down keys locks down shared security Even if a validator machine is compromised—or an insider goes rogue—CubeSigner’s anti-slashing policy means that attackers won't be able to hold the node operator's keys ransom, slash them, or unbond them. This reduces the burden on the (possibly small) handful of secops/engineers on a team, and makes it easier to scale the team without incurring additional risk. It also saves operators from building custom infrastructure for scaling and synchronizing the finality provider, key manager, and the anti-slashing database. Instead, they can combine CubeSigner with off-the-shelf tooling like GKE or EKS, configure their clusters to automatically scale and fallback to different data centers, re-balance machines, upgrade clients, upgrade OSes, and even upgrade hardware—without risking slashing or losing yield. <br> Want to learn more about securely managing your finality provider keys with CubeSigner? <a href="/contact-form-cubesigner-hardware-backed-key-management" target="_blank">Get in touch here</a>. <br>