Required submission information
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
|
Note: A full history of changes to Submissions should be reflected in a Maker’s GitHub repository in order to enable the Poster and/or Judges to confirm fulfilment of the Submission Requirements.

Additional Recommendations
- Optional: Demonstration video. View here for recommended topics.
- Ideal submissions will not contain changes to the EOSIO software, only smart contract code and related tooling.
- Ideal submissions will contain documentation for querying EVM contract state and account balances etc.
See rules for further details.