Trustodial: An Ontological Dilemma
Trustodial: An Ontological Dilemma
A lot of criticism has been circulating after the recent announcement that Wallet of Satoshi will be returning to the United States shortly thanks to the integration of Lightspark’s recent “Spark” system, specifically focusing around the issue of trust models and whether the new version of Wallet of Satoshi constitutes a noncustodial wallet or not.
Spark is a system based on statechains (explainer article there). Statechains don’t have the most clear cut trust model. Spark is essentially the channel factory version of statechains, with numerous statechains nested inside of a transaction tree built on a single on-chain UTXO.
Statechains are a Layer 2 system that allow entire UTXOs to be freely transferred off-chain with no liquidity constraints, but with the requirement of accepting some trust tradeoffs. You must trust that an operator, the service provider essentially, will delete private key material every time the statechain is transferred.
So let’s look at what makes something noncustodial.
A user has unilateral control over their funds, or the ability to regain it.
No other party (or parties) has the ability to prevent the user from spending their funds, or regaining their ability to, or to spend them without the involvement of the user.
The first quality definitively applies to statechains. Just like a Lightning channel a user has the ability to use a pre-signed transaction to reclaim their funds after a timelock period to ensure honest settlement. The second quality isn’t so clear cut in terms of applying or not applying.
The statechain protocol requires the operator and original user to collaboratively generate a key that neither party ever has full knowledge of. Using their shares they can collaborate to pre-sign the users withdrawal transaction. When the original user transfers it to someone else, the original user, new user, and operator all collaborate to “regenerate” the same key but with a different set of shares between the new user and operator.
After signing the new user’s withdrawal transaction, the operator is then supposed to delete the share they generated with the original users. This prevents the operator from ever signing a new transaction with the original user, and the shorter timelock on the new user’s transaction guarantees that they can spend theirs before the original user can spend his.
If the operator does not delete old key shares, then it would be possible for them to collaborate with any past user who kept their key share to steal the funds in the statechain.
The Operator
If the operator is doing what they are supposed to and deleting their old key shares every time the statechain is transferred, they are not a custodial system. They physically are incapable of signing any transactions in collaboration with anyone except the current and rightful owner of the statechain. The pre-signed transactions decrementing timelock guarantees that the current owner can always confirm their withdrawal transaction before any previous owner.
Operators can even run their software in an SGX enclave or other secure computing environment, and have the enclave enforce the correct behavior of the software. It can even provide proofs (granted you trust the environment to not be broken) of this that others can verify.
They also have a strong incentive to operate the protocol honestly, because in doing so they are not required to comply with the regulations that come along with being a custodial service holding other people’s money.
The Users
End users have a unilateral withdrawal transaction. This can be used any time after the timelock for their ownership expires and before the timelock for the previous owners time window expires. If the operator stops responding or disappears, they have this option.
But they have to trust that the operator is operating the protocol honestly, and deleting past key shares. There is no way for them to really verify that. As mentioned above, something like the SGX enclave could handle security for the operator’s software and sign proofs it is running honest software. But all that is doing is moving the point of trust away from the operator and onto Intel, the makers of the SGX enclave.
Even when dealing with a truly honest operator, who has only ever run honest software and never cheated a single user, a user can never actually know that they are an honest operator. They can only see that the operator has been honest, and hope they will continue to be.
So….?
There is no real clear cut answer. In the situation where an operator is actually being honest, it fits all the criteria I laid out above to be noncustodial. The user has an unimpeded ability to gain full access to their funds, and no one else is able to stop them from doing that or steal their funds.
The problem is that it isn’t verifiable.
There is no way to trustlessly verify as a user that you have trustless control over your funds. Even if you actually do.
So there is a problem with labeling it as noncustodial, because even if it is it is not possible for a user to ever truly verify it. But there is also a problem with calling it custodial, because the operator cannot do anything to move funds without collaborating with another user and the current user has a unilateral withdrawal transaction. This creates a dilemma in terms of categorizing tools in the space.
I don’t know what the solution is, but the first step I think is acknowledging the technical realities occurring before jumping to label things one way or another (why not a new category?) because of your own incentives. These types of questions, especially in an environment of glacially slow Bitcoin protocol changes, will become more frequent as developers struggle with the trade offs of Bitcoin’s current limitations.
Bitcoin is a programmable money, and the ways people will program it won’t always fit neatly into our predefined boxes.
This post Trustodial: An Ontological Dilemma first appeared on Bitcoin Magazine and is written by Shinobi.
Filed under: Bitcoin - @ July 7, 2025 8:10 pm