---
# System prepended metadata

title: EAT Suggestions

---

# EAT Suggestions

## Rationale
The Ethereum Access Token (EAT) proposal aims to standardize a means of smart contract function access-control based on off-chain criteria. EATs provide a method to ensure that a function call is only executed under the conditions specified by the EAT issuer, including the identity of the caller, the parameters of the function, the function itself, and the timeframe within which the function call is valid.

An example flow integrated in a DeFi application is the following:
1. a user interacts with the DeFi's off-chain service, providing sufficient input for the off-chain service to ensure the user meets its criteria (for example, possesses valid credentials)
2. Upon successful verification, the DeFi application issues an EAT to the user
3. The user then interacts with the designated smart contract function within the specified period of time

EATs fill a void where access control requirements differ from current standard access control mechanisms (role-based access modifiers or possession of a token):
- Desired acccess is short-lived
- Criteria needs to be flexible/dynamic
- Soul-bound or other token semantics are not desired (TODO: fill this out more?)

By conforming to EIP-712, EATs are interoperable with existing Ethereum infrastructure, and developers can use them to create access controls with minimal modifications to their existing code.

## Security Considerations
The security of the Ethereum Access Token (EAT) proposal depends on several factors:

### Replay Attacks: 
The implementation must ensure that an EAT cannot be reused after it has been consumed. This is achieved by marking the EAT as consumed in the `_consumeAccessToken` function. (Question: is this always desired or is this ok within the timeframe if idempotent)

### Smart Contract Security
The smart contracts that implement the EAT (`AccessTokenConsumer` and `AccessTokenVerifier`) must be audited and tested thoroughly to ensure that they do not contain vulnerabilities that could be exploited.

### Off-Chain Verification:
The security of the off-chain verification system that grants EATs is also important. If this system is compromised, malicious actors could be granted EATs that they should not have access to.

### Expiry Time Considerations:
The expiry time of the EAT must be set judiciously to balance usability and security. If the expiry time is set too long, it might increase the risk of EAT misuse. If it's too short, it might compromise the usability of the application.

