There is a strange moment when many people first use a non-custodial crypto wallet. You have just created the wallet and barely had time to understand how it works. Then the app shows you 12 or 24 words and tells you to store them somewhere safe.
Lose them and you may lose the ability to recover access to your assets. Show them to someone else and the assets themselves may be at risk.
The logic is clear. A non-custodial wallet gives the owner control over their crypto, and control comes with responsibility for the keys. But one question kept bothering us: does that responsibility have to begin by exposing the wallet's primary secret and immediately asking a new user to solve the problem of protecting it?
When we started building DARCA, this became one of the central security questions. We wanted to preserve the defining property of self-custody - the owner, not the service, controls the assets - while removing the situation in which one mistake around a seed phrase can undermine the whole security model.
DARCA is a non-custodial wallet built around that principle. A seed phrase is generated during registration, but it is not automatically shown to the user. DARCA does not see the plaintext phrase and cannot decrypt it independently.
Self-custody should not require exposing the primary secret on day one
The difference between custodial and non-custodial storage is more important than the wallet interface. In a custodial model, the user depends on a service that controls the infrastructure holding the assets. In a non-custodial model, the keys remain under the owner's control, so the service must not be able to move the crypto on its own.
DARCA follows the second model. We do not store seed phrases or private keys in plaintext. We cannot independently decrypt the wallet backup, and we cannot use the owner's assets. Keys are created and opened on the owner's device. The standard BIP-39 seed phrase remains available as a compatible recovery mechanism when the owner deliberately needs it.
That is the foundation for us. Users should not have to hand over their keys merely because that is the easiest way to build a service. At the same time, self-custody should not turn into a list of extra risks that a person has to manage perfectly from the first minute.
The most obvious example is the seed phrase.
Why DARCA does not show the seed phrase during registration
Seed phrases are usually presented only as a security mechanism. They also create a second problem: once the words are displayed in plaintext, the user has to preserve them so they are neither lost nor exposed.
A screenshot can be stolen along with access to a photo library. A plain text file can be copied. A phrase in notes can be synchronized accidentally or shown to the wrong person. A paper copy cannot be remotely hacked, but it can be lost, damaged, or forgotten in a drawer for years.
We decided not to create that risk automatically.
During registration, DARCA generates the seed phrase without displaying it. The user does not have to copy the words immediately, photograph them, or choose a place for a physical backup. Most importantly, DARCA does not receive the plaintext version either.
This creates an unusual situation: the wallet's primary secret exists, but after registration neither the user nor our team has seen it in plaintext. Control still belongs to the owner.
If DARCA does not know the seed phrase, where is it stored?
The seed phrase is generated on the user's device and encrypted there. The app generates a separate random data-encryption key (DEK), which encrypts the seed phrase with AES-256-GCM. The DEK is protected by a key derived from the user's password through Argon2id.
The server receives an encrypted wallet backup. It does not receive the plaintext seed phrase or the plaintext DEK. DARCA also does not receive private keys that could be used to control the assets.
That is why a backup does not turn DARCA into a custodial service. The server stores data needed for recovery, but it does not have everything required to decrypt that data on its own. Protected data is opened locally on the user's device.
We also separated account authentication from access to the wallet's cryptographic secrets. DARCA uses OPAQUE for password verification: the server can verify login data without receiving the password in plaintext. After successful authentication, the app can obtain the encrypted package, but that does not give the server the ability to open the secrets inside it.
For a user, this architecture is mostly invisible in day-to-day use. That is intentional. Security should not exist only as a set of instructions that a person must follow perfectly. Some protection can work before the user has to think about it.
What if I need my seed phrase?
It remains available to the owner. In DARCA settings, the user can intentionally reveal the seed phrase and store it independently. We do not block that option; doing so would make it difficult to call the wallet genuinely self-custodial.
The difference is when the decision is made. DARCA does not force a user to obtain the seed phrase during registration. If the owner wants to preserve it independently, they can choose to do so later, when there is a reason.
Once the seed phrase has been displayed, the security model changes. It can now be copied, photographed, written down, or exposed accidentally. From that point, it should be treated as potentially compromised and handled accordingly.
We are not limiting the owner's control in the name of safety. We are leaving control with the owner while avoiding an additional exposure before it is needed.
Security also means protecting users from their own mistakes
When people talk about crypto wallet security, they often picture an attacker trying to steal keys. A more ordinary failure is an owner losing the only way to recover their own wallet.
Someone can protect a paper seed phrase perfectly from hackers and then, years later, forget where it is. A physical copy can be destroyed or damaged. If it was the only recovery path, cryptography cannot repair the loss.
The encrypted backup in DARCA is partly meant to keep recovery from depending entirely on a person's ability to protect one secret in one place for years. The backup itself still does not give DARCA access to the assets: the server does not have the data required to decrypt it independently.
That is an important part of what a good crypto wallet should do. It should protect the owner not only from other people's actions, but also from situations in which the owner accidentally creates a problem that cannot later be fixed.
What we can actually claim about DARCA's security
Calling a wallet “the safest” means little without a defined comparison and evidence. We prefer to ask what data an attacker could obtain in different scenarios and what that data would allow them to do.
A compromise of the server database does not expose a plaintext seed phrase. An encrypted backup by itself does not authorize transactions. DARCA does not hold the plaintext DEK or the private keys needed to access the wallet independently. Password verification is separated from secret decryption. Until the owner requests the seed phrase, it does not appear on the screen or enter screenshots, notes, chats, or ordinary files by default.
This does not make the system invulnerable. No such system exists. The user's device and password still need protection. Once the owner reveals the seed phrase, they also take on the responsibility of storing it safely.
Our goal was not to promise that a wallet can never be compromised. It was to reduce the number of points where one mistake, one leak, or one compromised component automatically gives access to the assets.
That is the architecture behind DARCA's security claims: specific protections, explicit boundaries, and no promise of absolute safety.
Why launch another crypto wallet at all?
There are already plenty of crypto wallets. Adding another interface for holding crypto would not be a sufficient reason to build one.
For us, DARCA is an attempt to change the trade-off that has long surrounded self-custody. Users are often asked to choose between a service that takes on more responsibility and therefore gets more control, and a model in which the user has full control but must protect every critical secret without making a mistake.
DARCA keeps control with the owner while trying not to turn that control into a permanent security exam. The seed phrase was one of the first places where we applied the principle: it exists, belongs to the user, and can be revealed when needed, but it is not displayed automatically simply because that is the established flow.
That is why DARCA starts with security. Not with a promise that nobody will ever lose access or that a wallet cannot be compromised. Those promises would be dishonest. The practical question is smaller: how many dangerous actions can be removed from the user journey without taking control away from the owner?
For the seed phrase, our answer was simple. If the user does not need to see the wallet's primary secret right now, perhaps the safer default is not to show it at all.
Would you store a seed phrase immediately after registration, or reveal it only when you actually need it?
Top comments (0)