Security
Fiber’s keys are split across security boundaries and clouds. Signing still requires explicit user authorization — Fiber cannot freelance with your funds.
Fiber’s security model follows the enclave-based wallet design pioneered by systems like Privy: keys are valuable, so they should not live as one happy blob on one server.
Key architecture
Your key material is sharded with Shamir’s Secret Sharing (SSS) and split across multiple security boundaries and clouds.
In practice, that means separate encrypted shares — including a share held by API infrastructure and a share held in an internet-restricted enclave. No single ordinary server compromise should be enough to reconstruct spending authority.
Exact operational topology can evolve. The invariant we care about does not: Fiber should not be able to move funds without you.
Authorization model
Signing a transaction requires explicit end-user authorization.
Fiber cannot:
- move funds on your behalf without that authorization
- invent a transfer you did not approve
- “helpfully” initiate actions outside the authorization path
If a flow needs a signature, you are in the loop. That is the difference between an app that manages UX around keys and a custodian that holds them.
What this buys you
- reduced single-point key exposure
- enclave isolation for sensitive share handling
- a product path where recovery can use familiar login methods without turning Fiber into an exchange-style custodian
What this does not buy you
- immunity from phishing your login methods
- protection from approving the wrong transaction
- a guarantee that every third-party protocol you use is safe
- freedom from device compromise
Non-custodial security shifts risk. It does not vaporize it. Protect access paths the same way you would protect any account that can move money.
For the product-facing version of these guarantees, see Non-custodial. For how wallets are created and recovered in the app path, see Wallet infrastructure.