# Final Update - EPF

## Project Summary

I initially aimed to develop the proposed 4337 wallet, a browser extension wallet composed of three modules: extension, auth, and recovery. The aim was to support multiple SCW implementations by exposing the API to allow users to select the SCW implementation they prefer. However, the task turned out to be monumental, and some priorities needed to be set for EthDenver. Thus, we realigned our goals and came up with the following:

- Deprioritize the secure module for safe execution environments for multiple wallets.
- Finish onboarding with a custom screen for SCW to take user input.
- Inject the Web3Provider.
- Create a primary transaction confirmation screen that developers can clone and customize.
- Write a README for users to clone the repo and develop.
- Clean up any leftover issues.
- Modify the 2fa extension demo.

We successfully achieved our goals and launched the project at EthDenver by naming it Trampoline.

## Trampoline Framework Structure

To organize your extension's account code, you must place it all in the src/pages/Account folder. Within this folder, there are two subfolders that you'll use:

- account-api
- components

### account-api folder

You'll use the `account-api` folder to define the AccountAPI of your specific account implementation. Every implementation must implement `AccountApiType`.

export abstract class AccountApiType extends BaseAccountAPI {
  abstract serialize: () => Promise<object>;

  /** sign a message for the user */
  abstract signMessage: (
    request?: MessageSigningRequest,
    context?: any
  ) => Promise<string>;

  abstract signUserOpWithContext(
    userOp: UserOperationStruct,
    context?: any
  ): Promise<string>;
}

The boilerplate includes a SimpleAccount Implementation by Eth-Infinitism, which you can find [here](https://github.com/eth-infinitism/bundler/blob/main/packages/sdk/src/SimpleAccountAPI.ts).

### components folder

You'll use the components folder to define the components that will be used in the Chrome extension. This folder should contain three subfolders:

- onboarding
- sign-message
- transaction

The `onboarding` folder defines the component that will be displayed to the user during the creation of a new wallet. You can use it to display custom information or collect user inputs, if necessary.

Here's the interface of the `OnboardingComponent`:

export interface OnboardingComponentProps {
  onOnboardingComplete: (context?: any) => void;
}

export interface OnboardingComponent
  extends React.FC<OnboardingComponentProps> {}

After the component has gathered sufficient information from the user, it should pass the collected data to `onOnboardingComplete` as the `context` parameter. This `context` will then be passed on to your account-api.

Here's the interface of the `account-api`, which shows how the `context` will be passed:

export interface AccountApiParamsType extends BaseApiParams {
  context?: any;
}

export type AccountImplementationType = new (
  params: AccountApiParamsType
) => AccountApiType;

The `sign-message` folder defines the component that appears when the dapp asks the user to sign a message, such as when the dapp calls the `personal_sign` RPC method. You can use this component to display custom information or collect user inputs as needed.

Here's the interface of the `SignMessageComponent`:

export interface SignMessageComponenetProps {
  onComplete: (context?: any) => Promise<void>;
}

export interface SignMessageComponenet
  extends React.FC<SignMessageComponenetProps> {}

Once the component has gathered sufficient information from the user, it should pass the collected data to `onComplete` as the `context` parameter. This context will then be passed on to your `signMessage` function in the account-api.

Here's the interface of the `signMessage` function, which shows how the context will be passed:

  /** sign a message for the user */
  abstract signMessage: (
    request?: MessageSigningRequest,
    context?: any
  ) => Promise<string>;

The `transaction` folder defines the component that appears when the dapp requests to initiate a transaction, such as when the dapp calls the `eth_sendTransaction` RPC method. You can use this component to display custom information or collect user inputs as needed.

Here's the interface of the `TransactionComponent`:

export interface TransactionComponentProps {
  transaction: EthersTransactionRequest;
  onComplete: (
    modifiedTransaction: EthersTransactionRequest,
    context?: any
  ) => Promise<void>;
}

export interface TransactionComponent
  extends React.FC<TransactionComponentProps> {}

Once the component has gathered sufficient information from the user, it should pass the collected data to `onComplete` as the `context` parameter. You can also modify the transaction if desired and return it as a parameter of the `onComplete` function. This `context` and `modifiedTransaction` will then be passed on to your `createUnsignedUserOp` function in the account-api.

Here's the interface of the `createUnsignedUserOp` function, which shows how the context will be passed:

  /** sign a message for the user */
  abstract createUnsignedUserOp: (
    request?: MessageSigningRequest,
    context?: any
  ) => Promise<string>;

If you wish, you can also attach a paymaster to sponsor the transaction, and the paymaster information will be displayed to the user.

## Status Report

I am happy to announce the successful launch of the first version of Trampoline. You can find the repository here: https://github.com/eth-infinitism/trampoline

Here are the achievements I was able to accomplish during the project:

- Developed the ability to fork the repository and create a new wallet.
- Each wallet has the freedom to define their own Wallet API structure in src/pages/Account/account-api.
- Three custom components were added that can be defined by the wallet owners: onboarding, sign-message, and transaction.
- The project can be configured to run on any network, including local setup, and detailed instructions are available on the repository.
- Detailed documentation on how to use Trampoline can be found at: https://github.com/eth-infinitism/trampoline#trampoline-example

In addition to making the framework work, I also created two demo projects that showcase how to use Trampoline:

- **Two owner Account** - This custom SCW requires the signature of both owners for any transaction. You can find the project at: https://github.com/plusminushalf/trampoline-example/tree/two-owner-account.
- **Sign transactions with webauthn fingerprint** - This project verifies webauthn signatures on-chain and is the first open-source working and secure version. More information can be found at: https://github.com/plusminushalf/trampoline-example/tree/fingerprint. I will be writing a blog on how webauthn works and how we can optimize the implementation in the future. One issue with the current implementation is that it takes 1M gas for every transaction.

## Future Plans

Although we were able to launch Trampoline for EthDenver, it still requires stability fixes. Our target is to make it stable by EthTokyo. I have received suggestions on how to improve the architecture of the project and will work on implementing them after EthTokyo. I am also receiving a grant from EF to continue working on the project. More applications supporting this framework need to be developed and tested by developers in future hackathons so that the framework can support a wide variety of use cases without any shortcomings.

## Self evaluation

Working on this project was a roller coaster experience for me. Although I started off on a high note and learned a lot, I forgot to plan the project properly and it started feeling like an infinite amount of work that wouldn't be finished by the end of EPF. Discussing this with my mentors helped and Tom from EF helped me re-scope the project and get back on track. I would suggest to future fellows that it is good to re-evaluate the project's progress and re-prioritize the tasks midway through EPF.

I would also like to give a shoutout to the EPF team, particularly Josh and Mario, who not only helped when I was getting derailed but were also available for everyone throughout the EPF. We had weekly calls on Mondays to share updates and AMA sessions on Tuesdays. I particularly enjoyed the calls on Tuesdays as we got to listen to OG contributors who have been working and contributing to Ethereum for more than half a decade.

All in all, the EPF was a wholesome experience, and I hope to keep contributing more to Ethereum in the future.