avoid external links

Author: bbjubjub2494

ERCS/erc-8270.md

@@ -22,14 +22,16 @@ In order to avoid fragmentation, there should be one standard wrapper contract.
 
 ## Specification
 
-The smart contract source code for this ERC is available at https://github.com/bbjubjub2494/erc-8270, and can be deployed trustlessly using Arachnid's deterministic deployment proxy. It consists of a minimal withdrawal receiver contract which is deployed using a proxy for each NFT, and the main contract, which implements the [ERC-721](./eip-721.md) interface as well as the metadata and enumeration extensions.
+The Vyper source code for the wrapper is included in the ERC repository, along with a Python script generating deployment parameters. It can be deployed trustlessly using a well-known deterministic deployment proxy. The system has two smart contracts: a minimal withdrawal receiver contract which is deployed using a proxy for each NFT, and the main contract which implements the [ERC-721](./eip-721.md) interface as well as the metadata and enumeration extensions.
+
 The main contract allows anyone to mint a token associated with a specific validator public key. A proxy contract is immediately deployed to a unique withdrawal address. Holding the token confers full control over the withdrawal address and thus, once the validator is deployed, of its stake. More specifically, the main contract offers the following bespoke methods for the token holder to call:
 - `pullNativeBalance(tokenId, destination)` move the ether in the withdrawal address to the destination via a call.
 - `requestFullWithdrawal(tokenId)` use [EIP-7002](./eip-7002.md) to force an exit of the validator. The EIP-7002 fee will be paid from the balance of the withdrawal address. If necessary, the caller can add value to the call that will first be added to the withdrawal address balance.
 - `requestPartialWithdrawal(tokenId, amount)` use EIP-7002 to withdraw part of the validator's consensus layer balance. The fee is handled as described previously.
 - `requestConsolidation(tokenId, targetKeyHi, targetKeyLo)` send and [EIP-7251](./eip-7251.md) request to consolidate the validator's stake into another validator. The fee is handled identically to the EIP-7002 fee.
 - `requestSwitchToCompounding(tokenId)` special case of the previous function to consolidate the validator into itself in order to make it compound its rewards on the beacon chain.
 - `arbitraryCall(tokenId, target, data)` perform an EVM call from the withdrawal address, forwarding the call value passed by the caller. This is intended to be used for anything not anticipated by this ERC, such as collecting airdropped tokens.
+
 In addition, the main contract implements [ERC-5646](./eip-5646.md), which allows other contracts to query the implementation-defined state fingerprint of a given token. Since information about validators is not synchronously accessible on the execution layer, the token state in this ERC is defined as the list of past actions performed through the main contract that could affect the funds of the validator, i.e. consolidation requests, pulling the execution layer balance and performing arbitrary calls.
 
 ## Rationale
@@ -38,7 +40,7 @@ In addition, the main contract implements [ERC-5646](./eip-5646.md), which allow
 The decision to use non-fungible tokens stems from the fact that one unit of stake in one validator is not inherently interchangeable with one in another, since both validators can earn different rewards, get slashed, or exit independently from one another. A complex layer of abstraction would be necessary to make them fungible, which we avoid for the sake of minimalism. Wrappers on top of this ERC can implement their preferred fungibility concept if desired.
 
 ### ERC-5646
-Implementing ERC-5646 counters the attack vector described in [[#Collateral Value]], only using one storage slot per token. It also allows wrapped validators to be used as collateral in generic trustless lending protocols such as [PWN](https://pwn.xyz/).
+Implementing ERC-5646 allows smart contracts to cheaply compare the state of a wrapper to a known good state, to ensure that the owner did not change it unexpectedly. Without this, it would be difficult to prevent certain front-running attacks.
 
 ### CREATE2 salt
 When a user requests a token be minted, the resulting withdrawal address depends only on the user provided validator key and initial owner address. This means that withdrawal addresses are predictable (but not ERC-721 token ids) and thus that validator deposits can safely be performed ahead of time. This also protects in some reorg scenarios. Since the owner address is also included, this is not a DoS vector.
@@ -56,7 +58,8 @@ The existence of an wrapped validator token does not guarantee that a validator
 Smart contracts dealing with wrapped validator tokens can use [EIP-4788](./eip-4788.md) to verify proofs of the validator's state if needed.
 
 ### Deposit Front-running
-If no deposit has been made for a given validator yet, care should be taken to deal with deposit front-running by the party holding the validator key. ([An attack described in detail here](https://ethresear.ch/t/deposit-contract-exploit/6528)) There are two trustless ways to address this: one is to require the party to perform a 1 ETH pre-deposit to set the credentials, the other is to use the deposit contract Merkle root to detect the attack and revert the deposit. If [EIP-8025](./eip-8025.md) is activated, it can also be used to mitigate this attack.
+Per [the Consensus Specifications](https://github.com/ethereum/consensus-specs/blob/6370819a35e9558822ef024126cc09ee3666827d/specs/phase0/beacon-chain.md#deposits), if multiple deposits with the same validator key are made, only the withdrawal credentials of the first deposit are taken into account. As a result, a party that knows the validator key can steal funds by front-running the intended first deposit with their own deposit, putting in place withdrawal credentials they control and capturing the funds from the original deposit.
+There are two trustless ways to address this: one is to require the party to perform a 1 ETH pre-deposit to set the credentials, the other is to use the deposit contract Merkle root to detect unexpected deposits and revert. If [EIP-8025](./eip-8025.md) is activated, it can also be used to mitigate this attack.
 
 ### Slashing and Penalties
 The validator can leak or get slashed if its operator misbehaves. This issue can be handled economically by ensuring the operator retains exposure to a fraction of the validator's stake that can be seized in case the value of the stake goes down. This is also why wrapped validator tokens should not be naively bought or sold.