dApp Development Company Red Flags: What Vague Answers About Custody and Key Control Usually Mean

dApp development company red flags: what vague answers about custody and key control usually mean

Most red-flag lists for vetting a dApp development company focus on generic warning signs: no portfolio, no references, unrealistic timelines. Those are worth watching for, but there's a more specific and more consequential category of red flag that's easy to miss if you don't know what a good answer sounds like: vague or evasive responses about custody and key control, the exact decisions we walk through in building a non-custodial crypto wallet.

Why This Specific Question Matters So Much

If a dApp involves a wallet, or any mechanism for holding or moving user funds, custody design is one of the highest-stakes decisions in the entire build. Who can access private keys, under what conditions, and with what safeguards, determines whether user funds are actually safe or merely appear safe until something goes wrong. A development company that can't speak specifically and confidently about how it approaches this is either inexperienced with the problem or hasn't thought about it as carefully as it should have.

Red Flag: "We'll Figure Out Custody Later"

Custody architecture is a decision that belongs at the design stage, not something to be resolved once development is underway, the same layer-by-layer thinking we apply in dApp Architecture 101. A firm that treats it as a detail to sort out later, rather than a foundational choice that shapes the whole system, is signaling that it doesn't yet understand how deeply this decision affects everything downstream: the API design, the key storage approach, the recovery flow, the multi-chain support strategy.

Red Flag: No Specific Answer on Key Generation and Storage

A firm with real experience building non-custodial systems should be able to speak concretely about how keys are generated and stored, not in marketing language, but with technical specifics. On-device key generation following established standards (commonly referred to by their standard numbers, BIP-39 for seed phrases, BIP-32 and BIP-44 for hierarchical deterministic wallet derivation) and hardware-backed key storage where the platform supports it are the kind of specifics a firm that has actually built this before will mention without prompting. A vague answer like "we use industry-standard security" without any specifics is a sign the firm may not have hands-on experience with this exact problem.

Red Flag: No Clear Answer on Multi-Chain Support

If the dApp needs to support more than one chain, ask specifically how the wallet or custody layer handles that. A firm with real experience will have a clear answer about how key derivation and address generation work across chains, and what happens if a new chain needs to be added later. An evasive or overly simplified answer here often means multi-chain support hasn't actually been built and tested before, only described as a feature that "should be straightforward," a gap our checklist for vetting a full-stack Web3 development company also flags.

Red Flag: Claiming to Know Your Regulatory Position

This one runs the opposite direction from vagueness: be cautious of a development company that confidently tells you which regulatory model your business needs, rather than building to a custody model you specify and directing you to qualified legal counsel for that determination, exactly the distinction we make on our about page. A firm that positions itself as also being your regulatory advisor is either overstepping its actual expertise or underselling the seriousness of that question.

Red Flag: No Written Terms on Key Control and Ownership at Handover

Finally, watch for a firm that's vague about what happens to deployment keys, admin access, or key-generation infrastructure once the project is delivered. A serious development company will have this in writing before work starts, not as something negotiated after the fact: who holds what access during development, and exactly what gets transferred, and how, at handover. This is the same standard we hold ourselves to, whether you're building in-house or weighing an outsourced build.

What a Good Answer Actually Sounds Like

The contrast with all of this is a firm that speaks specifically and matter-of-factly about custody: which standards it follows for key generation, whether hardware-backed storage is used and on which platforms, how multi-chain support actually works technically, and a clear statement that it builds to the custody model the client specifies rather than dictating the client's regulatory position. That level of specificity, delivered without hesitation, is usually a much better signal of real experience than a polished pitch deck or an impressive client logo list.

Previous post

Keep your code secure with Dapplication.

Contact us