nftchance / emporium-lib Goto Github PK

2️⃣ Streamline the creation, verification, and consumption of intent-based EIP-712 signatures and transactions.

TypeScript 100.00%

emporium-lib's Introduction

Emporium Library

Emporium is the fastest way to get up and running with the a typesafe intent-based architecture in Typescript. Here you can find Solver and Signer mechanisms of Emporium to create, execute, and validate the state of parallel intent declarations and transactions.

Without Emporium:

🚨 .signTypedData() returns a raw hex type:string.
🤔 type:string has none of the logical utilities of an class:Intent.
🤬 .recover() requires you manage signature parts and backend support.

With Emporium:

🧩 .sign() returns a typesafe version of a class:Intent.
🥹 class:Intent includes all the utilities of a typical intent protocol.
✅ .recover() automaticaly verify the Signer from in-memory cache.
🚀 and several more small helper utilities.

Built using:

├─ abitype - "Parse EIP712 types to typesafe structs."
├─ ethers - "Complete and compact library for interacting with the Ethereum Blockchain."
└─ typescript - "You will find types for each piece to make working with the library simple."

Getting Started

Getting up and running with the use of Emporium is incredibly straightforward. Built on top of Ethers, you can import the library into your existing codebase without need configuration, dependency dances, or managing the conflicts of trying to use dependencies that are not meant for both the browser & node environment.

Installation

To install this library in your repository for personal use run:

pnpm i @nftchance/emporium-lib

Basic Usage

In the beginning stages, you likely aren't going to want to extend the framework. With instant access to signing and management of Delegation and Invocations you can prepare your codebase for framework consumption in just a few lines:

// * Prepare the EIP-712 domain metadata.
const metadata = ['Echo', '0.1.0']

// * Prepare your contract reference -- You can connect however you prefer.
// ! Echo is just an example, you will use your contract that 
//   extends the framework onchain here.
const contract = await (
    await ethers.getContractFactory('Echo')
).deploy(...metadata)

// * Instantiate the framework to handle your Intents.
const util = await new Framework(contract).init(...metadata)

// * Easily sign and manage the resulting body with type safety 
//   and access to the built-in utility functions.
const signedDelegation = await util.sign(owner, 'Delegation', {
    delegate: await owner.getAddress(),
    authority: ethers.ZeroHash as `0x${string}`,
    caveats: []
})

emporium-lib's People

Contributors

Watchers

Forkers

talaria-finance

emporium-lib's Issues

feat: remove PRIMARY_TYPES reliance from library

Now that we have to write our version of an intent protocol (#10), it has become apparent that we must remove the base implementations of the types. This is only possible because by including the 712 types in the library, we are operating with the assumption that the protocol:

1.) Already exists.
2.) Has been tested.

But, to test the protocol, we need the library because we need to be able to sign the messages. This means that for this to work, we must convert the library to be purely generic and extensible. While this is unfortunate right now, at least this means that it is unlikely we have backward compatibility issues created by protocol updates.

Tests that test the protocol should be localized to the protocol, and library functionality should be tested in the library. With this direction, we are to assume that the dependency in each environment is always assumed to function.

An interesting thing that the developers of Delegatable did was declare the top level of the EIP-712 interface values. Using that, they generate the Solidity code.

feat: replace ethers with viem

feat: mirror tests in eth-delegatable-utils

feat: write framework protocol

The library base had been built using Delegatable; however, that has proven to be wrong.

Due to the nature of the implementation, many decisions could have been better in Solidity. Through the development process, the library was configured to be Solidity-first meaning the Typescript types are inferred from the EIP712 types.

Due to building on top of the existing Delegatable framework, though, the implementation cannot be immediately wrapped by ethers even after having wrangled all the types. Further, the protocol was not written for 'production' and currently exists in a development-only state. Unfortunately, one cannot even take it to staging as there is no realistic way to build a consuming front-end on a testnet.

Finally, MetaMask has begun the development of a different implementation:

We have a team at MetaMask that is currently doing exploration on a second version. We’re hoping to form it into something consumable by December. The framework does work as is and could be used as a reference or starting point, but I suspect we won’t be actively developing it, at least for a while (trying account-based approaches)

If the developing team is unwilling to adopt and continue the protocol development, we should not deal with the struggles of building on top of a primitive that is not ours. Realistically, they have put immense work and thought into building the architecture. Forking the codebase is an effective and efficient path forward.

If we maintain the existing top-level architecture of the framework, then we not only preserve the social knowledge that has been established, but we also get to use all the deployed infrastructure that already exists on each chain.

The unfortunate truth is that, realistically, this is not something we should build for others. Instead, a certain level of foundational protection should be carried out to minimize the competition we create for ourselves. By establishing a generalized intent framework, we not only pull away from the pack but also enter territory where there are effectively no competitors that can close the gap quickly.

Key issues to resolve:

Typehash declarations were written with uint instead of uint256.
The implementation could have been designed considering gas efficiency.

While some things must be fixed, many others could/should be improved before shipping it into production.

Notes of thoughts:

Funnily, I think maintaining the terminology of Framework would disincentivize others from adopting simply because of the in-contract and resulting type names.

feat: caveat create2 factories

All caveats should be set to deploy with create2 so that we can easily access caveats consistently across all the chains.

feat: Typescript support for a Generalized Intent Frafemework

Enable the ability to sign and interact with the base Intent shapes of the framework.
- Delegation
- Invocations
Enforce type compliance of provided shape based on the struct that is provided.
Provide the ability to provide additional EIP712 types and reference type structs so that one can make an extensible framework.

feat: add function to Intent to get hash of Intent directive

feat: use abitype to convert EIP712 types into structs

feat: remove hardhat and ethers and only use viem

I don't wanna.

feat: Recover address from signed intent

Emporium Intent Library

feat: automatically infer primaryType

It is not actually necessary to declare the primaryType since it can be inferred from the type DAG.

feat: implement abitype to convert the EIP712 type to a struct at runtime

This has been completed and is consumed with the following:

const signedDelegation = await util.sign(owner, 'Delegation', {
    delegate: await owner.getAddress(),
    authority: ethers.ZeroHash as `0x${string}`,
    caveats: []
})

The fields are auto-completed based on the EIP-712 type that is provided, which also auto-completes based on the util without explicitly declaring the types.

The architecture was written to be soon integrated with viem, but first support ethers.

This means, that now, as long as we have the EIP712 types that can be declared, we are ready to rock and roll. This pushed along the base framework much faster than expected after the amount of initial hurdles I was running into.