Session Cards

Outline:

A history about why crypto UX is not improving (pains about gaming and defi) What is Account Abstraction (short) What is Session Keys Architecture How it’s made Future Work

Why is Crypto UX Still a Pain?

Email, iCloud, Twitter, and many more... The Internet is only about identities, but in the web2 world, the identities are provided by trusted centralized providers. We need to make crypto trustless and user-owned, which is one of the reasons why we have hard-coded validity rules on blockchains.

If you want to initiate a transaction on Ethereum than you should; have a valid nonce have enough ETH for gas have a valid ECSDA signature and many more.

And this is why crypto UX is still a pain and wallets are still visible. Let’s give some examples that these validity rules limit us.

Order Book based DEX: Users must submit a transaction for each operation. You want to spend your USDC on Ether? Okay, sign this message! Have you reconsidered? Okay, sign this message! You'd like to sell your Ether. Okay, sign this message!.. Each time you express your operation, you have to use your wallet, and yes, the wallet is visible and you are aware that you are doing so! (We're working on this to solve it!)

NFT Based Game: Assume you're playing an NFT-based card game, and each move you make requires you to sign a message from your wallet. You wish to fight with your second card? Okay, sign this message!... We require a transaction for each move, as well as the native token to pay the costs. This is one of the biggest barriers for web3 games. (We are also working on this!)

Assume you've registered a Twitter account using your email address, and each of your postings requires a signature from your email. Twitter's UX would be terrible if the architecture was developed in this manner. While using the software, your identity (email) is invisible. Crypto wallets should also be invisible. To make crypto wallets invisible, we need a way to make wallets smart: Account Abstraction.

What is Account Abstraction

In normal Ethereum Transactions you can’t initiate it if you don't ensure you don't match with validity rules. Account Abstraction allows you to program the validity rules of your account with arbitrary logics. This sounds easy but in fact it was not. It took too many years to be live on Ethereum. After PBS (proposer and builder separation) and many innovations AA became real. Let’s take a look at what AA brings us and its use cases.

Using different algorithms to prove the identity: This allows wallet builders to use different curves as a signing method and can improve the onboarding process Paying gas fees with different tokens: Paymaster technology allows developers to build Smart Wallets that users don't need to keep native tokens to access the blockchain. Batch Transaction: You can make two transactions together (such as transferfrom and approve) since you can call arbitrary calldata with “executeuserop”. Session Keys: A way to change how users engage with dapps.

Session Keys

In the web2 world, session keys are like temporary passwords used during a conversation between two devices (like your computer and a server). They're created at the start of the conversation, used to keep the information shared secure, and then thrown away after the conversation ends. So, even if a hacker somehow finds out this password, they can't use it to listen in on future conversations because a new, different password (or session key) is created each time.

As in the web2 world, we define session keys as a framework that has the potential to change how users engage with dApps. The goal of session keys is to allow users to set pre-approvals for a specific time in a variety of scenarios.

When we use session keys: As a user perspective: Users are signing with their wallet only one time. After that users are sending a request to dApp the builder to sign their messages on their behalf. So users are just “signing” with their identity and starting to play with the dApp. As a dApp builder perspective: dApp builders are responsible for preparing and sending the transactions to blockchain and serving the front end. dApp builders should create a node-like thing to sign for users’ behalf. How it’s made?

We have three parts for our project: A smart account contract powered by Biconomy and Safe, a smart contract for NFT based game and a front end for the game.

Smart Account Contract and its components:

Our main Smart Account contract is Safe’s base contract. We have implemented a plugin to make it 4337 compatible which allows us to initiate the transaction in a decentralized way instead of having centralized relayers. This plugin also contains Biconomy’s Session Key module for enabling the Session Key feature.

Firstly, the signer (dapp builder) signs the message with userop format. During the validation of this userop, Biconomy’s Session Key Manager verifies the session. Manager firstly checks if the session is on the merkle tree (we store sessions in a merkle tree to make it cheap) or not. After that, it checks the correctness of the session. If all works correctly, exactTransaction triggers, which triggers the executefrommodule function which interacts with Card Game Contracts.

So we have a fully compatible smart contract modules that works well together and enables the way that users are interacting with blockchains. Card Contract and Front End components:

Future works:

Generalized Sign In, Sign Out standards for Session Keys: It is possible to build pre-approvals, which creates a mechanism for people to use blockchain without recognizing it but users should be able to revoke the given ownership - similar to sign out. Make it easy to build signer for dApp builders: If we can’t define how to make a secure signer for your dapp than the signer mechanism can be vulnerable to attacks. Enable Offchain batching mechanisms for DEX’s: Since requests are declarative way to express user’s needing, we can do offchain computation and batching mechanisms to serve the best execution part. Make it compatible with intent based architectures: This can be so hard to do since intents are only a type of signed messages but still there is a possibility to make it compatible with intent based systems.

How it's made: We have three parts for our project: A smart account contract powered by Biconomy and Safe, a smart contract for NFT based game and a front end for the game.

Smart Account Contract and its components:

Our main Smart Account contract is Safe’s base contract. We have implemented a plugin to make it 4337 compatible which allows us to initiate the transaction in a decentralized way instead of having centralized relayers. This plugin also contains Biconomy’s Session Key module for enabling the Session Key feature.

Firstly, the signer (dapp builder) signs the message with userop format. During the validation of this userop, Biconomy’s Session Key Manager verifies the session. Manager firstly checks if the session is on the merkle tree (we store sessions in a merkle tree to make it cheap) or not. After that, it checks the correctness of the session. If all works correctly, exactTransaction triggers, which triggers the executefrommodule function which interacts with Card Game Contracts.

So we have a fully compatible smart contract modules that works well together and enables the way that users are interacting with blockchains.

Front End: We used React, Nextjs for building it. We used Safe Core AA SDK to connect Safe wallet from front end.