White-label partnerships
Embed the deniability infrastructure inside your custody platform, exchange, hardware wallet, or password manager. Powered by deny.sh, branded as yours. Revenue share or per-seat. We provide the cryptography, the audit posture, and the trust-anchor pipeline. You keep the customer.
Built for products that already hold someone's secrets
If your customers already trust you to protect a seed phrase, a recovery key, a private message, or a compliance document, deny.sh is the deniability layer that turns "we encrypted it" into "we encrypted it and when it leaks the attacker can't prove which decryption is real."
Custody platforms
Coinbase-class, Fireblocks-class, BitGo-class. Offer "deniable backup" as a premium customer feature. One ciphertext, two valid wallets. When the storage tier is breached or a backup file leaks, the recovered decoy doesn't betray the real holdings.
Exchanges
Protect operational hot-wallet keys against insider threat. Even an admin who decrypts a key file sees a convincing decoy unless they hold the genuine control file.
Hardware wallets
Ledger-class, Trezor-class. Companion app feature: encrypted seed-phrase backup with two passwords. Cloud-sync breach, drive seizure, lost device: the bytes decrypt to a dust wallet, the real recovery stays separated.
Password managers
1Password-class, Bitwarden-class. "Travel mode" with teeth: a second master password reveals a different vault. Both are mathematically valid. Useful for pre-positioned decoys when devices may be lost, seized, or surrendered in known scenarios.
Secure messengers
Add deniable archive: one encrypted history, two valid views. Useful for sources, journalists, and anyone whose phone gets searched.
Pharma, M&A, healthcare data at rest
Encrypted datasets that leak via a cloud-provider compromise, an exfiltrated backup, or a misplaced laptop decrypt to a decoy under attacker keys. Real research data, deal-room materials, and patient records stay separated, behind a control file the storage tier never holds. Existing at-rest-encrypted breach safe-harbours still apply.
How a partnership works
Three integration models. Pick the one that fits your stack.
SDK embed (most common)
Drop the 8.4KB deny.sh SDK into your existing app. Three function calls: encrypt, decrypt, generateDecoyControl. Zero runtime dependencies. Available for Node/TypeScript, Python, Rust. Ships in your binary, runs on your infrastructure, never phones home.
Hosted API (white-label)
Your customers hit your domain; we proxy the cryptographic work. You keep the brand and the relationship. We provide uptime, scale, and the cryptographic guarantee. SLA included.
Co-branded surface
"Deniable backup, powered by deny.sh." A small attribution badge in exchange for a deeper revenue share. We help your customers trust the cryptography because we're the people who built it.
Commercials
Two structures depending on integration model and volume. We're flexible, this is where most conversations end up.
Revenue share
Best for products where deniability is a paid premium tier. We take 15 to 25% of incremental revenue attributable to the deny.sh-powered feature. Recognition rules and reporting cadence agreed in writing.
Per-seat licensing
Best for products with a defined paid user-base. From $2/seat/month at the entry tier, scaling down with volume. The SDK is Apache 2.0 (free, no licence required). The seat-licence covers application-layer embedding rights, dedicated support, security updates, and a commercial licence on the application-layer code where needed.
Annual flat fee
Best for hardware wallets, on-device implementations, or products where per-seat tracking is awkward. Starts at $50,000/year for unlimited deployment within a single product line.
What's always included
Architecture review with our team. Multi-language SDK. Priority engineering support. Quarterly security updates. Co-marketing if you want it. NDA on whatever you need it on. Commercial application-layer embedding rights for the term of the partnership (the SDK is Apache 2.0 and free for embedding regardless).
Why partner instead of building it yourself
The cryptography is the hard part
Deniable encryption schemes are easy to design badly. Subtle errors break deniability without breaking the obvious tests. We're the people who shipped the open-source reference implementation. The 22-test in-browser verification suite at /verify is publicly auditable.
Independent audit in scoping
Third-party cryptographic audit in scoping for Q3 2026, results published when complete. Your customers benefit from the credibility without funding the audit themselves.
Story you can tell
"Ciphertext that doesn't betray your customers when it leaks, powered by deny.sh" is concrete and memorable. Compare to the alternative of trying to explain XOR-composition to your marketing team.
Speed
SDK embed: ~one engineer-week. Hosted API: same day. We've done the integration work so your team doesn't have to learn a new threat model.
Talk to partnerships
Tell us what you're building and how your customers are protected today. We'll come back with a scoped integration plan and commercial structure within 24 hours.
Looking for individual API access? See standard pricing. Building an internal tool? See enterprise plans.