When Openfort started a little more than a year ago, we were one of the first ones to build a compatible ERC4337 implementation of a smart account for web3 games. Our solution helped many get started onchain with much simpler transaction signing, gasless transactions, support for native game frameworks, etc.

To support developers in onboarding more people into their products, we're thrilled to share that Openfort is building a new account solution. Developers can now integrate an embedded, in-game, wallet. 

We like to call it **Embedded Smart Account**. (A blend of Smart Accounts + Embedded Wallets).

_In the coming weeks, we’ll start to roll out embedded smart accounts to customers. If you’re interested in early access, we’d love to talk with you._

## The crypto-enabled stack
We're observing widespread adoption of tools designed to streamline on-chain interactions, integrating various technologies to bridge the gap between the visibility and usability of blockchain.

We talk to developers every day, and while people are excited, we also see that making sense of the current crypto stack is harder than ever. Let us break it down with a very simple mental model, the crypto-enabled stack.

![Crypto-enabled-stack.svg](https://blog-cms.openfort.xyz/uploads/Group_504_71412174c3.svg)

At the high level, making onchain actions mainstream there are three layers: 
- The first layer is **authentication.** The person who is executing the onchain actions 
- The second layer is the **signer.** The how is authorizing/controlling the actions. 
- The third layer is the **smart account.** The where are those actions "recorded" and how do they affect the state. 

Most embedded wallets **only abstract the first two layers**, leaving users to deal with UX problems in the transaction flow like insufficient gas errors, frequent signature requests, or private key export.

An embedded smart account abstracts both layers with [ERC-4337 smart accounts](https://www.openfort.xyz/docs/guides/accounts/smart) to make the entire wallet experience invisible.

### The authentication layer
_The who makes the onchain actions_

Traditional blockchain systems often equate users directly with their wallet addresses, leading to a user experience that can be impersonal and intimidating for new adopters. Openfort challenges this by implementing a more nuanced, accessible approach to user authentication.

This layer allows users to log in using conventional methods such as email, social media accounts, or even existing wallet credentials, seamlessly integrating web3 with everyday web experiences. This approach ensures that users, irrespective of their familiarity with blockchain technology, can engage with blockchain-based applications more naturally and securely.

The [Openfort Auth architecture](https://www.openfort.xyz/docs/guides/auth/overview) allows you to combine existing auth providers tailored for games (e.g Unity Gaming Services) and connect them with multiple accounts. This helps you have richer data baout your users and manage those players more effectively. 

### The Signer Layer
_The how are onchain actions made_

The Signer Layer represents the mechanism through which users authorize blockchain transactions. Traditionally, this process has been cumbersome, requiring users to manage private keys and understand complex blockchain concepts. 

By decoupling the signer from the user's identity, Openfort enables a more flexible and secure approach to transaction authorization. This layer is crucial for maintaining the security and integrity of transactions while providing a user-friendly interface that abstracts away the complexities of key management.

In Openfort’s [embedded signer](https://www.openfort.xyz/docs/guides/accounts/signers/embedded-openfort-signer), the Signer Layer works seamlessly with the Auth Layer, ensuring that users can safely and easily authorize transactions without needing to understand the underlying mechanisms. Openfort let's you bring those signer via wallet connectors or simply generate a private key with our custom implementation.

### The (Smart) Account Layer
_The where are the onchain actions executed_

The Account Layer is where the on-chain activities and user assets reside. In conventional systems, this layer is typically merged with the signer, leading to a rigid structure that can be limiting and insecure. Openfort's approach, however, separates the user's account from their signing capabilities, offering enhanced flexibility and control.

This layer utilizes smart accounts, leveraging ERC-4337 standards, to create a more dynamic and user-friendly experience. Users benefit from features such as gasless transactions, automated batch transactions, and enhanced security measures, all while maintaining control over their assets.

Openfort’s [Smart Account Layer](https://www.openfort.xyz/docs/guides/accounts/smart) is designed to work smoothly with the Auth and Signer Layers, creating a cohesive system that enhances user experiences and security. This layer also works smoothly with signers like Metamask or Rainbow as they become the means of controlling the account. 

## Putting it all together

![Openfort_stack.svg](https://strapi-oube.onrender.com/uploads/Openfort_stack_925e4c7102.svg)

By integrating these three layers - Auth, Signer, and Account - Openfort provides a comprehensive solution that addresses the challenges and limitations of traditional blockchain systems. In the diagram above, you can see how Openfort can be used in various ways, depending on your architecture and target user base. 

Games have different needs than web-based applications. Different platforms, architectures and user bases. With Openfort you can plug and play various combinations and configure the setup beyond any wallet extension.

### The Road Ahead
Now that the crypto stack has a solid ground, the journey towards seamless account interoperability begins, demanding meticulous attention to security and developer impact across multiple applications. Interoperability unlocks deep benefits for users and developers alike, like:

- **Easier on-ramps**—no need to onramp assets again after doing it once.
- **Simple asset visibility**—enable devs to view assets across all apps used.
- **Secure asset composability**—enable users to act on their assets across apps.

Today, our current offerings include batched transactions to transfer assets to EOA wallets, and communication protocols like WalletConnect. The team is also exploring solutions like linking/unlinking signers and integrations with identity hubs to enable the next generation of connectivity. Stay tuned for more!

Discover the new Embedded Smart Account solution, offering seamless integration for developers and a magical onboarding experience for users with authentication and transaction flows.

Embedded-wallets.svg

Embedded Smart Accounts: Powering the Web3 Gaming Stack

## Overview
In this article, we will explore the concept of Recoverable Account and how it can be used using Openfort’s APIs. We will discuss the benefits of Recoverable Accounts, the design of Openfort Recovery, and what the future holds for this technology in the context of blockchain games and developers.

## Understanding Social Recoverable Accounts
Recoverable Accounts are a type of smart wallets that offer a method to recover lost access to a self-custodial account when not in possession of the seed phrases. It is Ethereum co-founder Vitalik Buterin's [preferred method](https://vitalik.eth.limo/general/2021/01/11/recovery.html) for securing a wallet.

Social Recoverable Accounts -also named social recovery- use smart contracts and Recovery Contacts (also known as Guardians) to add an additional layer of security. When a player loses access to their wallet (in this case, the private key controlling their Openfort account), they can reach out to their recovery contacts to sign a transaction to recover their wallet. 

Even though guardians can sign via direct onchain transfer, **with Openfort they also can leverage our API to avoid paying fees**; sending the signed message for them.
## Openfort Recovery Design

Openfort Recovery Design is inspired by the Social Recovery systems implemented by Argent. The owner of the wallet is always in full control, and a threshold is assigned for a minimum number of guardians to recover the wallet. 

![RECOVERY1.svg](https://blog-cms.openfort.xyz/uploads/RECOVERY_1_14825505d9.svg)

The owner can:
- Propose a new guardian.
- Cancel the proposal of a new guardian.
- Revoke a guardian.
- Cancel the revocation of a new guardian.
- Cancel the recovery mode.
- Transfer the ownership of the account (2 step process).

A guardian can:
- Start a recovery process.
- Lock and unlock the account for a period of time (`lockPeriod`).

Anyone can:
- When a guardian has been proposed for enough time (`securityPeriod`), confirm its proposal.
- When a guardian has been revoked for enough time (`securityPeriod`), confirm its revocation.
- When in recovery mode, submit the list of needed signatures (from half of the guardians) to complete the recovery of the account.

## Recovery Walkthrough

Given a player that has already connected their self-custodial wallet and Openfort has already deployed a smart wallet, we’re looking at an example where Openfort is by default the only guardian to recover the account. 

![RECOVERY2.svg](https://blog-cms.openfort.xyz/uploads/RECOVERY_2_2b90e665d7.svg)

This is just for demonstration purposes. In reality the players with self-custodial wallets have full control of their smart accounts and can decide who to add or remove as guardians. As a game developer you can suggest a friendly configuration where the game is one of the guardians to ease the recoverability process of the account. 

When "Start Recovery Process", this action calls the start recovery function in the contract, signaling the default Guardian (Openfort in this case) to initiate the recovery process.

Openfort (the guardian) has 2 days to complete the recovery process (gather all required signatures).Once signed, it approves the recovery process and the ownership of the account changes to the new address specified during the recovery initiation. 

In the event of the owner’s private key being found or the process being started by a malicious guardian, the owner can cancel the recovery process anytime before being completed.

### Trying out Openfort's Sample
For developers eager to dive into the code Openfort has made their contracts available in the [Openfort Contract Repository](https://github.com/openfort-xyz/openfort-contracts/tree/main/contracts/core) and the [sample](https://github.com/openfort-xyz/samples/tree/main/recoverable-accounts).

To get started with the sample:

- Clone the Sample Repository: This is the first step to accessing the sample code.
- Setting up the Environment: Before diving into the code, ensure you've set up the environment correctly. Create the `.env` file from the `.env.loca` example and populate it with the necessary information. All the required details can be fetched from the Openfort dashboard.
- Starting the Sample Application: Once everything is set up, execute `yarn` and then `yarn start` to get the sample application running.


## Wrapping up
Excited to use recoverable accounts in your game? Let's get started by looking at our [documentation](https://openfort.xyz/docs) and our [video walkthrough](https://www.youtube.com/watch?v=E8e1pklBbgw) for more.

If you have more questions/ideas/queries, join our Developer Discord and let us know there. Furthermore, you can follow us on Twitter for our updates as we keep shipping.


In this article, we will explore the concept of Recoverable Account and how it can be used using Openfort’s APIs. 

Group 385.svg

Technical Dive: Social Recoverable Accounts 

## Understating the ERC-6551
ERC-6551 is an Ethereum standard that allows ERC-721 tokens to have their own smart contract accounts, also known as Non-fungible Token Bound Accounts (TBA). This means that NFTs can now own digital assets and interact with various applications. The system doesn't require any changes to existing ERC-721 NFTs.

The ERC-6551 mechanism consists of three key parts: a registry, an account interface, and a minimal proxy implementation. The registry is permissionless and immutable, and it deploys a smart contract account for an NFT. 

The account interface sets the standard process, rules, and limits for account creation. ERC-1167 minimal proxy contracts are used in deploying accounts, making account implementations much easier and cheaper.

ERC-6551 is an improvement over ERC-721 because it overcomes some of the limitations of ERC-721. ERC-721 tokens are static and can only show static data or information. They are also not composable and cannot interact with other on-chain assets or contracts independently. ERC-6551, on the other hand, maintains backwards compatibility with previously minted ERC-721 NFTs and deploys smart contract accounts for NFTs via a permissionless registry. 

Check the [technical ERC-6551 proposal](https://eips.ethereum.org/EIPS/eip-6551) as well as the [non-technical write up](https://medium.com/future-primitive/tldr-nfts-have-their-own-wallets-try-it-here-http-tokenbound-org-6fac135a1f9d) from the authors.

## The Gaming Use Case for ERC6551
### Before ERC6551
In a traditional gaming application, players could own their characters as ERC-721 NFTs. However, all related assets that they collected within the game would also sit as separate tokens in the owner's wallet. This could be inconvenient for players, as they would have to keep track of multiple tokens and manually transfer them between their character and their wallet. 

Additionally, it would be difficult for game developers to create in-game UIs that allowed players to easily manage their assets.
### With ERC6551
ERC6551 allows game developers to create "inventories" for players. This means that all of a player's game-related assets can be automatically transferred into their character's wallet. This makes for a better user experience, as players no longer have to keep track of multiple tokens. 

Additionally, it allows game developers to create in-game UIs that are much more user-friendly.

For example, imagine a game where players can collect different weapons and armor. With ERC6551, players could simply equip their weapons and armor directly from their character's inventory. This would make the game more immersive and engaging, as players would no longer have to switch between their wallet and the game UI to manage their assets.
### Benefits of ERC6551 for gaming
ERC6551 offers a number of benefits for gaming applications, including:
- Improved user experience: ERC6551 makes it easier for players to manage their game-related assets.  You can now create a smart account via a minted or airdropped NFT
- Enhanced gameplay: ERC6551 can be used to create more immersive and engaging gameplay experiences. For example, players could use ERC6551 to equip their characters with different weapons and armor, or to purchase items from in-game shops.
- Increased security: ERC6551 can help to improve the security of game assets. This is because token-bound accounts are more secure than traditional wallets (EOAs).
Overall, ERC6551 is a valuable tool for gaming applications. It can be used to improve the user experience, enhance gameplay, and increase security.

## Challenges and Limitations of ERC-6551
While ERC-6551 brings a new layer of functionality to NFTs, it also introduces a set of challenges and limitations:
1. Complex NFT User Experience: ERC-6551 adds additional features and capabilities to NFTs, which also brings a new layer of complexity. Users need to have a higher level of understanding to fully utilize these advancements. 
2. Implementation Complexity: Implementing the ERC-6551 standard into existing ERC-721 tokens requires creating and configuring a new smart contract. This process can be complex and requires technical expertise. Additionally, it may involve paying for the services of a blockchain developer. 

At Openfort we want to overcome these challenges by smoothing and standardizing the interactions directly via APIs, offering an already build implementation catered towards web3 gaming. 

Let’s see how we’ve done this. 

## Combining the ERC6551 and ERC4337
The creation of smart wallets within in-game assets represents a leap forward into the evolution of the player experience in the game. No longer the standard unlocks new utility for NFTs but also allows for composability with other standards, in this case the famous ERC4337 (Account Abstraction).

At Openfort, we looked at the different ways we can combine them together to untap novel use cases while enjoying an optimal player experience. Here are the findings and thoughts as well as the path to follow if you’re looking to implement and offer “wallet-less” experience to your players. 

### Option 1: NFT is owned by an Openfort 4337 account

![Group 348.svg](https://blog-cms.openfort.xyz/uploads/Group_348_05b11271b9.svg)

The first option drops an ERC721 into a newly created smart wallet with Openfort. The ERC721 is 6551 compatible allowing it to store the different in-game assets, while the interactions happen at the Openfort level (4337 compatible) ensuring there is a smooth player experience -gasless txs and zero txs prompts. 

Nevertheless this option has constraints because the actions need to be encoded before sent and get the new owner form the logs via the implementation ABI.
All in all:
- (+) It uses session keys, which can enable a popup-less experience for users.

- (-) You deploy two smart wallets making it more costly to interact.

- (-) While the implementation works with Openfort it is cumbersome to use via the API.

See the implementation in our [Github repository](https://github.com/openfort-xyz/samples/tree/main/ERC6551-token-bound-accounts#option-1).

### Option 2: NFT is owned by an EOA and EIP6551 account is EIP4337 compliant

![Group 349.svg](https://blog-cms.openfort.xyz/uploads/Group_349_48e9e86864.svg)

This option reduced the complexity of the implementation, because now you don’t need to deploy two smart contract wallets but rather make the TBA compatible with ERC4337 directly while the EOA has the ERC721 ownership. 

The main disadvantage here is that you need to be careful the way you apply session keys within the game in the case an NFT owner decides to transact their token. 

All in all:
- (+) It reduces the complexity of the solution while also lowering the gas spending (you only create one smart wallet instead of two).
- (~) You can still benefit from session keys in your game but need to make sure to revoke them if the NFT is transferred to a new owner.

See the implementation in our [Github repository](https://github.com/openfort-xyz/samples/tree/main/ERC6551-token-bound-accounts#option-2).
## How can I use Token Bound Accounts with Account Abstraction?

Openfort’s 4337 account and a 6551 account are quite similar. The main difference is that the ownership of the 4337 account is defined by who has the signer and the ownership of the 6551 account is defined by who has the NFT.

Both have therefore the option of transferring ownership. 
- For the 6551 account, approve and transfer the ownership of the NFT.
- For the 4337 account, [request and accept](https://www.openfort.xyz/docs/guides/accounts/smart/transfer-ownership) ownership of the account.

While both options are doable we recommend following the second implementation better. It’s natively supported [via our endpoints](https://www.openfort.xyz/docs/reference/api/create-an-account-object) and ensures a smooth player experience as long as we implement the revocation of session keys is needed given a change of ownership of the NFT (we can help with that). You can check the ERC6551 smart contract [here](https://github.com/openfort-xyz/openfort-contracts/blob/main/contracts/core/erc6551/ERC6551OpenfortAccount.sol).


If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.

Learn the in's and out's of the ERC6551 with Openfort's smart accounts and learn how to make them both together for your game.

Group 344 (2).svg

Technical Dive: Combining Token Bound Account (TBA) with Account Abstraction (AA)

In the burgeoning domain of Web3, an innovative concept has emerged—session keys. These keys are akin to the well-known JSON Web Tokens (JWTs) but come with a twist, facilitating decentralized user verification in contrast to the centralized verification in traditional systems. 

## Session Keys in Action
Session keys are cryptographic keys used to establish a secure connection between a player's device, the game server and the user's web3 account. They act as temporary, specific-use keys for Web3, offering a much-needed solution. Session keys are similar to JWTs in the Web2 realm but come with more versatility, essentially serving as "programmable JWTs."

They are generated inside the player's device and are used to authenticate requests from the player. Session keys are short-lived and typically expire after a certain period of inactivity or when the player logs out. See an example that works works both on [dekstop and mobile](https://sample-lit-protocol-nextjs.vercel.app/).

These keys permit users to interact with a game based on predefined conditions, such as duration, token spending limits, post frequency, or other functions specific to the smart contract.

Incorporating session keys into web3 games offers several advantages:

- **Security:** Session Keys are scoped, and smart contracts can dictate which instructions a specific session key can accept. By storing expiry and access information at the contract level, session keys become less vulnerable to security risks. Additionally, layered security further protects user assets.
- **User Experience (UX):** Session keys significantly improve crypto UX by eliminating the need for constant wallet popups while a user performs actions within a dApp for a specified duration.
- **Interoperability:** Session keys function at the contract level, allowing users to continue using their preferred browser wallets while interacting with a dApp that supplies a session key in the background. This maintains app interoperability and enhances UX.

## Gaming and Session Keys

One of the most promising applications of session keys lies in the gaming domain. Given that many modern games involve in-game purchases, trades, and other transactions, session keys can drastically improve the gaming experience.

By allowing users to pre-authorize a range of transactions, games become smoother and more engaging. Players no longer need to pause their game every time they make a transaction, leading to uninterrupted gameplay.

![How session keys work-1.svg](https://blog-cms.openfort.xyz/uploads/session_key_walkthrough_ff19816585.svg)

Let's explore the four major steps involved in this process.

- When players log in, they should generate a session key on their device and send it to your game server. The sensitive part of the session key (the session private key) is always securely stored on the player's device and is not disclosed.
- The player includes the public part of the session key in subsequent requests from the player's device to the game server for authentication. Such requests should be digitally signed by the secret part of the session key.
- On the game server, validate the session key and the signature before processing the request. Periodically refresh the session key during the player's session to maintain security.
- Players can invalidate the session key whenever they want, e.g.: after logging out or after a certain period of inactivity.

## The Bright Side of Session Keys

![SessionKeysExample (1).svg](https://blog-cms.openfort.xyz/uploads/Session_Keys_Example_1_e31e7c28fb.svg)

Session keys can potentially redefine user interactions with games, offering a seamless experience that's unprecedented in the Web3 domain:

- **Bypassing Confirmations:** No more disruptions! Session keys can help bypass continuous transaction confirmations, especially beneficial in applications where frequent small transactions are made.
- **Offline Operations:** Session keys enable users to execute transactions even when offline. For example, a user can participate in an NFT drop without having to be online at the time of the drop.

## Setting New UX Standards

The introduction and adoption of session keys are not just about improving transactions; they are setting a new standard for user experience in the Web3 domain. By offering features like offline transactions and bypassed confirmations, session keys are paving the way for more intuitive and user-friendly games.

Excited to use Session Keys in your game? Let's get started by looking at our [Documentation](https://www.openfort.xyz/docs/guides/accounts/smart/session-keys) and our [Youtube video](https://www.youtube.com/watch?v=rh2E02PATlU) for more. 

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.


Session keys are cryptographic keys used to establish a secure connection between a player's device, the game server and the user's web3 account.

Group 329.svg

Technical Dive: The Power of Session Keys

## Overview

One innovation in the blockchain space is ERC4337, a standard for account abstraction on the EVM ecosystem. In this document, we will delve into the Paymaster component of ERC4337 and its functionality within the framework.

## Understanding Gasless Transactions

Paymasters, or "gas sponsors," in ERC4337 are smart contracts that enable transaction sponsorship through third-party-designed mechanisms. Often referred to as [gasless transactions](https://www.openfort.xyz/docs/guides/transaction-cloud/policies), paymasters eliminate the need for users to hold a blockchain's native token for transaction fees. This creates opportunities for transaction fee sponsorship or accepting network fees in ERC20 tokens.

Gasless transactions empower contracts to pay on users' behalf under any given conditions, unlocking a new realm of possibilities for transaction sponsorship mechanisms on EVM blockchains.

![PaymasterArchitecture-min.png](https://blog-cms.openfort.xyz/uploads/Paymaster_Architecture_min_6f6cfb813d.png)

Let's explore the four major steps involved in this process.

- **Step 1: Welcoming UserOperations**

Openfort, functioning as the primary orchestrator, receives a set of UserOperations. This phase represents the initiation of the ERC-4337 transaction flow.

- **Step 2: Meeting the Paymaster Contract**

Openfort communicates with the Paymaster contract, contingent on the inclusion of the Paymaster within the UserOperation. The Paymaster contract is responsible for potentially covering transaction fees for Contract Accounts. Openfort then verifies if the Paymaster has a sufficient deposit or if the associated Contract Account possesses the required gas fees.

- **Step 3: Custom Fee Logic in Action**

If a Paymaster is involved, it can apply its proprietary fee logic. This allows for a flexible and tailored transaction fee structure based on the specific Paymaster's criteria.

- **Step 4: Signature Validation and Execution Initiation**

At this juncture, Openfort collaborates with the Contract Account and, when applicable, the Paymaster to authenticate the signatures present in the UserOperation. The Contract Account serves as the interface between the user and Openfort, ensuring streamlined transactional communication. Upon successful signature validation, Openfort conveys the necessary data from the UserOperation to the Contract Account, initiating the transaction execution.

## The Power of Sponsoring Transactions

Paymasters can generally be categorized into two types: those with off-chain logic and those with on-chain logic, or simply put those that abstract the payment of network tokens and those that abstract the payment of network tokens with an alternative ERC-20 token. 

### Standard Paymasters: Sponsoring transaction fees

![PaymasterArchitecture (1)-min.png](https://blog-cms.openfort.xyz/uploads/Paymaster_Architecture_1_min_568b3ecc56.png)

Currently, to transact on blockchains you'll need the netork native token to pay for gas (i.e. Polygon you need POL). Standard Paymasters offer an alternative approach to this requirement.

Openfort verifies the logic of the paymaster, determines if the paymaster should cover the transaction costs, and signs offchain to pay the [gas costs](https://www.openfort.xyz/docs/guides/transaction-cloud/policies/sponsor). These costs are directly extracted from the paymaster (smart contract pool) filled with network tokens, similar to the operation of relayers with meta-transactions. 

### ERC20 Paymasters: Paying with ERC-20 tokens

![PaymasterArchitecture (2)-min.png](https://blog-cms.openfort.xyz/uploads/Paymaster_Architecture_2_min_f815f9fd48.png)

ERC20 Paymasters present another innovative solution. In this scenario, the Paymaster can pay for gas fees with:
- A [fixed amount of ERC20](https://www.openfort.xyz/docs/guides/transaction-cloud/policies/fixed) conversion. This implies that the fixed ERC20 amount will pay the amount of gas fees. This brings consistency to the end user experience but also exposes the game to win/lose ERC20 if the value is above/below the gas fee.
- A [dynamic amount of ERC20](https://www.openfort.xyz/docs/guides/transaction-cloud/policies/dynamic) conversion. This let's you cover the gas fees based on the conversion rate of your ERC20. This could be your preferred conversion rate or simply the conversion rate in a DEX (we'll use an Oracle for that). 

This approach allows for the integration of a Paymaster with an existing ERC-20 token, such as USDC or your own game token.

**Extra notes:**
- You can use the ERC20 from a players wallets to also subsidize for the network gas fees. It collects digital currencies from the user, converts them into native tokens based on the prevailing exchange rate, and pays for gas fees on behalf of the user.
- You can create policy rules to be more granular on the sponsorhip details, based on contracts. functions and limits like gas cot or timme. 
- Get your gas reports directly on the dashboard on monthly basis and pay directly with Fiat without holding tokens/crypto yourself.


If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.

One innovation in the blockchain space is EIP-4337, a standard for account abstraction on the EVM ecosystem. In this document, we will delve into the Paymaster component of EIP-4337 and its functionality within the framework.

Group 328 (1).svg

Technical Dive: Gas Sponsorship via Paymasters

## Openfort's Architecture
There's no one right way to build with Openfort. Whether you want high-touch, high control, or more of a set-it-and-forget it approach, our SDKs and API have what you need. This post is rather short but sharing the architecture representation of what we've built. 

### Simplified Overview of Openfort
Openfort provides SDKs and APIs for the most popular smart wallet features, including transaction relay and gas sponsoring, transaction batching, session keys, social recovery, and more.

![Group 295-min.png](https://blog-cms.openfort.xyz/uploads/Group_295_min_3ec4bfb35f.png)

### Frontend Headless SDK
A “bring-your-own-UI” that comes with extensive auth flexibility.
![FrontendHeadlessSDK.excalidraw.svg](https://blog-cms.openfort.xyz/uploads/Frontend_Headless_SDK_excalidraw_0539af0ca5.svg)

### Backend API & SDKs
For maximum flexibility, our backend API lets you tailor the flow to your exact needs.
![BackedAPISDK.excalidraw.svg](https://blog-cms.openfort.xyz/uploads/Backed_APISDK_excalidraw_271cfc56e5.svg)

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and share your ideas. Stay updated by following us on [Twitter](https://twitter.com/openfortxyz).

Learn about the Openfort's architecture with our diagrams and see how it can help you get your game to the next level,

coverEcosystem

Technical Dive: Openfort's Architecture

**“Increase the number of successful blockchain powered games in the world”**

We do this by helping developers be better at their gaming projects.

## TL;DR
Openfort's philosophy centers on providing frictionless experiences for users and developers, promoting open and free solutions without lock-in, and nurturing a community-driven approach. Openfort offers the flexibility to self-host or opt for a pro version, aligning with open-source principles.

## First Principle: Enhancing the user and developer experience
Openfort's philosophy is to pursue seamless experiences for users and developers. Openfort provides easy-to-use tools and APIs, enabling developers to focus on crafting engaging applications without managing complex infrastructure. Users should be able to interact with applications effortlessly, irrespective of the technology involved.

We aim to remove obstacles for developers by providing standardized APIs and SDKs. These tasks include blockchain interactions, wallet management, and transactions. This approach empowers developers to concentrate on producing exceptional games and applications, free from concerns about underlying systems.

## Second Principle: Promoting Open Solutions and Avoiding Lock-In
Embracing an open, free, and iterative approach is at the core of Openfort's philosophy. Openfort supports self-hosting and pro versions to cater to user preferences and requirements. This approach motivates users to take ownership of their projects and adapt the codebase as needed. This environment enables developers to experiment, learn, and grow without constraints.

## Third Principle: Fostering a Community-Driven Approach
A vibrant developer community is central to Openfort's philosophy. It emphasizes the importance of collaboration, support, and resource-sharing among developers. The platform's goal is to establish a thriving ecosystem where developers can contribute to the platform's growth and improvement. This will shape the project's future based on their needs and feedback.

As part of Openfort's commitment to open source, developers are actively invited to share their knowledge, collaborate on projects, and provide feedback in order to enhance the platform. Its supportive and inclusive environment empowers its users to drive innovation and develop cutting-edge applications.

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.

Openfort offers the flexibility to self-host or opt for a pro version, aligning with open-source principles.

CoverPhilosophy

Embracing Openness: Openfort's Philosophy

## Overview
Gaming, a realm that has been a part of our culture since the advent of Pong in the 1970s, has seen a significant transformation over the years. Today, we are witnessing the rise of broader ecosystems involving multiple games, publishers, and organizational structures. This evolution is not just about the games themselves, but also about how players interact with them and each other.

At Openfort, we've been working on a framework that reimagines the gaming ecosystem. This framework offers key features such as single sign-on, interoperability, achievement tracking, enhanced permissioning flows, and ecosystem control. We believe this approach will benefit players, developers, and various gaming ecosystems by providing seamless integration, cross-game compatibility, and frictionless onboarding.

## The Openfort Framework: A New Approach to Gaming

Our framework introduces several features that are designed to enhance the gaming experience:

- Single Sign-On Across Games: One ecosystem-level profile serves as an SSO for any game within the ecosystem.
- Interoperability: Secure and standardized cross-game compatibility for in-game currencies, assets, and more via a player's managed or connected external wallet.
- Achievement Tracking: Ecosystem-level support for soul-bound tokens, achievements, XP, rank, and more.
- Enhanced Permissioning Flows: OAuth-like authorization for asset control across ecosystem games.
- Ecosystem Control & Security: Explicit approval for games requesting access to profile assets and authentication.
## Creating a Seamless Experience for All

Our framework is designed to work seamlessly for everyone involved:

1. Players: APIs work with ecosystem profiles and standard game-level player accounts, requiring no additional implementation.
2. Developers: No extra logic is needed to make frictionless API calls on behalf of players using ecosystem profiles. The same accessToken and decryptWalletKey are provided for seamless integration with existing API usage.
## Potential Use Cases

Our framework can be applied to a variety of scenarios:

- Gaming DAOs with Partnered Games
- Game Publishers with Multiple Games
- Game Marketplaces
- Gaming Guilds and Gaming Communities

![EcosystemOverview](https://blog-cms.openfort.xyz/uploads/Ecosystem_Overview_f652153a6d.svg)

## Benefits of Gaming Ecosystems

The Openfort framework offers a multitude of benefits that enhance the gaming experience for both players and developers:

- **Customization and Branding**: Partners can create their platform's UI/UX flow for ecosystem integration with fully documented APIs or opt for the existing UI/UX flow. Customization options include brand colors, logos, icons, background images, domain/subdomain attachment, and more.

- **Security and Permissioned Asset Access:** The ecosystem auth flow offers a clear and user-friendly method for games to request permission to access a player's ecosystem profile wallet assets. This approach mirrors conventional OAuth permissioning flows and mitigates the risk of compromised assets.

- **Effortless Integration for New and Existing Games:** The ecosystem product seamlessly integrates with new or existing games by simply implementing a "Sign In With..." button within the game. This approach requires no additional logic or development overhead, ensuring a seamless onboarding experience for both players and developers.

- **Keep Your Gaming Progress Secure and Uninterrupted:** With your Game ID, switching, losing, or reinstalling devices won't disrupt your gaming progress. Your account remains secure and accessible, allowing you to effortlessly pick up right where you left off.

- **Simplify Your Gaming Experience:** Imagine a unified gaming experience where you can seamlessly connect all your games to a single ID. By creating an ID, you'll enjoy a streamlined gaming experience across our entire ecosystem.

- **Play, Connect, and Foster a Vibrant Community:** Connecting with fellow gamers is an integral part of the gaming experience. With Game ID, you can find and connect with other players and friends. The friends you make in one game will be visible in other games they play, fostering a vibrant and connected community.

- **Take Your Game Progress To The Next Level:** Your Game ID holds the key to unlocking our marketplace, where you will effortlessly be able to trade, buy, and sell assets from all games within the ecosystem. Managing your virtual assets becomes a seamless and enjoyable part of your gaming journey.

## Looking forward

Excited to use Session Keys in your game? Let's get started by looking at our [documentation](https://www.openfort.xyz/docs/guides/resources/ecosystem) and our [Youtube video](https://www.youtube.com/watch?v=s8wMDpTTzJE) for more. 

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) let us know there and follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.

A standardized framework for game ecosystems offers key features such as single sign-on, interoperability, achievement tracking, enhanced permissioning flows, and ecosystem control. 

Openfort blog

Embedded Smart Accounts: Powering the Web3 Gaming Stack

Embedded Smart Accounts: Powering the Web3 Gaming Stack

Technical Dive: Social Recoverable Accounts

Technical Dive: Combining Token Bound Account (TBA) with Account Abstraction (AA)

Technical Dive: The Power of Session Keys

Technical Dive: Gas Sponsorship via Paymasters

Technical Dive: Openfort's Architecture

Embracing Openness: Openfort's Philosophy

Technical Dive: Create Your Gaming Ecosystem