Monstera Framework

I’m starting a short series of posts around something we’ve just begun building: an open-source SDK called Monstera. 🪴

These posts will stay focused on one thing only: why Monstera exists, how it works, and what you can realistically build with it.

That said, let's start with the why. The truth is, we simply kept running into the same problem.

Different products, different requirements, all needing wallet access, key management, and APIs that don’t leak secrets or turn into a maintenance nightmare. Every solution looked slightly different, but never different enough to justify rebuilding everything from scratch.

So instead of solving the same problem five times, we decided to build a single framework that could handle those requirements cleanly. And we’re open-sourcing it. 

That framework is Monstera.

At a high level, Monstera is an SDK for API-driven wallets with multiple accounts. One wallet can contain multiple accounts, and each account can be scoped to a specific product or use case. One user identity, multiple isolated blockchain addresses.

The important part is where the sensitive stuff lives.

If you’ve read my earlier posts on Oasis Sapphire, you already know the model: keys live inside a TEE-backed contract, processed privately, never exposed.

That same approach underpins Monstera.

Again, the point is that we literally cannot see the secrets, even if we wanted to.

We just started writing the SDK, and a lot will evolve. But that is also why I’m posting about it now, because this is the stage where feedback actually matters.

If you’re curious, skeptical, or already thinking about how you’d use something like this, I absolutely encourage you to reach out. Questions and criticism are welcome! 

In the next posts, I’ll go deeper into how the SDK is structured, what kinds of products it fits (and what it doesn’t), and the concrete usage patterns it enables.

This post is just laying the ground. The rest is the build.