diff --git a/EIPS/eip-3520.md b/EIPS/eip-3520.md
new file mode 100644
index 00000000..9ae498be
--- /dev/null
+++ b/EIPS/eip-3520.md
@@ -0,0 +1,93 @@
+---
+eip: 3520
+title: Transaction Destination Opcode
+author: Alex Papageorgiou (@alex-ppg)
+discussions-to: https://ethereum-magicians.org/t/eip-3520-transaction-destination-opcode/6058
+status: Draft
+type: Standards Track
+category: Core
+created: 2021-04-16
+requires: 3508
+---
+
+## Simple Summary
+
+Provide access to the original recipient of a transaction.
+
+## Abstract
+
+This EIP introduces the following EVM instruction: `ENTRYPOINT`.
+
+This instruction is meant to provide access to the original recipient of the transaction, the `to` address, enabling new ways of introspection to be applied in conjunction with [EIP-3508](./eip-3508.md).
+
+## Motivation
+
+It is undeniable that smart contracts are becoming more interconnected than ever. Up until this point, smart contracts have entirely relied on compliant interfaces and introspection to introduce a new step in the call chain of a complex multi-contract interaction. However, this presents a forwards-only approach which limits the types of interactions that can manifest.
+
+The purpose of this EIP is to provide a way via which a contract is able to identify the entry-point of a transaction on the blockchain and deduce what was the original intention of the transaction by applying introspection on the original transaction data itself.
+
+This EIP enables the development of new types of smart contracts as it can open new pathways for [EIP-721](./eip-721) NFTs and [EIP-20](./eip-20) tokens to detect which action their transaction is part of, such as detecting a liquidity provision to a decentralized exchange or a loan within a collateralized lending protocol.
+
+## Specification
+
+### ENTRYPOINT (`0x4a`)
+
+The `ENTRYPOINT` instruction uses 0 stack arguments and pushes the original `to` member of the transaction onto the stack. The address yielded by the instruction is a 160-bit value padded to 256-bits. The operation costs `G_base` to execute, similarly to `ORIGIN` (`0x32`).
+
+### AUTHCALL (`0xf7`)
+
+The `ENTRYPOINT` opcode by itself re-introduces discrimination into the system as it indirectly allows one to evaluate whether the smart contract code being executed is done so by an EOA by validating that `ENTRYPOINT == ADDRESS` where `ADDRESS` (`0x30`) retrieves the currently executing account address.
+
+In detail, the address returned by the `ENTRYPOINT` opcode will be equivalent to the `to` address parameter specified in the nearest `AUTHCALL` up the stack.  If there is no `AUTHCALL` in the stack then `ENTRYPOINT` will retrieve the original transaction's `to` field.
+
+## Rationale
+
+### AUTHCALL (`0xf7`) Interaction
+
+The [EIP-3074](./eip-3074.md) introduced a new call instruction called `AUTHCALL` (`0xf7`) that will replace a transaction's `ORIGIN` (`0x32`) with the context variable `authorized`. The intention of `AUTHCALL` is to prevent discrimination between smart contracts and EOAs which `ORIGIN` initially facilitated and as a result, it is sensible also replace the values retrieved by the `ENTRYPOINT` opcode to the target of an `AUTHCALL`.
+
+This interaction ensures full compatibility with [EIP-3074](./eip-3074.md) and ensures that no form of discrimination is introduced back into the system by this EIP.
+
+### Naming Conventions
+
+The `ENTRYPOINT` instruction came to be by defining a sensible name that immediately and clearly depicts what it is meant to achieve by signaling the first interaction of a particular call, i.e. the entry-point.
+
+### Instruction Address Space
+
+Equivalent to [EIP-3508](./eip-3508).
+
+### Gas Cost
+
+The opcode ENTRYPOINT (`0x4a`) essentially performs the same thing as the opcode ORIGIN (`0x32`) and thus shares the exact same gas cost.
+
+### Dependency on EIP-3508
+
+The `ENTRYPOINT` (`0x4a`) instruction alone has no perceivable benefit as it can be replaced by the `AUTHCALL` (`0xf7`) instruction and as such should solely be introduced to the system in conjunction with the `ORIGINDATA*` opcodes defined in [EIP-3508](./eip-3508.md).
+
+## Backwards Compatibility
+
+The EIP does not alter or adjust existing functionality provided by the EVM and as such, no known issues exist.
+
+## Test Cases
+
+TODO.
+
+## Security Considerations
+
+### Introspective Contracts
+
+The `ENTRYPOINT` instruction allows the association of the `ORIGINDATALOAD` and `ORIGINDATACOPY` values with a particular smart contract address and interface, enabling introspection to be applied based on the function signature invoked and the arguments provided to reliably deduce the call-path via which a particular smart contract was invoked and allowing a more granular level of interaction to be defined in such special cases.
+
+However, this type of introspection should solely be applied on pre-approved contracts rather than user-defined ones as the value stemming from this type of introspection entirely relies on a contract's code immutability and proper function, both of which a user supplied contract can easily bypass.
+
+### Caller Discrimination
+
+The instructions of this EIP should not be utilized as a way to discriminate between EOA callers and smart contracts, as this type of differentiation can be broken by an `AUTHCALL` as defined in the specification chapter.
+
+### Contract Creation Behaviour
+
+The behaviour of the `ENTRYPOINT` opcode during a contract creation will result in the opcode yielding the zero-address as the first address interacted with in the transaction. This should be taken into account by contract implementations in a similar fashion to how `ecrecover` invalid signatures are handled to prevent software misbehaviours from arising.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).