Under the hood: how Mervey designs safety for digital products

Digital product security doesn't begin with pre-release checks, but with decisions made before development even starts. What data do we collect? Where do we store private keys? Who gets access? How do we help users avoid irreversible mistakes? At Mervey, these questions define our architecture, interface, and team processes. Here's how this approach works in practice.

Protecting user data: don't collect more than you need

Before developing any feature, we determine exactly what information it truly needs. Every extra field is additional data that must be stored, protected, and deleted on time. Collecting info "just in case" might help with future analytics, but it increases the impact of a potential breach. So our rule is simple: if a function works without certain data, we don't collect it unless necessary. User data protection starts right here—not by choosing an encryption algorithm.

Crypto wallet safety: control over private keys

In P2PChat, private keys are stored on the user's device, not on Mervey servers. Our team has no access to them—and therefore cannot manage the owner's funds. This design also defines our limits: we can't reverse a confirmed blockchain transfer or restore a lost seed phrase—the word sequence used to recover wallet access. These limitations must be explained upfront. Managing digital assets requires understanding which actions are irreversible.

Safe interface: warn before the mistake

When a transfer is irreversible, the interface must help users verify their decision before sending funds. Address verification, operation confirmation, and clear warnings about consequences are part of product safety. Their job isn't just to show information but to alert users to risks at the right moment. So when designing, we evaluate not only scenario speed but also whether a user has enough info to act consciously. Extra confirmations make sense if they help prevent loss.

Protection against social engineering

Not every attack starts with a code vulnerability. An attacker might pose as support staff, scare users into thinking they're blocked, and convince them to share data or approve transfers. So protecting against social engineering requires clear communication rules for our team. Our support never asks for seed phrases. We remind users about this in the interface and public channels, ensuring official contacts are always visible and easy to verify. These measures don't eliminate fraud but help users spot suspicious requests before handing over access.

Secure development: code checks and access control

Security depends on more than just your own code. Third-party libraries, integrations, and contractor work also affect system safety and need review. Before release, we conduct internal audits. We grant access with minimal necessary rights for limited periods: project members get only what they need to do their job. The unified Mervey team connects architecture, design, and development into one process. This keeps accountability high at the intersection of tasks where requirements are easily overlooked.

Security is a result of specific decisions

Encryption and testing are essential, but they don't replace thoughtful architecture on their own. Product safety comes from sequential choices: not collecting unnecessary data, limiting access, checking dependencies, and warning users before irreversible actions. This is how we define secure development: considering risks at every stage rather than addressing them only after an incident occurs. In the next installment of our "Under the hood" series, we'll explain how we test products before release and what limitations exist in our testing environment. Developing a product that handles money or personal data? Describe your task via the form on the Mervey website—we'll discuss security requirements and solutions to plan for before launch.