You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 theTypescript
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 adevelopment-only
state. Unfortunately, one cannot even take it tostaging
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:
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:
uint
instead ofuint256
.While some things must be fixed, many others could/should be improved before shipping it into production.
Notes of thoughts:
Framework
would disincentivize others from adopting simply because of the in-contract and resulting type names.The text was updated successfully, but these errors were encountered: