The Application MUST persist an “Account Table” consisting of

• A unique 160bit account ID
• A nonce (sequence number)
• An EOSIO token balance (aka SYS)
• [optional] A unique associated EOSIO account

The Application MUST persist an “Account State Table” per account, if it would not be empty, consisting of

• A unique 256bit key
• A 256bit value

The Application MUST persist an “Account Code Table” per account, if it would not be empty, consisting of

• EVM bytecode associated with account

The Application MUST execute EVM transactions as faithfully to the Ethereum Yellow Paper as possible with the following notes:

• There will be no effective BLOCK gas limit. Instructions that return block limit should return a sufficiently large supply
• The TRANSACTION gas limit will be enforced
• The sender WILL NOT be billed for the gas, the gas price MAY therefore be locked at some suitable value
• All other gas mechanics/instructions should be maintained
• Block number and timestamp should represent the native EOSIO block number and time
• Block hash, coinbase, and difficulty should return static values

The Application MUST implement an action named “raw”

• Whose inputs are
• A binary Ethereum transaction encoded as it appears in a serialized Ethereum block
• [optional] A 160bit account identifier “Sender”
• Which results in
• Appropriate Updates to Account, Account State, and Account Code Tables reflecting the application of the transaction
• Log output (via EOSIO print intrinsics)
• IF the “R” and “S” values of the transaction are NOT 0
• A transaction containing this action must fail if the signature (V, R, S) within the input does not recover to a valid and known 160bit account identifier in the Accounts Table
• IF the “R” and “S” values of the transaction are 0
• A transaction containing this action must fail if “Sender” input parameter is not present or does not refer to a valid and known 160bit account identifier in the Accounts Table
• If the associated entry in the Accounts Table has no Associated EOSIO Account
• OR if the transaction has not been authorized by the Associated EOSIO Account

The Application MUST implement an action named “create”

• Whose inputs are
• An EOSIO account
• An arbitrary length string
• Which results in a new Account Table entry with
• Balance = 0
• Nonce = 1
• Account identifier = the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the EOSIO account name and the arbitrary input string
• A transaction containing this action must fail if it is not authorized by the EOSIO account listed in the inputs
• A transaction containing this action must fail if an Account Table entry exists with this EOSIO account associated

The Application MUST respond to EOSIO token transfers

• Provided that the EOSIO account in the “from” field of the transfer maps to a known and valid Account Table entry through the entry’s unique associated EOSIO account
• Transferred tokens should be added to the Account Table entry’s balance

The Application MUST implement an action named “withdraw”

• Whose inputs are
• An EOSIO account
• A token amount
• Which results in
• Deducting the amount from the associated Account Table entry’s balance
• Sending an inline EOSIO token transfer for the amount to the EOSIO account
• A transaction containing this action must fail if it is not authorized by the EOSIO account listed in the inputs OR if such a withdrawal would leave the Account Table entry’s balance negative

The Application MAY implement additional actions for maintenance or transaction processing so long as they do not violate the spirit of the execution model above.

The Application MUST implement some method of specifying the “CHAIN_ID” for EIP-155 compatibility.

• This MAY be done at compile time
• This MAY be done with an additional initialization action