A wallet's balance screen is not the control boundary. The important question is who can authorize a transaction.
Crypto assets are recorded on a blockchain. A wallet manages keys associated with those assets and uses the owner's private key to sign a transaction. The public address can be shared to receive funds, but it is not a signing secret. In a non-custodial design, the service should not be able to sign a transfer independently of the owner.
Separate recipient discovery from transaction authorization
DARCA supports finding a recipient by phone number, from a chat, through nearby Bluetooth discovery, by scanning a QR code or by entering an address. This changes only the discovery step. A phone number is not converted into a blockchain address, and Bluetooth is not a peer-to-peer asset transfer mechanism.
Once a recipient is selected, the user reviews the recipient, asset, network, amount and network fee. A PIN or biometric confirmation authorizes the local signing flow. The app signs on the device and submits the signed transaction to the relevant blockchain. A chat message or payment request cannot debit the wallet without this separate approval.
Network choice is part of the transaction's correctness. A token can exist across multiple networks; ERC20 and BEP20 are examples of different token standards. The sender must choose a network compatible with the recipient's wallet. The interface should make that choice visible before signing.
Backup and recovery boundaries
DARCA does not store the seed phrase or private keys on its server in plaintext. A separate DEK (Data Encryption Key) encrypts the seed phrase and other private data. Argon2id derives keys from a password or seed phrase, while AES-256-GCM protects private data and the DEK. Decryption happens locally. The server receives an encrypted backup and technical recovery parameters, but not the plaintext DEK, decrypted backup, private keys or seed phrase. A successful login does not itself provide the server with the material to sign a transaction.
The seed phrase is still available in settings as an independent recovery option. It is not placed in front of every user during registration, where it could be copied into a screenshot or an inadequately protected note.
This design does not remove user-side risks: phishing, malware, device loss, exposed recovery data and incorrect transaction details remain relevant. DARCA charges no additional transfer fee, but the blockchain network fee applies. The app displays the fee before signing and provides a transaction hash after submission.
The useful test for any wallet is to trace one operation: who constructs it, who signs it, what the server can access and what the user sees before approval. Which part of this flow would you inspect first when evaluating a wallet?
The engineering boundary
The product problem is not just how to hide long addresses. It is how to reduce address handling without turning recipient discovery into transaction authorization. Those are separate operations with different security consequences.
A phone number can be useful as an application-level lookup key. It cannot replace the blockchain address inside the signed transaction. Bluetooth can help identify a nearby user. It does not create a transport channel for the asset. A chat can carry a payment request. It must not become an implicit authorization channel.
The implementation therefore has to preserve a visible confirmation boundary. Before signing, the user needs the recipient, asset, network, amount and fee. After confirmation with PIN or biometrics, the signing operation happens locally. The server can support discovery, synchronization and recovery infrastructure without receiving the material that would let it sign independently.
Network and transaction state
A wallet that supports several assets also has to represent network context explicitly. ERC20 and BEP20 are not interchangeable labels for an abstract coin. They refer to different token standards and ecosystems. A transaction can be syntactically valid and still be sent through a network that the recipient cannot use. Network selection must therefore be part of the confirmation data, not a setting that disappears behind a generic Send button.
The same applies after submission. A useful history record includes recipient, asset, network, amount, fee, status and transaction hash. The hash allows the user or an engineer to inspect the operation on the relevant blockchain. A loading spinner alone does not explain whether the transaction was prepared, signed, broadcast or confirmed.
Recovery and threat model
DARCA's recovery design separates the encrypted backup from the values needed to open it. The DEK encrypts the seed phrase and other private data. Argon2id is used to derive keys from a password or seed phrase, and AES-256-GCM protects the private data and DEK. Decryption remains local. The server stores an encrypted backup and technical recovery parameters, but not the plaintext DEK, decrypted backup, private keys or seed phrase.
This reduces the server's independent signing capability, but it does not solve every threat. A compromised device can expose secrets at the point of use. Phishing can trick a user into approving a transaction. An exposed seed phrase can enable recovery outside the application. A wrong address can create an irreversible result even when the cryptographic flow works exactly as designed.
The design trade-off is therefore explicit: remove routine address copying and technical friction, while keeping recipient review and signing approval with the owner. The right evaluation question is not whether an interface looks simple. It is whether the simplicity changed the authority model. Which boundary would you test first in a wallet implementation?
What to inspect in a real implementation
A useful review can be organized around observable boundaries rather than claims. First, identify which operations happen on the device and which require the server. Next, inspect what the confirmation screen actually binds together: recipient identity, destination, asset, network, amount and fee. Finally, test whether a successful account login is sufficient to access signing secrets or whether a separate local step is required.
For DARCA, this distinction is reflected in the backup flow. A DEK protects private data, but the server does not receive the plaintext DEK or decrypted backup. Argon2id and AES-256-GCM provide key derivation and authenticated encryption in the described flow; local decryption preserves the separation between account access and wallet signing. The seed phrase remains available to the owner as an independent recovery method.
This is not a substitute for a full security assessment. The description does not establish how every device compromise, phishing scenario, implementation defect or recovery edge case behaves. Those questions require testing and review of the actual implementation. The product boundary that can be stated here is narrower: transaction signing is intended to occur locally after owner confirmation, and the server is not intended to sign independently.
That is why reviewing the workflow matters. A label such as non-custodial should be followed by concrete questions about keys, recovery, server access and the data displayed before signing. Which test would you run first against a wallet that claims local signing?
Top comments (0)