How Sceptre keeps transactions safe

Questions about how transactions are secured on Sceptre have been circulating recently on social media. Some of the conclusions drawn have been inaccurate, but understandable since they are based on information that, for safety reasons, were never made public. We don’t need our community to be sent into a panic, so those statements are worth addressing.

The Multisignature System

Multi-signature (multi-sig) wallets boost security by removing the single point of failure inherent to single-key wallets. Attackers cannot move funds without compromising multiple distinct keys simultaneously.

Sceptre takes this further with Multi-Party Computation (MPC), which splits a single private key into shares across multiple independent parties. On-chain, this system looks like an Externally Owned Account (EoA) - and that’s the root of the inaccuracies that led us to write this post. This layer of security is necessary since Flare has a non-EVM part (the p-chain) used by the Sceptre bot. Besides not covering the whole system, a simple multi-sig would never give us enough security.

The timelock

A timelock introduces a mandatory, public delay before certain smart contract changes can be executed. All Sceptre wallets are secured through our MPC setup, providing a consistent authorization framework across the protocol. With this shared framework in place, we have not added a separate timelock layer for contract administration. The main reason to introduce one would be to give third parties advance notice of upcoming contract changes, and no such requests have arisen to date.

The scope of a timelock is also important. On Flare, a smart contract timelock operates on the EVM-based C-chain and can govern administrative actions such as contract upgrades. It cannot apply to staking transactions on the P-chain, which is not EVM-based and does not support smart contracts. Our MPC manages staking actions across all the addresses we use, and those P-chain operations fall outside the scope of a C-chain timelock.

For Sceptre, a timelock would therefore primarily add delays to contract administration, while covering only a limited part of the operations already managed through MPC. We would reconsider this policy if a need for third-party advance notice emerges and communicate any change publicly.

A time-tested strategy

Sceptre is built on a foundation of proven security. The team behind it has spent nearly a decade building and scaling security infrastructure across major blockchain networks, protecting billions of dollars in TVL. Sceptre leverages a Multi-Party Computation (MPC) setup because time and experience have shown us that it’s the most robust protection available in the market today. Institutional capital allocators regularly audit and validate our security architecture, with our most recent private audit completed just months ago.

Regarding rewards from the deregistered identity

Following the remediation presented last week to the FTSO Management group, rewards from the second identity are being added to the pool until it ceases operation on September 16th 2026. As mentioned in the remediation, 100% of provider-side rewards accrued by this second identity will be passed to depositors, verifiable at 0x12e605bc104e93B45e1aD99F9e555f659051c2BB. Sceptre will not take the usual 10% fee on these rewards.

Talk to us

From day one, Sceptre has been built alongside our community. We pride ourselves on team accessibility, many of the things that make Sceptre what it is today came from feedback from our community. If you see room for improvement, our doors are always open and security is no exception; if you think we should change or improve something, we are more than happy to listen.

However, the recent public claims that led to this article went beyond constructive critique, creating unnecessary harm to Sceptre, our community and the Flare ecosystem. While we recognize these conclusions were drawn without access to complete information, public allegations of negligence or malicious intent are counterproductive. A simple direct outreach would have opened an immediate dialogue, allowing us to clarify our architecture and take in the feedback, as we always do.