From 5bedba5938ab1dab9c03c84d3f39615d7cfaaff8 Mon Sep 17 00:00:00 2001 From: PixelCircuits Date: Tue, 19 Sep 2023 10:49:04 -0400 Subject: [PATCH 1/7] added EIP draft --- EIPS/eip-xxxx.md | 208 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 EIPS/eip-xxxx.md diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md new file mode 100644 index 00000000000000..1447e2beb79174 --- /dev/null +++ b/EIPS/eip-xxxx.md @@ -0,0 +1,208 @@ +--- +eip: 9999 +title: General Intents for Smart Contract Wallets +description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent standards at sign time. +author: Stephen Monn (@pixelcircuits), Bikem Bengisu (@supiket) +discussions-to: https://ethereum-magicians.org/[TODO] +type: Standards Track +category: ERC +status: Draft +created: 2023-08-31 +--- + +## Abstract + +A generalized intent specification entry point contract which enables support for a multitude of intent standards as they evolve over time. Instead of smart contract wallets having to constantly upgrade to provide support for new intent standards as they pop up, a single entry point contract is trusted to handle signature verification which then passes off the low level intent data handling and defining to other contracts specified by users at intent sign time. These signed messages, called a `UserInent`, are gossipped around any host of mempool strategies for MEV searchers to look through and combine with their own `UserIntent` into an object called an `IntentSolution`. MEV searchers then package up an `IntentSolution` object they build into a transaction making a `handleIntents` call to a special contract. This transaction then goes through the typical MEV channels to eventually be included in a block. + +## Motivation + +See also ["EIP-4337: Account Abstraction via Entry Point Contract specification"](./eip-4337) and the links therein for historical work and motivation. + +This proposal uses the same entry point contract idea to enable a single interface which smart contract wallets can support now to unlock future proof access to an evolving intent landscape. It seeks to achieve the following goals: + +- **Achieve the key goal of enabling intents for users**: allow users to use smart contract wallets containing arbitrary verification logic to specify intents as described and handled by various other intent standard contracts. +- **Decentralization** + - Allow any MEV searcher to participate in the process of solving signed intents + - Allow any developer to add their own intent standard definitions for users to opt-in to at sign time +- **Be forward thinking for future intent standard compatibility**: Define an intent standard interface that gives future intent standard defining contracts access to as much information about the current `handleIntents` execution context as possible. +- **Keep gas costs down to a minimum**: Include some key intent handling logic, like basic execution guarantees and a default intent standard definition, into the entry point contract itself in order to optimize gas efficiency for the most common use cases. +- **Enable good user experience** + - Avoid the need for smart contract wallet upgrades when a user wants to use a newly developed intent standard + - Enable complex intent composition that only needs a single signature + +## Specification + +Users package up intents they want their wallet to participate in, in an ABI-encoded struct called a `UserIntent`: + +| Field | Type | Description | +| ------------ | --------- | ------------------------------------------------------------------------------------ | +| `standard` | `bytes32` | The intent standard identifier | +| `sender` | `address` | The wallet making the operation | +| `nonce` | `uint256` | Anti-replay parameter | +| `timestamp` | `uint256` | Time validity parameter | +| `intentData` | `bytes[]` | Data defined by the intent standard broken down into multiple segments for execution | +| `signature` | `bytes` | Data passed into the wallet along with the nonce during the verification step | + +The `intentData` parameter is an array of arbitrary bytes whose use is defined by the intent standard. Each item in this array is referred to as an **intent segment**. Users send `UserIntent` objects to any mempool strategy that works best for the intent standard being used. A specialized class of MEV searchers called **solvers** look for these intents and ways that they can be combined with other intents (including their own) to create an ABI-encoded struct called an `IntentSolution`: + +| Field | Type | Description | +| ----------- | -------------- | --------------------------------------------- | +| `timestamp` | `uint256` | The time at which intents should be evaluated | +| `intents` | `UserIntent[]` | List of intents to execute | +| `order` | `uint256[]` | Order of execution for the included intents | + +The solver then creates a **solution transaction**, which packages up an `IntentSolution` object into a single `handleIntents` call to a pre-published global **entry point contract**. + +The core interface of the entry point contract is as follows: + +```solidity +function handleIntents + (IntentSolution calldata solution) + external; + +function simulateHandleIntents + (IntentSolution calldata solution, address target, bytes calldata targetCallData) + external; + +function simulateValidation + (UserIntent calldata intent) + external; + +function registerIntentStandard + (IIntentStandard intentStandard) + external returns (bytes32); + +function verifyExecutingIntentForStandard + (IIntentStandard intentStandard) + external returns (bool); + +error ValidationResult + (bool sigFailed, uint48 validAfter, uint48 validUntil); + +error ExecutionResult + (bool success, bool targetSuccess, bytes targetResult); +``` + +The core interface required for an intent standard to have is: + +```solidity +function validateUserIntent + (UserIntent calldata intent) + external; + +function executeUserIntent + (IntentSolution calldata solution, uint256 executionIndex, uint256 segmentIndex, bytes memory context) + external returns (bytes memory); + +function isIntentStandardForEntryPoint + (IEntryPoint entryPoint) + external returns (bool); +``` + +The core interface required for a wallet to have is: + +```solidity +function validateUserIntent + (UserIntent calldata intent, bytes32 intentHash) + external returns (uint256); + +function generalizedIntentDelegateCall + (bytes memory data) + external returns (bool); +``` + +### Required entry point contract functionality + +The entry point's `handleIntents` function must perform the following steps. It must make two loops, the **verification loop** and the **execution loop**. + +In the verification loop, the `handleIntents` call must perform the following steps for each `UserIntent`: + +- **Validate `timestamp` value on the `IntentSolution`** by making sure it is within an acceptable range of `block.timestamp` or some time before it. +- **Call `validateUserIntent` on the wallet**, passing in the `UserIntent` and the hash of the intent. The wallet should verify the intent's signature. If any `validateUserIntent` call fails, `handleIntents` must skip execution of at least that intent, and may revert entirely. +- **Call `validateUserIntent` on the intent standard**, specified by the `UserIntent` with the `standard` parameter, passing in the `UserIntent`. The intent standard should verify the `intentData` parameter can successfully be parsed according to what the standard expects. If any `validateUserIntent` call fails, `handleIntents` must skip execution of at least that intent, and may revert entirely. + +In the execution loop, the `handleIntents` call must perform the following steps for all **segments** on the `intentData` bytes array parameter on each `UserIntent`: + +- **Call `executeUserIntent` on the intent standard**, specified by the `UserIntent` with the `standard` parameter. This call passes in the entire `IntentSolution` as well as the current `executionIndex` (the number of times this function has already been called for any standard or intent before this), `segmentIndex` (index in the `intentData` array to execute for) and `context` data. The `executeUserIntent` function returns arbitrary bytes per intent which must be remembered and passed into the next `executeUserIntent` call for the same intent. + +It's up to the intent standard to choose how to parse the `intentData` segment bytes and utilize the `context` data blob that persists across intent execution. + +The order of execution for `UserIntent` segments in the `intentData` array always follows the same order defined on the `intentData` parameter. However, the order of execution for segments between `UserIntent` objects can be specified by the `order` parameter of the `IntentSolution` object. For example, an `order` array of `[1,1,0,1]` would result in the second intent being executed twice (segments 1 and 2 on intent 2), then the first intent would be executed (segment 1 on intent 1), followed by the second intent being executed a third time (segment 3 on intent 2). If no ordering is specified in the solution, or all segments have not been processed for all intents after getting to the end of the order array, a default ordering will be used. This default ordering loops from the first intent to the last as many times as necessary until all intents have had all their segments executed. If the ordering calls for an intent to be executed after it's already been executed for all its segments, then the `executeUserIntent` call is simply skipped and execution across all intents continues. + +Before accepting a `UserIntent`, solvers must use an RPC method to locally call the `simulateValidation` function of the entry point, which verifies that the signature and data formatting is correct; see the [Intent validation section below](#intent-validation) for details. + +#### Registering new entry point intent standards + +The entry point's `registerIntentStandard` function must allow for permissionless registration of new intent standard contracts. During the registration process, the entry point contract must verify the contract is meant to be registered by calling the `isIntentStandardForEntryPoint` function on the intent standard contract. This function passes in the entry point contract address which the intent standard can then verify and return true or false. If the intent standard contract returns true, then the entry point registers it and gives it a **standard ID** which is unique to the intent standard contract, entry point contract and chain ID. + +### Extension: default intent standard + +We extend the entry point logic to support a **default intent standard** that can be used by solvers to perform basic operations in a gas efficient way. This default standard is registered with its own standard ID at entry point contract creation time. The functions `validateUserIntent` and `executeUserIntent` are included as part of entry point contracts code in order to reduce external calls. The `intentData` on this default standard is used as calldata to call to the intent `sender`. This allows the solver to perform a basic list of operations from their own wallet in a more gas efficient manner. + +### Intent standard behavior executing an intent + +The intent standard's `executeUserIntent` function is given access to a wide set of data, including the entire `IntentSolution` in order to allow it to be able to implement any kind of logic that may be seen as useful in the future. Each intent standard contract is expected to parse the `UserIntent` objects `intentData` parameter and use that to validate any constraints or perform any actions relevant to the standard. Intent standards can also take advantage of the `context` data it can return at the end of the `executeUserIntent` function. This data is kept by the entry point and passed in as a parameter to the `executeUserIntent` function the next time it is called for an event. This gives intent standards access to a persistent data store as other intents are executed in between others. One example of a use case for this is an intent standard that is looking for a change in state during intent execution (like releasing tokens and expecting to be given other tokens). + +### Smart contract wallet behavior executing an intent + +Smart contract wallets are not expected to do anything by the entry point during intent execution after validation. However, intent standards may wish for the smart contract wallet to perform some action. The smart contract wallet `generalizedIntentDelegateCall` function must perform a delegate call with the given calldata at the calling intent standard. In order for the wallet to trust making the delegate call it must call the `verifyExecutingIntentForStandard` function on the entry point contract to verify both of the following: + +- The `msg.sender` for `generalizedIntentDelegateCall` on the wallet is the intent standard contract that the entry point is currently calling `executeUserIntent` on. +- The smart contract wallet is the `sender` on the `UserIntent` that the entry point is currently calling `executeUserIntent` for. + +### Intent validation + +To validate a `UserIntent`, the solver makes a view call to `simulateValidation(intent)` on the entry point. This function always reverts with `ValidationResult` as a successful response. If the call reverts with another error, the solver rejects the `UserIntent`. While running, the solver should make sure that the call's execution trace does not invoke any **forbidden opcodes**. If this condition is violated, the solver should also reject the `UserIntent`. + +#### Forbidden opcodes + +The forbidden opcodes are to be forbidden when `depth > 2` (i.e. when it is the wallet, intent standard, or other contracts called by them that are being executed). They are: `GASPRICE`, `GASLIMIT`, `DIFFICULTY`, `TIMESTAMP`, `BASEFEE`, `BLOCKHASH`, `NUMBER`, `SELFBALANCE`, `BALANCE`, `ORIGIN`, `GAS`. The only exception is the `GAS` opcode if it is immediately followed by `CALL`, `DELEGATECALL`, `CALLCODE` or `STATICCALL`. They should only be forbidden during verification, not execution. These opcodes are forbidden because their outputs may differ between simulation and execution, so simulation of calls using these opcodes does not reliably tell what would happen if these calls are later done on-chain. + +### Simulation + +To simulate execution of an `IntentSolution`, the solver makes a view call to `simulateHandleIntents(solution)` on the entry point. This function always reverts with `ExecutionResult` as a successful response. If the call reverts with another error, the solver knows the `IntentSolution` was invalid. The solver also has the option to provide a `target` with `targetCallData`. At the end of simulation, the entry point will call to the target contract with the calldata to do any final analysis and return data through the `ExecutionResult` error. + +## Rationale + +The main challenge with a generalized intent standard is being able to adapt to the evolving world of intents. Users need to have a way to express their intents in a seamless way without having to make constant updates to their smart contract wallets. + +In this proposal, we expect wallets to have a `validateUserIntent` function that takes as input a `UserOperation`, and verifies the signature. A trusted entry point contract uses this function to validate the signature and forwards the intent handling logic to an intent standard contract specified in the `UserOperation`. The wallet is then expected to have a `generalizedIntentDelegateCall` function that allows it to perform intent related actions from the intent standard contract, using the `verifyExecutingIntentForStandard` function on the entry point for security. + +The entry point-based approach allows for a clean separation between verification and intent execution, and prevents wallets from having to constantly update to support the latest version of intent composition that a user wants to use. The alternative would involve developers of new intent standards having to convince wallet software developers to support their new intent standards. This proposal moves the core definition of an intent into the hands of users at signing time. + +### Solvers + +Solvers facilitate the fulfillment of a user's intent in search of their own MEV. They also act as the transaction originator for executing intents on-chain, including having to front any gas fees, removing that burden from the typical user. + +Solvers will rely on gossiping networks and solution algorithms that are to be determined by the individual intent standards. + +### Entry point upgrading + +Wallets are encouraged to be DELEGATECALL forwarding contracts for gas efficiency and to allow wallet upgradability. The wallet code is expected to hard-code the entry point into their code for gas efficiency. If a new entry point is introduced, whether to add new functionality, improve gas efficiency, or fix a critical security bug, users can self-call to replace their wallet's code address with a new code address containing code that points to a new entry point. During an upgrade process, it's expected that intent standard contracts will also have to be redeployed and registered to the new entry point. + +#### Intent standard upgrading + +Because intent standards are not hardcoded into the wallet, users do not need to perform any operation to use any newly registered intent standards. A user can simply sign an intent with the new intent standard. + +## Backwards Compatibility + +This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. There is a little more difficulty when trying to integrate with existing smart contract wallets. If the wallet already has support for [ERC-4337](https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160), then implementing a `validateUserIntent` function should be very similar to the `validateUserOp` function, but would require an upgrade by the user. + +## Reference Implementation + +See https://github.com/essential-contributions/ERC-xxxx +[TODO] + +## Security considerations + +The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ ERC[TODO] supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. + +Verification would need to cover one primary claim (not including claims needed to protect solvers, and intent standard related infrastructure): + +- **Safety against arbitrary hijacking**: The entry point only returns true for `verifyExecutingIntentForStandard` when it has successfully validated the signature of the `UserIntent` and is currently in the middle of calling `executeUserIntent` on the `standard` specified in a `UserIntent` which also has the same `sender` as the `msg.sender` wallet calling the function. + +Additional heavy auditing and formal verification will also need to be done for any intent standard contracts a user decides to interact with. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 11592f6fe1e24e687b3cb1b5e91076fbbd6ef33f Mon Sep 17 00:00:00 2001 From: PixelCircuits Date: Tue, 19 Sep 2023 10:59:40 -0400 Subject: [PATCH 2/7] updated eip number --- EIPS/{eip-xxxx.md => eip-7739.md} | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) rename EIPS/{eip-xxxx.md => eip-7739.md} (96%) diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-7739.md similarity index 96% rename from EIPS/eip-xxxx.md rename to EIPS/eip-7739.md index 1447e2beb79174..2cce7b264ea2a7 100644 --- a/EIPS/eip-xxxx.md +++ b/EIPS/eip-7739.md @@ -1,5 +1,5 @@ --- -eip: 9999 +eip: 7739 title: General Intents for Smart Contract Wallets description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent standards at sign time. author: Stephen Monn (@pixelcircuits), Bikem Bengisu (@supiket) @@ -190,12 +190,11 @@ This ERC does not change the consensus layer, so there are no backwards compatib ## Reference Implementation -See https://github.com/essential-contributions/ERC-xxxx -[TODO] +See https://github.com/essential-contributions/ERC-7739 ## Security considerations -The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ ERC[TODO] supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. +The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ ERC-7739 supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. Verification would need to cover one primary claim (not including claims needed to protect solvers, and intent standard related infrastructure): From 42724ef36b5470a2efcee98e541240165bbad2a1 Mon Sep 17 00:00:00 2001 From: PixelCircuits Date: Tue, 19 Sep 2023 11:25:56 -0400 Subject: [PATCH 3/7] formatting fixes --- EIPS/eip-7739.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-7739.md b/EIPS/eip-7739.md index 2cce7b264ea2a7..8ef51aea4ef5dc 100644 --- a/EIPS/eip-7739.md +++ b/EIPS/eip-7739.md @@ -1,13 +1,13 @@ --- eip: 7739 title: General Intents for Smart Contract Wallets -description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent standards at sign time. +description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent structures/definitions at sign time. author: Stephen Monn (@pixelcircuits), Bikem Bengisu (@supiket) discussions-to: https://ethereum-magicians.org/[TODO] +status: Draft type: Standards Track category: ERC -status: Draft -created: 2023-08-31 +created: 2023-09-19 --- ## Abstract @@ -16,7 +16,7 @@ A generalized intent specification entry point contract which enables support fo ## Motivation -See also ["EIP-4337: Account Abstraction via Entry Point Contract specification"](./eip-4337) and the links therein for historical work and motivation. +See also ["ERC-4337: Account Abstraction via Entry Point Contract specification"](./eip-4337) and the links therein for historical work and motivation. This proposal uses the same entry point contract idea to enable a single interface which smart contract wallets can support now to unlock future proof access to an evolving intent landscape. It seeks to achieve the following goals: @@ -186,13 +186,13 @@ Because intent standards are not hardcoded into the wallet, users do not need to ## Backwards Compatibility -This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. There is a little more difficulty when trying to integrate with existing smart contract wallets. If the wallet already has support for [ERC-4337](https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160), then implementing a `validateUserIntent` function should be very similar to the `validateUserOp` function, but would require an upgrade by the user. +This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. There is a little more difficulty when trying to integrate with existing smart contract wallets. If the wallet already has support for [ERC-4337](./eip-4337), then implementing a `validateUserIntent` function should be very similar to the `validateUserOp` function, but would require an upgrade by the user. ## Reference Implementation See https://github.com/essential-contributions/ERC-7739 -## Security considerations +## Security Considerations The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ ERC-7739 supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. @@ -204,4 +204,4 @@ Additional heavy auditing and formal verification will also need to be done for ## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). +Copyright and related rights waived via [CC0](../LICENSE.md). From f1109a3a820a981ae4c43c53af9c226a0a1be8a7 Mon Sep 17 00:00:00 2001 From: PixelCircuits Date: Tue, 19 Sep 2023 11:27:54 -0400 Subject: [PATCH 4/7] fix broken links --- EIPS/eip-7739.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7739.md b/EIPS/eip-7739.md index 8ef51aea4ef5dc..cd22493107c2c1 100644 --- a/EIPS/eip-7739.md +++ b/EIPS/eip-7739.md @@ -16,7 +16,7 @@ A generalized intent specification entry point contract which enables support fo ## Motivation -See also ["ERC-4337: Account Abstraction via Entry Point Contract specification"](./eip-4337) and the links therein for historical work and motivation. +See also ["ERC-4337: Account Abstraction via Entry Point Contract specification"](./eip-4337.md) and the links therein for historical work and motivation. This proposal uses the same entry point contract idea to enable a single interface which smart contract wallets can support now to unlock future proof access to an evolving intent landscape. It seeks to achieve the following goals: @@ -186,7 +186,7 @@ Because intent standards are not hardcoded into the wallet, users do not need to ## Backwards Compatibility -This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. There is a little more difficulty when trying to integrate with existing smart contract wallets. If the wallet already has support for [ERC-4337](./eip-4337), then implementing a `validateUserIntent` function should be very similar to the `validateUserOp` function, but would require an upgrade by the user. +This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. There is a little more difficulty when trying to integrate with existing smart contract wallets. If the wallet already has support for [ERC-4337](./eip-4337.md), then implementing a `validateUserIntent` function should be very similar to the `validateUserOp` function, but would require an upgrade by the user. ## Reference Implementation From defa9cf193a29e695be9e2997f377bb17f85ad70 Mon Sep 17 00:00:00 2001 From: PixelCircuits Date: Tue, 19 Sep 2023 11:43:36 -0400 Subject: [PATCH 5/7] formatting --- EIPS/eip-7739.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7739.md b/EIPS/eip-7739.md index cd22493107c2c1..2e35154829b28a 100644 --- a/EIPS/eip-7739.md +++ b/EIPS/eip-7739.md @@ -1,7 +1,7 @@ --- eip: 7739 title: General Intents for Smart Contract Wallets -description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent structures/definitions at sign time. +description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent structures at sign time author: Stephen Monn (@pixelcircuits), Bikem Bengisu (@supiket) discussions-to: https://ethereum-magicians.org/[TODO] status: Draft @@ -190,7 +190,7 @@ This ERC does not change the consensus layer, so there are no backwards compatib ## Reference Implementation -See https://github.com/essential-contributions/ERC-7739 +See `https://github.com/essential-contributions/ERC-7739` ## Security Considerations From 8d5a63f4155a499588e23dd66e110eab811f7504 Mon Sep 17 00:00:00 2001 From: PixelCircuits Date: Tue, 19 Sep 2023 11:57:09 -0400 Subject: [PATCH 6/7] update ethereum magicians link --- EIPS/eip-7739.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-7739.md b/EIPS/eip-7739.md index 2e35154829b28a..0e49ad6f5287f9 100644 --- a/EIPS/eip-7739.md +++ b/EIPS/eip-7739.md @@ -3,7 +3,7 @@ eip: 7739 title: General Intents for Smart Contract Wallets description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent structures at sign time author: Stephen Monn (@pixelcircuits), Bikem Bengisu (@supiket) -discussions-to: https://ethereum-magicians.org/[TODO] +discussions-to: https://ethereum-magicians.org/t/erc-7739-generalized-intents-for-smart-contract-wallets/15840 status: Draft type: Standards Track category: ERC @@ -194,7 +194,7 @@ See `https://github.com/essential-contributions/ERC-7739` ## Security Considerations -The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ ERC-7739 supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. +The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ [ERC-7739](./eip-7739.md) supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. Verification would need to cover one primary claim (not including claims needed to protect solvers, and intent standard related infrastructure): From ae5dc482330aa301994cbf727d82eee7b481c43a Mon Sep 17 00:00:00 2001 From: PixelCircuits Date: Wed, 20 Sep 2023 10:07:53 -0400 Subject: [PATCH 7/7] update eip number --- EIPS/{eip-7739.md => eip-7521.md} | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) rename EIPS/{eip-7739.md => eip-7521.md} (99%) diff --git a/EIPS/eip-7739.md b/EIPS/eip-7521.md similarity index 99% rename from EIPS/eip-7739.md rename to EIPS/eip-7521.md index 0e49ad6f5287f9..f19bea4e37e7d0 100644 --- a/EIPS/eip-7739.md +++ b/EIPS/eip-7521.md @@ -1,9 +1,9 @@ --- -eip: 7739 +eip: 7521 title: General Intents for Smart Contract Wallets description: A generalized intent specification for smart contract wallets, allowing authorization of current and future intent structures at sign time author: Stephen Monn (@pixelcircuits), Bikem Bengisu (@supiket) -discussions-to: https://ethereum-magicians.org/t/erc-7739-generalized-intents-for-smart-contract-wallets/15840 +discussions-to: https://ethereum-magicians.org/t/erc-7521-generalized-intents-for-smart-contract-wallets/15840 status: Draft type: Standards Track category: ERC @@ -190,11 +190,11 @@ This ERC does not change the consensus layer, so there are no backwards compatib ## Reference Implementation -See `https://github.com/essential-contributions/ERC-7739` +See `https://github.com/essential-contributions/ERC-7521` ## Security Considerations -The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ [ERC-7739](./eip-7739.md) supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. +The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ [ERC-7521](./eip-7521.md) supporting wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserIntent` function and its "check signature, increment nonce" logic) and gate any calls to `generalizedIntentDelegateCall` by checking with the entry point using the `verifyExecutingIntentForStandard` function. The concentrated security risk in the entry point contract, however, needs to be verified to be very robust since it is so highly concentrated. Verification would need to cover one primary claim (not including claims needed to protect solvers, and intent standard related infrastructure):