Private keys
MONSTERAProtected inside Sapphire's confidential environment.
TYPICAL EMBEDDED WALLETStored on a device or managed by a wallet provider.
MONSTERA · OASIS SAPPHIRE
A world taking root.
Preparing your jungle journey…
THE MONSTERA PROTOCOL
Rooted in privacy.Free to grow.
Portable wallet infrastructure for your applications. Users authenticate to the same wallet across integrated apps, while key storage and signing stay inside Oasis Sapphire.
NO-STATE WALLET INFRASTRUCTUREBUILT ON OASIS SAPPHIRE
01 / Beneath the canopy · Oasis Sapphire design
A living
architecture.
One confidential foundation. Three distinct responsibilities. A wallet that can grow beyond any single application.
Follow the roots ↓- 01 — THE ENTRANCE
Authenticate.
The authenticator verifies the user's proof for the exact operation. Your product chooses the experience.
- 02 — THE ROOT
Authorize.
The vault enforces the wallet's access boundary. A relayer can submit the request without controlling the wallet.
- 03 — THE CANOPY
Sign confidentially.
Key state and signing stay inside Oasis Sapphire. Your application receives a signature, without taking custody of the keys.
THE ROOT SYSTEMWhere does authorization happen?
The authenticator verifies the proof and the vault enforces access. The application and transaction sponsor do not replace that authorization boundary.
Read the technical guide02 / The open clearing · Why Monstera
Your app. Their wallet.
Give users one wallet across your apps without storing their private keys or running a custody system.
| Capability | Typical embedded wallet | Monstera |
|---|---|---|
| Private keys | Stored on a device or managed by a wallet provider. | Protected inside Sapphire's confidential environment. |
| Your backend | May help manage wallets, keys, or signing. | Never holds or controls user keys. |
| Across apps | Users may need to reconnect, install, or import a wallet. | Users access the same wallet by authenticating. |
| User experience | The wallet often feels separate from the app. | The wallet experience is built directly into your app. |
Your backend
MONSTERANever holds or controls user keys.
TYPICAL EMBEDDED WALLETMay help manage wallets, keys, or signing.
Across apps
MONSTERAUsers access the same wallet by authenticating.
TYPICAL EMBEDDED WALLETUsers may need to reconnect, install, or import a wallet.
User experience
MONSTERAThe wallet experience is built directly into your app.
TYPICAL EMBEDDED WALLETThe wallet often feels separate from the app.
Monstera uses Oasis Sapphire and requires gas for onchain actions.
OWNERSHIPWhat does no-state mean?
The browser and application backend do not persist wallet private keys. Wallet state still exists in the confidential runtime; no-state describes the application integration.
Read the technical guide03 / New growth · PayMyEmail
An email. A wallet.
A whole new branch.
PayMyEmail
A separate service built on Monstera, with an email-based wallet and a browser extension. Familiar access for people. Confidential wallet infrastructure underneath.
The extension connects to dapps, resolves email recipients, and requests wallet signatures through Monstera.
NEW GROWTHHow does PayMyEmail use Monstera?
PayMyEmail is a separate service and extension built on the protocol. It adds an email-based experience while requesting signatures through Monstera.
Read the technical guide04 / The sheltered grove · Authentication
Access, on their terms.
Authenticators implement the same verification contract while retaining their own proof semantics. Integrations can support the wallet's chosen access model without storing its keys or recreating its account.
Password
Familiar onboarding for demos and prototypes
Wallet signature
Fresh EIP-712 approval from trusted addresses
Dual factor
Password-minute signature plus guardian
Password or wallet
Consumer-friendly recovery and access
API key session
Scoped, short-lived automation tokens
Multi router
Human and machine access on one vault
IAuthenticator.verify
Identity is not enough. The proof must authorize the exact operation being executed.
Understand the trust boundary.
Confidential execution relies on Oasis Sapphire. Your authenticator defines who can act; proof handling, session scope, recovery, and sponsor secrets still need careful integration.
Read the security assumptionsACCESSHow do scoped sessions behave?
A session token can authorize permitted operations until its expiration. Use narrow scopes and short lifetimes, and preserve a recovery path.
Read the technical guide05 / A place to build
Build your first wallet.
Start at the application layer.
Use the published TypeScript SDK to create wallets and request authorized signatures. Key state stays in Sapphire.
import { Monstera } from "@monstera_protocol/sdk";
const leaf = Monstera.connect({
mainnet: false,
signer: sponsorSigner,
checkVersion: false,
});Illustrative integration guide. No wallet is connected and no transaction is sent.
SDK quickstartView a wallet creation and signing example
create-wallet.ts
import { Monstera } from "@monstera_protocol/sdk";
const leaf = Monstera.connect({
mainnet: false,
signer: sponsorSigner, // Pays gas; cannot bypass wallet authentication.
checkVersion: false,
});
const created = await leaf.createWalletForUsername({
username: "fern-labs",
authenticatorAddr,
authConfig,
});
// Protected calls use a proof for the exact KeyVault action.
const signature = await leaf.signMessage({
keyVaultAddr: created.keyVault,
index: 0,
message,
authProof,
});DEVELOPER FIELD NOTESWhat belongs on the server?
Keep sponsor credentials and service secrets out of browser bundles. The sponsor submits transactions and pays gas; user authorization is still required.
Read the technical guideDig into the system
Put the wallet in your product—not its keys.
Integrate one portable wallet surface, choose how users authenticate, and keep custody outside your application infrastructure.
YOUR NEXT BRANCHReady to build a first integration?
Start on the test network, choose an authenticator, and follow the wallet creation guide before integrating protected signing.
Read the technical guide