Security without theater.
The strongest custody systems are intentionally unglamorous. Layered, redundant, and designed to fail safely.
We don't publish security details to impress you. We build systems that work, verify them independently, and share what helps you evaluate us without helping attackers.
How we hold bitcoin
Predominantly cold storage
The vast majority of client bitcoin is held in cold storage, completely offline. Only what's needed for immediate operations touches connected systems.
Multi-signature architecture
Moving bitcoin requires multiple independent approvals. No single key, person, or system can authorize a transfer alone. Keys are distributed across roles and locations.
Geographic distribution
Critical components are spread across jurisdictions. No single location failure can compromise access to client assets.
Hardware security modules
Cryptographic operations happen in specialized hardware designed to resist tampering and extraction. Keys never exist in exposed memory.
Zero trust model
Every access request is verified, regardless of origin. No user, device, or system is trusted by default. Authentication and authorization are continuous, not one-time events.
Continuous monitoring
Automated systems monitor activity patterns around the clock. Anomalies trigger alerts and, where appropriate, protective holds. Human review follows, but the first line of defense never sleeps.
Protecting your account
Passkey authentication
Sign in with biometrics or hardware keys. No passwords to steal or phish. Your device proves who you are.
Withdrawal protection
Set your own withdrawal limits and cooling-off periods. Once enabled, these limits can't be raised or disabled instantly. Changes require a waiting period before they take effect, giving you time to react if something is wrong.
Saved destinations
Maintain a list of trusted addresses you control. Withdrawals to saved destinations proceed without delays. New addresses require additional verification and time holds before transfers complete. Even if someone gains access to your account, they can't redirect bitcoin to unknown addresses.
Session management
Active sessions are visible and revocable. You can see where you're logged in and end sessions you don't recognize.
Activity notifications
Sensitive actions trigger alerts. You'll know if something happens on your account that you didn't initiate.
Operational discipline
Technical controls matter, but security ultimately depends on how an organization operates.
Separation of duties
No one person can complete sensitive operations alone. Different roles hold different pieces. Collusion would require coordinating across multiple independent parties.
Least privilege access
People only have access to what their role requires. Standing access to sensitive systems is minimized. When elevated access is needed, it's granted temporarily and logged.
Defined procedures
Critical operations follow documented procedures, not improvisation. When pressure arrives, we follow the playbook.
Background verification
Team members in sensitive roles undergo appropriate background checks. Trust is verified, not assumed.
What we don't publish
Some information is better kept private. A detailed security blueprint helps attackers more than it helps you evaluate us.
- Exact threshold configurations and signing requirements
- Physical locations and facility details
- Internal system architecture and vendor relationships
- Identities of people in security-critical roles
This isn't secrecy for its own sake. It's operational security that protects your assets.
Independent verification
We don't ask you to trust our claims. As we grow, we're building layers of independent verification:
- Reserve attestations confirming 1:1 backing
- Control reviews by qualified third parties
- Penetration testing by independent security firms
- SOC 2 or equivalent compliance attestation
We publish verification results when they're meaningful, not when they're marketing.
How we stay disciplined
Anyone can write policies. The question is whether those policies hold up when things get difficult.
We keep the mandate narrow
Custody, transfers, and conversion. That's it. We don't add products that introduce hidden risks. No lending. No yield. No financial engineering.
We assume you want safety, not returns
Our operating assumption is that you'd rather have predictable access to your bitcoin than marginal gains from us taking risks with it. If that's not true for you, we're probably not the right fit.
Routine checks catch problems early
Reconciliation, exception handling, and review aren't just for auditors. They're how we catch issues before they become crises.
We choose discipline over novelty
New isn't automatically better. We prefer repeatable processes, measured changes, and standards we can explain clearly.
Responsible disclosure
We value the security research community and welcome reports of potential vulnerabilities. If you've discovered a security issue, we want to work with you to resolve it responsibly.
How to report
Send your report to security@ficha.com. Include as much detail as possible: steps to reproduce, potential impact, and any proof-of-concept code.
For sensitive reports, you may encrypt your message using our PGP public key.
What we ask
- Report the issue to us before any public disclosure
- Give us reasonable time to investigate and address the issue (typically 90 days)
- Avoid accessing, modifying, or deleting data belonging to others
- Don't perform actions that could harm service availability
- Act in good faith to avoid privacy violations and service disruption
What we commit to
- Acknowledge receipt of your report within 48 hours
- Keep you informed of our progress in addressing the issue
- Not pursue legal action against researchers acting in good faith
- Credit you in any public disclosure if you wish (or maintain anonymity if preferred)
Bug bounty rewards
We offer monetary rewards for qualifying security vulnerabilities reported through responsible disclosure. Rewards are determined based on severity, impact, and quality of the report.
Safe harbor
Security research conducted in accordance with this policy is considered authorized. We will not initiate legal action against researchers who discover and report vulnerabilities in good faith, even if they inadvertently access data beyond their own accounts during testing.
Our security contact information is also available here (RFC 9116 security.txt).
Security is what we do, not what we say. The best evidence is consistent, careful operations over time.
