Security

Pending final legal review.

Our approach #

Peaknode exists so institutions do not have to be taken at their word. We hold ourselves to the same standard: this page describes what the platform does today, and nothing it does not.

Accounts and access #

• Passwords are stored as Argon2id hashes.
• Multi-factor authentication is available to every user, and organizations can require it.
• Sessions use short-lived access tokens signed with Ed25519, with rotating refresh tokens.
• Every API request is authorized against the caller’s organization and role permissions.
• Sign-in and password reset are rate limited, and password reset requires a proof-of-work challenge.
• Security-relevant actions are recorded in an audit log.

Data protection #

• Traffic to peaknode.ar, app.peaknode.ar, and api.peaknode.ar is encrypted with TLS.
• Sensitive fields, such as credentials for blockchain data providers, are encrypted at rest with AES-256-GCM.
• Peaknode never asks for or stores the private keys of your custody wallets, and never moves funds.

Cryptography in proofs #

• Wallet ownership. Each wallet signs a challenge issued by Peaknode. We verify the signature against the wallet’s address using the chain’s own scheme, such as ECDSA over secp256k1 for Bitcoin and Ethereum. Multisig wallets prove ownership by collecting signatures up to their threshold.
• Liabilities. Customer balances are committed as leaves of a Merkle sum tree, one tree for each asset. A customer can check their inclusion with a zero-knowledge proof against the tree’s root and total.
• Zero-knowledge proofs. Each inclusion proof shows that the customer’s balance is in the tree, and that their balance and every neighbouring subtotal on their path are below a fixed limit, without showing those subtotals. There is no single proof over the whole tree: negative amounts are ruled out collectively, by the proofs customers check.
• Funds. Balances are read directly from blockchain nodes and data providers at recorded block heights, never from an exchange’s own API.

Reporting a vulnerability #

Email [email protected] with a description, steps to reproduce, and the impact you see. Our contact details are also published at /.well-known/security.txt.

We aim to acknowledge reports within three business days and will keep you updated while we work on a fix.

Safe harbor. If you act in good faith, avoid privacy violations, data destruction, and service disruption, test only against accounts you own or are permitted to use, and give us reasonable time to fix an issue before disclosing it, we will not pursue legal action against you for your research.

Out of scope: denial-of-service testing, social engineering, physical attacks, and findings that require a compromised device.