## 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 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.ca/general/2021/01/11/recovery.html) for securing a wallet.

Recoverable Accounts -also named Social Recovery Accounts- 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/recoverable) and the sample is [here](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]() 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: 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/transfer-account-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/api/accounts#create-an-account) 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/tree/main/contracts/core/eip6551).


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)

## Overview
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 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.

These keys permit users to interact with an app based on predefined conditions, such as duration, token spending limits, post frequency, or other app-specific functions.

## Understanding Session Keys
Apps can incorporate a layered security model that grants tiered access to session keys, ensuring the safety of a user's funds and assets, and preventing unauthorized access via session keys.

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.

![How session keys work-1.svg](https://blog-cms.openfort.xyz/uploads/How_session_keys_work_1_aa70263ef3.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 (session private key) is always securely stored on the player's device and should never be disclosed.
- The player should include 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.

### Use Cases for Session Keys

Session Keys enable a plethora of use cases, allowing developers to create web2-style user flows while harnessing the power of crypto and its native capabilities.

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

Some potential use cases include:

- User-friendly social media apps without interruptions.
- Rearranging assets within a wallet/inventory without having to confirm each time you make a change, just when you have completed their arrangement.
- Seamless gaming experiences with in-app NFTs.
- User friendly and uninterrupted playing of games.
- Layered security models for all crypto apps.

### Wrapping up

Excited to use Session Keys in your game? Let's get started by looking at our [Documentation](https://www.openfort.xyz/docs/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. They are generated inside the player's device and are used to authenticate requests from the player.

Group 329.svg

Technical Dive: Gaming Session Keys

## Overview

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.

>NEW: Get your gas reports directly on the dashboard on monthly basis and pay directly with Fiat without holding tokens/crypto yourself.

## Understanding Gas Sponsorship: The Paymaster

Paymasters, or "gas sponsors," in EIP-4337 are smart contracts that enable transaction sponsorship through third-party-designed mechanisms. Often referred to as gasless transactions, 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.

The Gas Sponsorship concept in EIP-4337 empowers 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**

Our journey begins when Openfort, our trusty guide, receives a bundled batch of UserOperations. Think of Openfort as the central coordinator, expertly managing these UserOperations within the bustling world of ERC-4337 transaction flow.

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

Next, Openfort interacts with a special character in our story - the Paymaster contract. This interaction only happens if the UserOperation invites the Paymaster to the party. Remember, Paymasters are the generous souls who can sponsor transaction fees for Contract Accounts. At this stage, Openfort checks if the Paymaster has enough deposit or if the Contract Account is loaded enough to cover gas fees.

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

Now, if a Paymaster is part of the journey, it can implement its custom fee logic during execution. This step is like the Paymaster showing off its unique skills, adding flexibility and customization to our adventure.

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

Finally, we reach the climax of our journey. Openfort calls on the Contract Account and, if necessary, the Paymaster, to validate the signatures in the UserOperation. Contract Accounts are like the user's personal assistants, seamlessly interacting with Openfort to facilitate transaction execution. Once the signatures get a thumbs-up, Openfort passes the relevant data from each UserOperation to the Contract Account, kickstarting the execution process.

## 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 the Ethereum or Polygon blockchain, users must acquire ETH or MATIC, respectively, to cover gas fees. Off-Chain Paymasters offer an alternative approach to this requirement.

In this model, users send their transactions to a third-party entity, Openfort. Openfort verifies the logic of the paymaster, determines if the paymaster should cover the transaction costs, and signs off-chain to pay the gas costs. These costs are directly extracted from a smart contract pool filled with network tokens, similar to the operation of relayers. An invoice for the gas fees is subsequently issued on a monthly basis.

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

![PaymasterArchitecture (2)-min.png](https://blog-cms.openfort.xyz/uploads/Paymaster_Architecture_2_min_f815f9fd48.png)
_Can I pay for gas fees with the game token?_ YES!

On-Chain Paymasters present another innovative solution. In this scenario, the Paymaster contract functions as an intermediary currency conversion service. 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.

This approach allows for the integration of a Paymaster with an existing ERC-20 token, such as USDC. However, it necessitates the use of an external source to determine token price and requires verification that the Paymaster contract has the necessary approvals to charge the user for the specified token.

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 Gmaing 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/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. 

📜 Blog