Facet V2 Transaction Structure

The Basics

To create a Facet transaction you send a successful (receipt status = 1) Ethereum transaction to the Facet inbox address (0x00000000000000000000000000000000000face7) with an encoded Facet transaction in its calldata.

Facet transactions are encoded as EIP-2718 transactions, but as they have different fields than existing Ethereum transactions they have their own tx type which is 0x46 (70 in decimal). 0x46 is the ASCII code for the letter F.

The Facet payload format is:

0x46 ++ rlp_encode([chain_id, to, value, max_fee_per_gas, gas_limit, data])

Where ++ denotes binary concatenation. For Facet mainnet chain_id will be 0x0face7, for testnet 0x0face7a. The other fields should be familiar:

  • To: The recipient's address. Can be an EOA or smart contract address, or, when left empty, this field signifies you are creating a new Facet smart contract.

  • Value: The amount of Facet Compute Token that you are sending with the transaction.

  • Max Fee Per Gas: This behaves the same as the corresponding EIP-1559 transaction field, specifying the max amount in FCT wei you are willing to pay per gas unit. Note:

    • On Facet there is no mempool. This means that if your transaction is underpriced (i.e., max fee per gas is less than the block's base fee) it will fail immediately and you will have to send a fresh transaction to replace it.

    • There is no max_priority_fee_per_gas field. Facet transaction priority / ordering is completely determined by L1 transaction ordering.

  • Gas Limit: the maximum number of gas units you're willing to spend. Works like the corresponding field in normal Ethereum transactions.

  • Data: your calldata

What about Ethscriptions?

In Facet V1 payloads were Ethscriptions, not EIP-2718 transactions. There were some advantages to this approach, but Ethscriptions were not the best choice for this specific use-case. There are a few reasons for this. First, the Ethscriptions protocol lacks some important features for the Facet use-case:

  • Ethscriptions are a text-based format which is inefficient for expressing binary data

  • Ethscriptions don't support batching (multiple Ethscriptions per Ethereum transaction)

  • Ethscription creations are event-based which makes it challenging for smart contract wallets

Even if we could upgrade the Ethscriptions protocol to fix these, we would still have the most significant hurdle which is that developers don't want to add a dependency and learn a new protocol unless it adds significant value.

Though the Facet Protocol itself is now separate from Ethscriptions, this is the only change. The creators of the Facet Protocol remain devoted to the growth of the Ethscriptions Protocol.

Last updated