Architecture
Openfort's smart contracts are open source. Moreover, Openfort is buit on public goods infrastructure like the ERC-4337 or ERC-6551 standards. We choose open source tools which are scalable and make them simple to use.
Openfort is not a 1-to-1 mapping of any wallet solution you've seen. While we offer many of the features that other solutions have, we go much further than anyone else because: (1) We're based on smart accounts not EOAs, and (2) we build the server stack so you don't have to worry about the reliability of the infrastructure.
Architecture#
Openfort consists of modules that allow you to plug-and-play the tools to achieve your success.
Our infrastructure orchestrates everything under the hood to make the development and maintenance easy. The 4 key components we take care of are:
- Smart accounts: We offer optimized and diverse set of smart accounts to fit your needs. Types of smart accounts.
- Signers: Signers define the custodianship of your user's accounts. At Openfort we're flexible and offer our own signer solution or support external signer providers.
- Bundlers/RPCs: We built a Meta Bundler Network to ensure reliable access to the blockchain. If one fails, another takes over.
- Paymasters: We built the most customizable paymasters to configure granular rate limits and policies for gas sponsoring, through either our API or dashboard.
Our goal at Openfort is to make all of smart accounts easy to use and invisible to the player. That doesn't mean you can't enjoy all the benefits of it. If you're a game dev veteran, you'll probably be familiar with the integrations we offer. If you're a blockchain dev veteran it means you'll probably be able to use every inch of features and benefits we offer. In either scenario Openfort helps you build you weekend hackathon or your ambitious AAA game.
Product Principles#
It is our goal to provide an architecture that any large-scale company would design for themselves, and then provide tooling around that architecture that is easy-to-use for indie-developers and small teams.
We use a series of principles to ensure that scalability and usability are never mutually exclusive:
Everything works in isolation#
Each system must work as a standalone tool with as few moving parts as possible. The litmus test for this is: "Can a user run this product with nothing but a Postgres database?"
Everything is integrated#
Openfort is composable. Even though every product works in isolation, each product on the platform needs to 10x the other products. For integration, each tool should expose an API and Webhooks.
Everything is extensible#
We're deliberate about adding a new tool, and prefer instead to extend an existing one. This is the opposite of many cloud providers whose product offering expands into niche use-cases. We provide primitives for developers, which allow them to achieve any goal. Less, but better.
Everything is portable#
To avoid lock-in, we make it easy to migrate in and out. Our cloud offering is compatible with our self-hosted product. We use existing standards to increase portability (like pg_dump and CSV files). If a new standard emerges which competes with a "Openfort" approach, we will deprecate the approach in favor of the standard. This forces us compete on experience. We aim to be the best Postgres hosting service.
Build for developers#
"Developers" are a specific profile of user: they are builders. When assessing impact as a function of effort, developers have a large efficiency due to the type of products and systems they can build. As the profile of a developer changes over time, Openfort will continue to evolve the product to fit this evolving profile.