diff --git a/EIPS/eip-7697.md b/EIPS/eip-7697.md
new file mode 100644
index 00000000000000..fdb9a6b360663b
--- /dev/null
+++ b/EIPS/eip-7697.md
@@ -0,0 +1,155 @@
+---
+eip: 7697
+title: AUTHCREATE opcode
+description: Validating and setting code for deterministic addresses.
+author: Xin Tian (@txgyy), Elim Poon (@yaonam)
+discussions-to: https://ethereum-magicians.org/t/eip-7697-authcreate-opcode/19780
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-04-23
+requires: 155
+---
+
+## Abstract
+
+The EIP introduces an EVM instruction `AUTHCREATE`. It allows a deterministic addresses to migrate to a smart contract.
+
+Inspiration comes from [EIP-3074](./eip-3074.md) and [EIP-5003](./eip-5003.md):
+
+- ([EIP-3074](./eip-3074.md)) + [EIP-5003](./eip-5003.md) = (`AUTH` + `AUTHCALL`) + `AUTHUSURP`
+- [EIP-7697](./eip-7697.md) = `AUTHCREATE` = `AUTH` + `AUTHUSURP`
+
+## Motivation
+
+For a long time, the EVM ecosystem has been plagued by two issues:
+
+1. Difficulty ensuring consistency across addresses on multiple chains, even when using the same bytecode.
+2. EOAs lack contract capabilities, preventing the realization of account abstraction.
+    1. Authentication - any form of proving one’s identity.
+    2. Authorization - any access policy.
+    3. Replay protection - transaction ordering decoupled from replay protection.
+    4. Gas payment - gas payment decoupled from the account itself.
+    5. Execution - any execution logic.
+
+[EIP-7697](./eip-7697.md) will address these issues.
+
+| Feature                                                      | [EIP-7697](./eip-7697.md)  | [EIP-3074](./eip-3074.md) | [EIP-5003](./eip-5003.md) | [EIP-7377](./eip-7377.md) |
+|--------------------------------------------------------------|----------------------------|---------------------------|---------------------------|---------------------------|
+| Deploy the same address [ERC-2470](./eip-2470.md)            | ✅                          | ❎                         | ✅ need 3 opcodes          | ✅ only EOA                |
+| Help EOA to upgrade to CA                                    | ✅                          | ❎                         | ✅ need 3 opcodes          | ✅                         |
+| Support `secp256r1` or more                                  | ✅                          | ✅                         | ❎                         | ❎                         |
+| Reuse existing wallet infrastructure                         | ✅ adapt the contract       | ❎                         | ✅ adapt the contract      | ❎ adapt the node rpc      |
+| Integrate easily with [ERC-4337](./eip-4337.md) and RIP-7560 | ✅ support factory contract | ❎                         | ❎                         | ❎                         |
+| Grant temporary CA capabilities to EOA                       | ❎                          | ✅                         | ❎                         | ❎                         |
+
+## Specification
+
+### Constants
+
+| Constant          | Value  |
+|-------------------|--------|
+| `AuthCreateMagic` | `0x04` |
+| `AUTHCREATE`      | `0xf6` |
+
+`AuthCreateMagic` is used for [EIP-7697](./eip-7697.md) signatures to prevent signature collisions with other signing
+formats.
+
+#### Input
+
+##### Stack
+
+| Stack     | Value       |
+|-----------|-------------|
+| `top - 0` | `endowment` |
+| `top - 1` | `offset`    |
+| `top - 2` | `size`      |
+
+##### Memory
+
+The two stack arguments (`offset` and `size`) describe a range of memory. The format of the contents of that range is:
+
+- `memory[offset    : offset+1 ]` - `yParity`
+    - 0-1: secp256k1
+    - 4-5: secp256r1
+- `memory[offset+1  : offset+33]` - `r`
+- `memory[offset+33 : offset+65]` - `s`
+- `memory[offset+65 :          ]` - `creationCode`
+
+#### Output
+
+##### Stack
+
+| Stack     | Value          |
+|-----------|----------------|
+| `top - 0` | `contractAddr` |
+
+##### Memory
+
+Memory is not modified by this instruction.
+
+#### Behavior
+
+The arguments (`yParity`, `r`, `s`) are interpreted as an ECDSA signature on the secp256k1(or secp256r1) curve over the
+message `keccak256(AuthCreateMagic || chainId || creationCodeHash)`, where:
+
+- `chainId` is the current chain's [EIP-155](./eip-155.md) unique identifier padded to 32 bytes.
+- `creationCode` is the creation code set for the EOA.
+
+#### Gas Cost
+
+_todo: detail_
+
+`Authenticate`:
+
+- secp256k1: 3000
+- secp256r1: 3450
+
+`Set Code`:
+
+- create2: 32000 + dynamicGas
+
+## Rationale
+
+Authenticate and set code for EOA
+
+### Authenticate
+
+Users need to prove their ownership of an address using a specified signature algorithm to set the Code under that
+address.
+The signature content includes `AuthCreateMagic`, `chainId`, and `creationCodeHash`.
+
+The inclusion of `nonce` in the signature message was considered, but addresses generated by `secp256r1` do not have
+a `nonce`.
+
+Two signature algorithms can be supported (with the capability to easily expand to more):
+
+#### secp256k1
+
+Use the `secp256k1` algorithm when `yParity` is equal to 0 or 1.
+
+#### secp256r1
+
+Use the `secp256r1` algorithm when `yParity` is equal to 4 or 5. It depends on [EIP-7212](./eip-7212.md).
+
+### Set Code
+
+1. After the signature verification passes, first set the `nonce` to 0.
+2. The subsequent operations are the same as [Create2](./eip-1014.md).
+3. Restore to the original `nonce` and increment it by 1.
+
+## Backwards Compatibility
+
+Determine the signature type through the first byte, allowing for support of additional signature algorithms.
+
+## Security Considerations
+
+1. When an `EOA` upgrades to a `CA`, the `EOA` can no longer initiate transactions,
+   and if the contract checks `tx.origin`, it will cause the transaction to fail.
+2. Upgrading to a non-functional or malicious contract can result in the loss of user assets.
+3. It is possible to upgrade to a contract in a single transaction and perform `SELFDESTRUCT`,
+   but resetting the `nonce` to 0 poses a risk of transaction replay.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).