Last week, SwissBorg lost $41 million worth of SOL, due to a suspected compromise in its integration with their staking provider, Kiln. On-chain, staking on Solana is fundamentally low-risk. It’s non-custodial, and there is no slashing on Solana. When you delegate tokens to a validator, you remain in full control of those tokens. A validator cannot spend, lock, or destroy delegated tokens. At worst, if a validator stops validating, the delegator simply stops earning rewards. So how could a compromise lead to a loss of 193K SOL?
The answer lies in the difference between security-by-assumption and security-by-design. Traditional finance relies on trust and legal enforcement. In crypto, we rely on cryptography. We build systems that are secure by construction, rather than by assumption. We build systems that don’t have the ability to lose funds, rather than a mere legal obligation not to. Transaction crafting APIs go against these principles, and introduce unnecessary risk. Risk that, as the incident shows, is not negligible.
At Chorus One, we offer an SDK to help with transaction crafting, but we have never built a transaction crafting API, because such an API is fundamentally a security hazard. It’s a dangerous primitive that should not exist. We provide the tools to simplify staking, and we help our customers build their integration in ways that are secure by design, and which mitigate attack vectors that can result in a loss of funds, even in case of a breach. In today’s computing landscape, compromises are a matter of when, not if. For a system to be secure, it’s not enough to try and prevent a breach. A secure system takes the possibility of a breach seriously, and takes measures to limit the blast radius when a breach inevitably happens. A secure system employs defense in depth: a layered approach to security, so that a breach of a single layer is not fatal to the entire system. And most of all, a secure system minimizes attack surface. The only API call that can’t be compromised, is one that does not exist.
In this post we’ll clarify the technical details of staking transactions on Solana, and the security implications of the different ways of constructing them.
To stake on Solana, you have to craft a staking transaction, sign it, and broadcast it to the Solana network through an RPC node. As part of this staking transaction, you choose which validator to delegate to, and how much to delegate. The Solana network will process that transaction, and from that point on, you’re staking. If the validator that you delegated to performs its duties, the network automatically distributes staking rewards to your account.
Unstaking is a two-step process. First, you send a stake deactivate transaction to signal your intent to stop staking. After the network processes this transaction, it takes time for the stake to become inactive. As soon as the stake is inactive, you can send a stake withdraw transaction to make the SOL liquid again.
Staking transactions are a core part of Solana, and they work the same regardless of the validator that you want to stake with. Just as the amount to stake is a parameter in the transaction, the validator to delegate to is a parameter. Supporting delegation to one validator is no more difficult than supporting delegation to another, and different staking providers in principle do not need different integrations.
At a low level, a staking transaction is a small piece of data. We need to encode the parameters, ( e.g. which validator to stake to and amount of SOL to delegate,) into a binary format. Because stake transactions are fairly simple, writing code that generates the correct bytes is not too difficult for a developer familiar with Solana, and it’s possible to understand and verify the meaning of every byte in the encoded data. Still, it requires a few steps to prepare the data in the correct format, so the developers of the Solana blockchain offer a library that can do this in a single step. Application developers can embed that library into their application, and as a result, they can support Solana staking with less effort.
Adopting a library creates risk: by calling a library, a developer is now leveraging third-party code to craft a staking transaction, but how does that developer know that the third-party code is behaving as expected and not, say, crafting a transfer transaction that sends all their users’ funds to an attacker’s wallet? Fortunately, Solana’s libraries are open source. Developers can read the source code, and observe for themselves that there is nothing fishy going on. When Solana developers include exactly that code into our application, the system is secure.
To support staking on Solana, in principle you don’t need to integrate with a staking provider at all. If you can craft staking transactions, you’re good to go, and crafting staking transactions is easy. Still, there are reasons to integrate more deeply with a staking provider, such as tracking delegations for the purpose of rewards reporting. Such features do not need to interact directly with transaction crafting, and when implemented correctly, do not compromise the security of the system.
A different reason to go with vendor-specific integrations is uniformity. The Solana developers offer a library for transaction crafting on Solana, the Aptos developers offer one for Aptos, etc. Integrating any single chain is not too complex, but supporting 30+ chains, and a multitude of ways to sign (software wallets, hardware wallets, multisigs, custodians, etc.) … it adds up.
At Chorus One we understand this struggle, and that’s why we built the Chorus One SDK that bundles everything in a single place, behind a consistent interface. While some domain knowledge will always be needed to integrate a chain — different blockchains are just that different! — our SDK helps developers kick-start their integrations.
Our SDK is a layer on top of the official libraries offered by the chains we support. As with any decision to adopt a library, introducing an additional layer introduces risk. There is more code, more parties involved, and in general more moving pieces with room for error. To mitigate this risk, our SDK is open source. Anybody can see what it’s doing, and confirm that nothing fishy is going on. Still, every new layer brings at least some minuscule amount of risk, so we allow our customers to make this trade-off for themselves. Our SDK is there to help institutions integrate staking faster, with less effort, but for those unable or unwilling to introduce additional third-party code, it is always possible to use the underlying libraries directly.
There are multiple ways for an application to integrate functionality provided by a third party. Two popular ones are the SDK, where the third party provides a library of code to include into the application, and the REST API, where the application connects over the Internet to somebody else’s computer, to ask it to perform some task.
With our SDK, you embed our code directly into your application. Because the code runs as part of your application, this means that it continues to work regardless of what happens to Chorus One. If we disappeared tomorrow, our validator may stop validating, and we would not release new versions of the SDK, but you would still be able to craft unstake transactions. A library-based integration is also great for uptime: there is nothing that can go down, it’s 100% reliable by construction. It’s also great for security: you know exactly what code will run. You can read it and verify what it does, and you can be sure that it doesn’t change under your feet.
In practice, most developers don’t read the code of the libraries they use in detail. For even a modestly complex application, this would be utterly infeasible for a single person. Even in crypto, software is to some extent built on trust. For transaction crafting however, because it’s such a critical component, and because it’s not that complex, it is feasible to verify the full source code, and we would recommend any integration partner to do that. With our SDK the choice is yours: trust, or trust but verify. Once you’ve verified, you can be confident that your system is secure even going forward, because you control when you update your code.
Contrast this with an API. With an API, you make a request to a third party, who then runs code to compute a response. From a reliability standpoint alone, this introduces a critical dependency on the third party. If their API is offline, your application stops working. From a security perspective, it introduces an even more critical dependency. You get to see the response to your request, but not the code that computed it. If you ask a transaction crafting API “please give me a staking transaction”, how do you know that the response is really a staking transaction, and not a transaction that steals your funds? One way of verifying that would be to decode the transaction, but that’s as complex as crafting one in the first place. Making an API call and then verifying the result at best creates additional work, and in the worst case introduces reliability problems. For something as critical as transaction crafting, not verifying is not an option. It would be reckless to blindly trust a third party. Note that it’s not enough to verify once. You need to write code that verifies every response. This is because the API is not under your control. The third party can change it at any time. Your application can start misbehaving even when you made no changes to it. And as the potential breach of Kiln’s API painfully demonstrated, a third party API can even start returning malicious responses.
APIs do have their place. We need APIs, for example to submit transactions to the blockchain. An API does mean introducing a third party, and we have to carefully consider how that affects the security of the system. For something as critical as transaction crafting, blindly trusting an API is not only reckless, it is also completely unnecessary. That’s why we offer the Chorus One SDK as a library, rather than an API.
To learn more about Chorus One’s SDK, access our docs or reach out for a demo.
