RIP-7759: Layer 2 Transaction Fees

Abstract

---

The document describes the minimal set of business and technical prerequisites, functional and non-functional requirements for Layer 2 Transaction Fees that when implemented ensures that Layer 2 solutions are transparently and consistently calculating and displaying transaction fees.

Motivation

---

Layer 2 (L2) Transaction Fees are a crucial element of financing the operations of L2 platforms apart from rewards given to participants for providing economic security guarantees such as validators in consensus protocols. Yet how these transaction fees are derived, to whom they are paid, how and where they are displayed to any of the participants in L2 platforms varies greatly between L2 platforms.

Given the above, the need for transparency in a open ecosystem to build trust, and the evolving legal and regulatory landscape around fee transparency and what type of fees can be charged, this document sets out to define the different types of L2 transaction fees and then define requirements around transaction fee transparency for L2 platforms.

Hence, the L2 WG of the EEA Communities Project managed by OASIS, an open-source initiative, intends for this document to specify requirements about L2 transaction fees. This document will first:

• Define the meaning of a transaction fee and its components
• Define the roles relevant to transaction fees
• Define transaction types and their relationship to transaction fees

Subsequently, the document will define requirements around fee transparency, fee estimation, final fees, and how, when and where fees are communicated to the different roles. The specification will also discuss requirements around responsibilities and accountability of roles towards one another.

Note, that fees associated with asset and data bridges between L2 platforms as well as between L2 platforms and centralized exchanges are beyond the scope of this document.

Specification

---

Typographical Convention: Requirement Ids

A requirement is uniquely identified by a unique ID composed of its requirement level followed by a requirement number, as per convention [RequirementLevelRequirementNumber]. There are four requirement levels that are coded in requirement ids as per below convention:

[R] - The requirement level for requirements which IDs start with the letter R is to be interpreted as MUST as described in RFC2119.
[D] - The requirement level for requirements which IDs start with the letter D is to be interpreted as SHOULD as described in RFC2119.
[O] - The requirement level for requirements which IDs start with the letter O is to be interpreted as MAY as described in RFC2119.

Note that requirements are uniquely numbered in ascending order within each requirement level.

Example : It should be read that [R1] is an absolute requirement of the specification whereas [D1] is a recommendation and [O1] is truly optional.

Definitions of L2 Transaction Fees and related concepts

This document defines Transaction Fee as the fee in a Layer 2 (L2) network or protocol token to be paid by a Transaction Originator or Transaction Sender comprised of the sum of an Execution Fee, a Data Fee, and a Priority Fee.

Note that this document defines as Transaction as a digitally signed message sent from an L2 account that contains instructions and data that result in an L2 state transition. Also note that this document defines State and State Transition as follows:

• State: The set of all accounts on an L2 that are mapped to one another using a cryptographic data structure.
• State Transition: An event that deterministically changes one or more accounts in the set of all accounts that comprise the complete state of an L2.

Further note that this document defines Account as a unit that is minimally comprised of a unique account identifier, a deterministic ordering parameter, also referred to as a nonce, a balance of a Layer 1, Layer 2 or Sidechain unit of exchange, also referred to as a protocol token. Changes to an account are controlled by a unique cryptographic public and private key pair. There are typically additional account elements referring to instructions and data associated to the account that determine account changes.

In formula form the Transaction Fee is given as:

Transaction Fee = Execution Fee + Data Fee + Priority Fee

The different components are defined as follows:

• Execution Fee: A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover the Layer 2 transaction fees excluding a Priority Fee and a Data Fee.

• Data Fee: A fee to be paid by the Transaction Originator or Transaction Sender sufficient to cover the Layer 1 transaction fees, and any other transaction data fees related to non-Layer 1 data storage, and excluding a Priority Fee and an Execution Fee.

• Priority Fee: Paid by the Transaction Originator or Transaction Sender to obtain a desired slot for its transaction in a new block. Note that the exact position of a transaction, a slot, in a new block may be determined by factors such as time-stamp, or minimization of Maximal Extractable Value (MEV) of a block in addition to a Priority Fee. And that MEV is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block.

Note that a Transaction Fee has a Transaction Fee Price which is defined in the context of this document as an L2 Gas price or a price of an L2 gas equivalent unit of compute and storage consumption.

Note that a Gas price or a price of an L2 gas equivalent unit of compute and storage consumption is typically variable and changes with the level of usage of an L2 network. Note that a gas price is expressed in Giga Wei (GWEI) for EVM-compatible networks, where Wei represents the smallest unit of gas; 1 Wei = 10^-18 Eth in Ethereum's native token.

Furthermore, note that Gas in this document refers to the unit that measures the amount of computational and storage effort required to execute specific operations on an EVM-compatible network.

Definition of L2 Roles relevant to Transaction Fees

The following roles are relevant to transaction fees, their calculation and how, when and where they are presented:

• Transaction Originator: The account that created a transaction for a Layer 1, L2, or Sidechain.
• Transaction Sender: The account that sent a transaction to a Layer 1, L2, or Sidechain.
• Intermediary: An entity that is the sender of a transaction for which it is not the Transaction Originator.
• Sequencer: Collects transactions, publishes them in a batch to the Layer 1 on which the L2 operates, receives transaction fees from the published transactions, pays L2 fees to other L2 protocol participants, and, if required, participates in a consensus algorithm with other sequencers to determine transaction ordering in a block.
• L2 Operator: An entity responsible for the operation of an L2.
• Developer: An individual writing computer code for software applications that operate on a Layer 1, L2 or Sidechain.

Definitions of Transaction Types

There are different types of transactions, and depending on the context transaction fees are paid for differently and by different roles.

There are two types of transactions in the context of this document:

• Direct Transaction: A transaction where the Transaction Originator is also the Transaction Sender.
• Meta Transaction: A transaction where the Transaction Sender is not the Transaction Originator, and the transaction fee for the Transaction Originator is different if the same transaction was a direct transaction.

In the case of a Direct Transaction the Transaction Originator pays for the Transaction Fee based on the Transaction Fee Price the Transaction Originator is maximally willing to pay.

In the case of a Meta Transaction, the Transaction Originator may pay only a portion or no transaction fees at all. Instead, an Intermediary pays all or part of the Transaction Fee. Note that the Intermediary may be the Transaction Sender, or pay the Transaction Sender for the Transaction Fees incurred. Also note that the Transaction Originator may pre-pay Transaction Fees to the Intermediary or the Transaction Sender or both, or submit payment together with the Transaction sent to the Intermediary.

Therefore, the communication of a Transaction Fee and its components is different for different business scenarios. This document will not break down requirements by business scenario but rather by role and if that role is responsible to pay part or all of a Transaction Fee.

Layer 2 Transaction Fee Transparency Requirements

[R1] An L2 Transaction Fee MUST be comprised as the sum of an Execution Fee, a Data Fee, and a Priority Fee.

[R1] Testability: Mathematical equality equations can be tested as the sum of the equations elements equaling a desired output. The test is passed if the sum of the elements as inputs is equal to the desired output. If the sum of the equations element do not equal the desired output the test fails.

[R2] All components of an L2 Transaction Fee MUST NOT be less than zero.

[R2] Testability: Mathematical equality or inequality equations can be expressed as testable conditions. A passing test condition is that each individual element of a transaction fee is equal to or larger than zero. A failing test condition is that one or more transaction fee elements is less than zero.

[O1] An L2 Transaction Fee or any of its components MAY BE zero.

[O1] Testability: Mathematical equality equations can be expressed as testable conditions. A test for [R2] also tests this optional requirement since zero values are allowed in tests for [R2].

[R3] The setting and/or calculation of an Execution Fee MUST be well documented and verifiable.

[R3] Testability:

Preconditions:

• The L2 must have a defined Execution Fee.
• There must be documentation available for the current Execution Fee.
• An L2 instance is up and running.

Test Steps:

1. Verify that there is a documented process for setting and/or calculating the Execution Fee.
2. Verify that the documentation includes the value, specific formula or calculation used to determine the Execution Fee.
3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the calculation.
4. Verify that the documentation is up-to-date and accurate, and that it matches the current Execution Fee being charged.
5. Attempt to independently calculate the Execution Fee using the information provided in the documentation.
6. Verify that the calculated Execution Fee matches the currently charged Execution Fee.

Test Passing Criteria:

• The documented process for setting and/or calculating the Execution Fee must be clear and unambiguous.
• The documentation must include the specific value, formula or calculation used to determine the Execution Fee, as well as any relevant assumptions or dependencies.
• The documentation must be up-to-date and accurate.
• The calculated Execution Fee must match the currently charged Execution Fee.

[R4] The setting and/or calculation of a Data Fee MUST be well documented and verifiable.

[R4] Testability:

Preconditions:

• The L2 must have a defined Data Fee.
• There must be documentation available for the current Data Fee.
• An L2 instance is up and running.

Test Steps:

1. Verify that there is a documented process for setting and/or calculating the Data Fee.
2. Verify that the documentation includes the value, specific formula or calculation used to determine the Data Fee.
3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the calculation.
4. Verify that the documentation is up-to-date and accurate, and that it matches the current Data Fee being charged.
5. Attempt to independently calculate the Data Fee using the information provided in the documentation.
6. Verify that the calculated Data Fee matches the currently charged Data Fee.

Test Passing Criteria:

• The documented process for setting and/or calculating the Data Fee must be clear and unambiguous.
• The documentation must include the specific value, formula or calculation used to determine the Data Fee, as well as any relevant assumptions or dependencies.
• The documentation must be up-to-date and accurate.
• The calculated Data Fee must match the currently charged Data Fee.

[R5] The setting of a Priority Fee MUST be well documented and verifiable.

[R5] Testability:

Preconditions:

• The L2 must have a defined Execution Fee and Data Fee.
• There must be documentation available for the current Priority Fee.
• An L2 system must be up and running.
• An L2 user is configured.

Test Steps:

1. Verify that there is a documented process for setting the Priority Fee by the L2 user.
2. Verify that the documentation includes the specific factors or criteria used to determine and set the Priority Fee.
3. Verify that the documentation includes any relevant assumptions or dependencies that are used in the determination and setting of the Priority Fee.
4. Verify that the documentation is up-to-date and accurate.
5. An L2 user sets a priority fee for a transaction.
6. Verify that the set Priority Fee is correctly added to the Execution Fee and Data Fee to calculate the Transaction Fee.
7. Verify that the calculated Transaction Fee matches the currently charged Transaction Fee for the set Priority Fee.

Test Passing Criteria:

• The documented process for setting the Priority Fee by the L2 user must be clear and unambiguous.
• The documentation must include the specific factors or criteria used to determine the Priority Fee, as well as any relevant assumptions or dependencies.
• The documentation must be up-to-date and accurate.
• The set Priority Fee must be correctly added to the Execution Fee and Data Fee to calculate the Transaction Fee.
• The calculated Transaction Fee must match the currently charged Transaction Fee for the set Priority Fee.

[R6] The L1 Gas Price charged by an L2 and the L1 gas cost of an L2 transaction posted to the L1 and/or to a Data Availability capability as part of a Data Fee derivation MUST be displayed as part of a Data Fee.

Note that the L1 Gas Price charge by an L2 for an L2 transaction may deviate from the L1 Gas Price o the L1 at the time of the L2 transaction.

[R6] Testability:

Preconditions:

1. An L2 application is running in a valid environment.
2. Appropriate user credentials are available for accessing Data Fee information.
3. L1 Gas Price, L1 gas cost, and the estimated data size for an L2 transaction are available and valid.

Test Steps:

1. Navigate to the L2 application's Transaction display section.
2. Initiate the process to post an L2 transaction.
3. Verify that the L1 Gas Price is displayed as part of the Data Fee.
4. Verify that the L1 gas cost is displayed as part of the Data Fee.

Passing Criteria:

• The L1 Gas Price is accurately displayed as part of the Data Fee.
• The L1 gas cost is accurately displayed as part of the Data Fee.

[R7] The L1 Gas Price calculation or method used in a Data Fee derivation MUST be published and verifiable.

[R7] Testability:

Preconditions:

1. An L2 application is running in a valid environment.
2. The L1 Gas Price calculation or method is accessible.

Test Steps:

1. Navigate to the L2 application section responsible for L1 Gas Price calculation.
2. Inspect and identify the calculation or method used in the Data Fee derivation for L1 Gas Price.
3. Ensure that the L1 Gas Price calculation or method is accessible and can be reviewed.
4. Verify that the published L1 Gas Price calculation or method aligns with the documented specifications.

Passing Criteria:

• The L2 application section responsible for L1 Gas Price calculation is successfully accessed.
• The calculation or method used in the Data Fee derivation for L1 Gas Price is identified.
• The L1 Gas Price calculation or method is accessible for review.
• The published L1 Gas Price calculation or method aligns with the documented specifications.

[R8] The utilized L1 Gas Price in an L2 Transaction MUST indicate if it was derived based on a calculation or a Gas Price Data Oracle, or a combination of both.

[R8] Testability:

Preconditions:

1. An L2 application is running in a valid environment.
2. An L2 Transaction is in progress, and the utilized L1 Gas Price is available for verification.

Test Steps:

1. Access the details of the ongoing L2 Transaction.
2. Locate and examine the information related to the utilized L1 Gas Price.
3. Verify that the indication specifying whether the L1 Gas Price was derived from a calculation, a Gas Price Data Oracle, or a combination of both is present.
4. Confirm that the indication aligns with the actual method used for deriving the L1 Gas Price.

Passing Criteria:

• The details of the ongoing L2 Transaction are successfully accessed.
• The information about the utilized L1 Gas Price is identified and available for examination.
• The indication regarding the derivation method (calculation, Gas Price Data Oracle, or a combination) is clearly present.
• The indicated derivation method aligns accurately with the actual method used for deriving the L1 Gas Price.

[R9] The L2 Gas Price as charged by an L2 and the L2 gas cost of an L2 transaction MUST be displayed as part of an Execution Fee.

[R9] Testability:

Preconditions:

1. An L2 application is running in a valid environment.
2. Appropriate user credentials are available for accessing Execution Fee information.
3. L2 Gas Price and L2 gas cost of an L2 transaction are available and valid.

Test Steps:

1. Navigate to the L2 application's Transaction display section.
2. Initiate the process to post an L2 transaction.
3. Verify that the L2 Gas Price is displayed as part of the Execution Fee.
4. Verify that the L2 gas cost is displayed as part of the Execution Fee.

Passing Criteria:

• The L2 Gas Price is accurately displayed as part of the Execution Fee.
• The L2 gas cost is accurately displayed as part of the Execution Fee.

[R10]

[R10]

The L2 Gas Price calculation or method used in an Execution Fee derivation MUST be published and verifiable.

[R10] Testability:

Preconditions:

1. An L2 application is running in a valid environment.
2. The L2 Gas Price calculation or method is accessible.

Test Steps:

1. Navigate to the L2 application section responsible for L2 Gas Price calculation.
2. Inspect and identify the calculation or method used in the Execution Fee derivation for L2 Gas Price.
3. Ensure that the L2 Gas Price calculation or method is accessible and can be reviewed.
4. Verify that the published L2 Gas Price calculation or method aligns with the documented specifications.

Passing Criteria:

• The L2 application section responsible for L2 Gas Price calculation is successfully accessed.
• The calculation or method used in the Execution Fee derivation for L2 Gas Price is identified.
• The L2 Gas Price calculation or method is accessible for review.
• The published L2 Gas Price calculation or method aligns with the documented specifications.

[R11] The utilized L2 Gas Price MUST indicate if it was derived based on a calculation or a Gas Price Data Oracle, or a combination of both.

[R11] Testability:

Preconditions:

1. An L2 application is running in a valid environment.
2. An L2 Transaction is in progress, and the utilized L2 Gas Price is available for verification.

Test Steps:

1. Access the details of the ongoing L2 Transaction.
2. Locate and examine the information related to the utilized L2 Gas Price.
3. Verify that the indication specifying whether the L2 Gas Price was derived from a calculation, a Gas Price Data Oracle, or a combination of both is present.
4. Confirm that the indication aligns with the actual method used for deriving the L2 Gas Price.

Passing Criteria:

• The details of the ongoing L2 Transaction are successfully accessed.
• The information about the utilized L2 Gas Price is identified and available for examination.
• The indication regarding the derivation method (calculation, Gas Price Data Oracle, or a combination) is clearly present.
• The indicated derivation method aligns accurately with the actual method used for deriving the L2 Gas Price.

[R12] An L2 MUST provide a capability to estimate a Transaction Fee based on a given Transaction and the current Operating Conditions of the L2.

Note that L2 Operating Conditions refer to a combination of the current volume of L2 transactions waiting to be processed on an L2 and all the transactions currently being processed on an L2.

[R12] Testability:

Preconditions:

• An L2 system is up and running.
• The L2 must have a defined process for estimating a Transaction Fee based on varying Operating Conditions.
• Operating Conditions must be measurable for the L2, including:
  • The current number of transactions waiting to be processed on the L2.
  • The current number of transactions currently being processed on the L2.
  • The current available L2 resources (e.g. CPU, memory, network bandwidth).
  • The current L2 and L1 gas prices
• The L2 must be configured to adjust the Transaction Fee estimation based on varying Operating Conditions.
• Different sets of test Transactions with varying levels of complexity and number of transactions must be available.

Test Steps:

1. Verify that the L2 can provide a Transaction Fee estimate.
2. Submit a simple test Transaction to the L2 after the first set of test transactions has been submitted to the L2.
3. Record the estimated Transaction Fee provided by the L2.
4. Verify that the estimated Transaction Fee is within an acceptable range of the actual Transaction Fee charged after the L2 transaction has been finalized on the L1.
5. Increase the number of transactions waiting to be processed on the L2 by submitting another test data set with more transactions and submit a complex test Transaction.
6. Record the estimated Transaction Fee provided by the L2.
7. Verify that the estimated Transaction Fee has increased in response to the increase in the number of transactions waiting to be processed and currently being processed.
8. Verify that the estimated Transaction Fee has increased in response to the increase in the number of transactions currently being processed and waiting to be processed.
9. Repeat the test with different test Transactions of varying complexity to ensure that the Transaction Fee estimation process is accurately responsive to changes in Operating Conditions and transaction complexity.

Test Passing Criteria:

• The L2 must provide a Transaction Fee estimate in response to a test transaction.
• The estimation process must take into account the current Operating Conditions of the L2.
• The estimated Transaction Fee must be within an acceptable range of the actual Transaction Fee charged.
• The Transaction Fee estimation process must be accurately responsive to changes in Operating Conditions, with higher Operating Conditions leading to higher estimated Transaction Fees.

[R13] An L2 MUST record and provide access to the Transaction Fee that the Transaction Sender has included in the Transaction when a Transaction has been sent to the L2.

[R13] Testability:

Preconditions:

• An L2 system is up and running.
• The L2 must have a defined process for recording and storing the Transaction Fee included by the Transaction Sender.
• A test Transaction must be available with a known Transaction Fee included by the Transaction Sender.

Test Steps:

1. Submit the test Transaction to the L2.
2. Verify that the L2 has recorded the Transaction Fee included by the Transaction Sender.
3. Retrieve the recorded Transaction Fee from the L2.
4. Compare the retrieved Transaction Fee with the known Transaction Fee included by the Transaction Sender.
5. Verify that the recorded Transaction Fee matches the known Transaction Fee included by the Transaction Sender.

Test Passing Criteria:

• The L2 must have recorded the Transaction Fee included by the Transaction Sender.
• The recorded Transaction Fee must be accessible by the user.
• The recorded Transaction Fee must match the known Transaction Fee included by the Transaction Sender.

[R14] An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been processed by the L2.

[R14] Testability:

Preconditions:

• An L2 system is up and running.
• The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender.
• A test Transaction must be available with a known Transaction Fee charged to the Transaction Sender.

Test Steps:

1. Submit the test Transaction to the L2.
2. Wait for the Transaction to be processed by the L2, and the L2 return a message to the Transaction Sender with the processing result of the test transaction including the transaction fee.
3. Retrieve the Transaction Fee charged to the Transaction Sender from the L2 message.
4. Compare the retrieved Transaction Fee with the known Transaction Fee submitted by the Transaction Sender.
5. Verify that the recorded Transaction Fee matches or is less than the known Transaction Fee submitted by the Transaction Sender.

Test Passing Criteria:

• The L2 must have calculated and recorded the Transaction Fee charged to the Transaction Sender.
• The recorded Transaction Fee must be accessible by the Transaction Sender.
• The recorded Transaction Fee must match or is less than the Transaction Fee submitted by the Transaction Sender.

[R15] An L2 MUST record and provide access to the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on theL2.

Transaction finality in the context of this document is defined as the condition when a transaction can no longer be reverted on an L2. Note that the finality condition will vary by L2, and that L2 finality requirements are outside of the scope of this document.

[R15] Testability:

Preconditions:

• The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender.
• An L2 system is up and running.
• A test Transaction must be available with a known, estimated Transaction Fee to be charged to the Transaction Sender.
• The test environment must have finalized the test Transaction on the L2 according to the L2 finality conditions.

Test Steps:

1. Retrieve the Transaction ID for the test Transaction.
2. Retrieve the Transaction Fee charged to the Transaction Sender from the L2.
3. Compare the retrieved Transaction Fee with the known, estimated Transaction Fee to be charged to the Transaction Sender.
4. Verify that the recorded Transaction Fee matches or is less than the known Transaction Fee to be charged to the Transaction Sender.

Test Passing Criteria:

• The L2 must have calculated and recorded the Transaction Fee charged to the Transaction Sender.
• The recorded and finalized Transaction Fee must be accessible by the user.
• The recorded Transaction Fee must match or be less than the known, estimated Transaction Fee to be charged to the Transaction Sender.

[R16] If there is a Transaction Fee Refund, an L2 implementation MUST record and provide access to the Transaction Fee Refund when a Transaction has been finalized on the L2.

A Transaction Fee Refund in the context of this document is defined as the difference between the Transaction Fee that the Transaction Sender has included in the Transaction sent to the L2 and the Transaction Fee that has been charged to the Transaction Sender when a Transaction has been finalized on the L2.

[R16] Testability:

Preconditions:

• The L2 must have a defined process for calculating and recording the Transaction Fee charged to the Transaction Sender and the Transaction Fee Refund.
• An L2 system is up and running.
• A test Transaction must be available with a known Transaction Fee estimate to be charged to the Transaction Sender.
• The test environment must have finalized the test Transaction on the L2 based on its finality conditions.

Test Steps:

1. Retrieve the Transaction ID for the finalized test Transaction.
2. Retrieve the Transaction Fee charged to the Transaction Sender from the L2.
3. Calculate the Transaction Fee Refund as the difference between the Transaction Fee that the Transaction Sender included in the Transaction and the Transaction Fee charged to the Transaction Sender when the Transaction was finalized.
4. Compare the balance of the users' account protocol token balance minus the estimate Transaction Fee with the balance of the users' account protocol token balance minus the Transaction Fee of the finalized test transaction.
5. Verify that the Transaction Fee Refund from step 3. equals the comparison value in step 4.

Test Passing Criteria:

• The L2 must have calculated the Transaction Fee Refund.
• The Transaction Fee Refund must be accessible by the user.
• The Transaction Fee Refund must match the comparison result of step 4.

[R17] An L2 MUST provide continuous access to the Transaction Fee, the Transaction Fee components, and Transaction Fee Refund, if applicable, of all Transaction finalized on the L2.

[R17] Testability:

Preconditions:

• A test L2 is up and running.
• The L2 must have a defined process for submitting and finalizing Transactions.
• There is a set of test L2 transactions.

Test Steps:

1. Submit a set of Transactions to the L2.
2. Wait for the L2 to finalize the Transactions using transaction confirmation notifications as finalization confirmations.
3. Query the L2 for a Transaction ID from the set of finalized test transactions.
4. For a given Transaction ID, retrieve the Transaction ID, Transaction Fee, Transaction Fee components (Execution Fee, Data Fee, and Priority Fee), and Transaction Fee Refund (if applicable).
5. Verify that the retrieved Transaction Fee, Transaction Fee components, and Transaction Fee Refund (if applicable) match the values recorded in the transaction confirmations.
6. Repeat steps 3. through 5. for each Transaction ID in the set of test transactions at random time intervals during the test for the entire test transaction set.

Test Passing Criteria:

• Steps 3. through 5. are successfully completed for every transaction in the test transaction set, otherwise the test fails.

[R18] An L2 MUST provide a capability that delivers a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on.

[R18] Testability:

Preconditions:

• A test L2 is running and operational
• The L2 has a current Fee Price available
• A Transaction Sender or Transaction Originator is ready to send a transaction on the L2

Test steps:

1. Retrieve the current Fee Price from the L2.
2. Calculate a Transaction Fee based on the Fee Price obtained in step 1.
3. Send a transaction to the L2 with the calculated Transaction Fee.
4. Retrieve the Transaction Fee recorded by the L2 for the transaction sent in step 3.
5. Verify that the Transaction Fee recorded by the L2 matches the calculated Transaction Fee in step 2.

Test Passing criteria:

• The current Fee Price is successfully retrieved from the L2 in step 1.
• The calculated Transaction Fee matches the Transaction Fee recorded by the L2 in step 5.

Layer 2 Transaction Fee Visibility Requirements

In this section, this document discusses the visibility requirements for different L2 Transaction Types and Roles.

[R19] A Transaction Originator, a Transaction Sender and a Developer MUST be able to view an estimated Transaction Fee and its components before an L2 Transaction is submitted.

[R19] Testability:

Preconditions:

• An L2 instance is set up and running.
• A Transaction Originator, a Transaction Sender, and a Developer have access to the L2 and can interact with it.
• The L2 provides a capability to estimate Transaction Fees based on current operating conditions and other relevant factors.

Test Steps:

1. The Transaction Originator, the Transaction Sender, and the Developer navigate to the L2 interface and initiate the process of creating a new transaction.
2. The L2 interface displays the estimated Transaction Fee and its components (Execution Fee, Data Fee, and Priority Fee) to the Transaction Originator, the Transaction Sender, and the Developer.
3. The Transaction Originator, the Transaction Sender, and the Developer proceed to submit the Transaction to the L2.

Test Passing Criteria:

• The L2 interface displays the estimated Transaction Fee and its components accurately.
• The Transaction Originator, the Transaction Sender, and the Developer are able to review and verify the estimated Transaction Fee and its components before submitting the Transaction.

[R20] A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after an L2 Direct Transaction has been processed on the L2.

[R20] Testability:

Preconditions:

• An L2 instance is operational and available for use.
• The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information.
• At least one Direct Transaction has been submitted and processed on the L2.
• The L2 has a defined method to notify L2 users that an L2 transaction has been processed.

Test Steps:

1. Transaction Sender or Developer submit a Direct Transaction to the L2.
2. The L2 processes the Direct Transaction and charges a Transaction Fee.
3. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been processed on the L2 using the Transaction ID from the transaction processing confirmation notification from the L2.
4. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee.
5. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction.
6. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

Test Passing Criteria: The test passes if,

• The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been processed.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

[R21] An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after an L2 Meta Transaction has been processed on the L2.

[R21] Testability:

Preconditions:

• An L2 instance is operational and accepting transactions.
• The Intermediary and Developer have access to the L2.
• The Intermediary and Developer have a Meta Transaction ready to submit to the L2.
• The L2 has a defined method to notify L2 users that an L2 transaction has been processed.

Test Steps:

1. The Intermediary and Developer submit a Meta Transaction to the L2.
2. The L2 processes the Meta Transaction and charges a Transaction Fee.
3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction processing confirmation notification from the L2.
4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee.
5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction.
6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

Test Passing Criteria: The test passes if,

• The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been processed.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Meta Transaction.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

[R22] A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee and its components after an L2 Direct Transaction has been finalized on the L2.

[R22] Testability:

Preconditions:

• An L2 instance is operational and available for use.
• The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information.
• At least one Direct Transaction has been submitted, processed and finalized on the L2.
• The L2 has a defined method to notify L2 users that an L2 transaction has been finalized.

Test Steps:

1. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been finalized on the L2 using the Transaction ID from the transaction finalization confirmation notification from the L2.
2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, Priority Fee.
3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Direct Transaction.
4. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

Test Passing Criteria: The test passes if,

• The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been finalized.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

[R23] An Intermediary and a Developer MUST be able to view a Transaction Fee and its components after an L2 Meta Transaction has been finalized on the L2.

[R23] Testability:

Preconditions:

• An L2 instance is operational and accepting transactions.
• The Intermediary and Developer have access to the L2.
• The Intermediary and Developer have a Meta Transaction ready to submit to the L2.
• The L2 has a defined method to notify L2 users that an L2 transaction has been finalized.

Test Steps:

1. The Intermediary and Developer submit a Meta Transaction to the L2.
2. The L2 processes, and finalizes the Meta Transaction and charges a Transaction Fee.
3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2.
4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee.
5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction.
6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

Test Passing Criteria: The test passes if,

• The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been finalized.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Meta Transaction.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account.

[R24] If there is a Transaction Fee Refund, a Transaction Originator, a Transaction Sender and a Developer MUST be able to view a Transaction Fee Refund after an L2 Direct Transaction has been finalized on the L2.

[R24] Testability:

Preconditions:

• An L2 instance is operational and available for use.
• The Transaction Originator, Transaction Sender, and Developer have access to the L2 and can view Transaction information.
• At least one Direct Transaction has been submitted, processed and finalized on the L2.
• The L2 has a defined method to notify L2 users that an L2 transaction has been finalized.

Test Steps:

1. The Transaction Originator, Transaction Sender, or Developer accesses the L2 to view the Transaction Fee and its components after a Direct Transaction has been finalized on the L2 using the Transaction ID from the transaction finalization confirmation notification from the L2.
2. The Transaction Originator, Transaction Sender, or Developer verifies that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee.
3. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 is equal to or less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction.
4. The Transaction Originator, Transaction Sender, or Developer verifies that the Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account.

Test Passing Criteria: The test passes if,

• The Transaction Originator, Transaction Sender, or Developer can access the Transaction Fee and its components on the L2 after a Direct Transaction has been finalized.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components displayed to the Transaction Originator, Transaction Sender, or Developer before submitting the Direct Transaction.
• The Transaction Fee and its components displayed on the L2 match or are less than the Transaction Fee and its components charged to the Transaction Sender's account, if applicable.

[R25] If there is a Transaction Fee Refund, an Intermediary and a Developer MUST be able to view a Transaction Fee Refund after an L2 Meta Transaction has been finalized on the L2.

[R25] Testability:

Preconditions:

• An L2 instance is operational and accepting transactions.
• The Intermediary and Developer have access to the L2.
• The Intermediary and Developer have a Meta Transaction ready to submit to the L2.
• The L2 has a defined method to notify L2 users that an L2 transaction has been finalized.

Test Steps:

1. The Intermediary and Developer submit a Meta Transaction to the L2.
2. The L2 processes, and finalizes the Meta Transaction and charges a Transaction Fee.
3. The Intermediary and Developer access the Transaction and the Transaction Fee and its components for the processed Meta Transaction using the Transaction ID from the transaction finalization confirmation notification from the L2.
4. The Intermediary and Developer verify that they can see the Transaction Fee and its components, including the Execution Fee, Data Fee, and Priority Fee.
5. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 is less than the Transaction Fee and its components displayed to them before submitting the Meta Transaction.
6. The Intermediary and Developer verify that the Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account.

Test Passing Criteria: The test passes if,

• The Intermediary and Developer can access the Transaction Fee and its components on the L2 after a Meta Transaction has been finalized.
• The Transaction Fee and its components displayed on the L2 are less than the Transaction Fee and its components displayed to the Intermediary and Develope before submitting the Meta Transaction.
• The Transaction Fee and its components displayed on the L2 match the Transaction Fee and its components charged to the Transaction Sender's account.

[R26] An L2 MUST provide an Intermediary with a capability to display the Transaction Fee and its components of an L2 Meta Transaction after it has been processed on the L2 to 3rd parties.

[R26] Testability:

Preconditions:

• A L2 instance is operational and accessible.
• There is at least one Intermediary operating on the L2.
• At least one L2 Meta Transaction has been submitted and processed on the L2.
• The Intermediary can access the Transaction with its Transaction Fee and its Fee components.
• The L2 is accessible by any 3rd party.

Test Steps:

1. The Intermediary logs into their account on the L2.
2. The Intermediary selects the L2 Meta Transaction they wish to view the Transaction Fee and its components for using the Transaction ID from the transaction processing confirmation notification from the L2.
3. The L2 displays the Transaction Fee and its components of the selected L2 Meta Transaction to the Intermediary.
4. The Intermediary verifies that the displayed Transaction Fee and its components match or are less than the submitted Transaction Fee and its components.
5. The Intermediary attempts to display the Transaction Fee and its components of the selected L2 Meta Transaction to a 3rd party.
6. The 3rd party verifies that the displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID.

Test Passing Criteria:

• The Intermediary is able to view the Transaction Fee and its components of the selected L2 Meta Transaction.
• The displayed Transaction Fee and its components are accurate and match the actual Transaction Fee and its components of the selected L2 Meta Transaction.
• The Intermediary is able to display the Transaction Fee and its components of the selected L2 Meta Transaction to a 3rd party.
• The displayed Transaction Fee and its components match the actual Transaction Fee and its components of the selected L2 Meta Transaction as verified by the 3rd party.

[R27] If there is a Transaction Fee Refund, an L2 MUST provide an Intermediary with a capability to display the Transaction Fee Refund of an L2 Meta Transaction to a 3rd party after it has been finalized on the L2.

[R27] Testability:

Preconditions:

• An L2 instance is deployed and running.
• An Intermediary is operating on the L2 and has the necessary permissions to view Transaction Fee Refunds.
• A set of L2 Meta Transactions has been submitted and processed on the L2, resulting in at least one Transaction Fee Refund.

Test steps:

1. The Intermediary sends a request to the L2 to display the Transaction Fee Refund of a specific L2 Meta Transaction using the Transaction ID from the L2's transaction finalization confirmation notification.
2. The L2 receives the request and verifies that the Intermediary has the necessary permissions to view Transaction Fee Refunds.
3. The L2 retrieves the Transaction Fee Refund information for the requested L2 Meta Transaction.
4. The L2 sends the Transaction Fee Refund information to the Intermediary.
5. The Intermediary receives the Transaction Fee Refund information.
6. The Intermediary verifies that the Transaction Fee Refund information matches the expected values based on the difference in the L2 Meta Transaction Transaction Fee between the submitted and finalized L2 Meta Transaction.
7. The Intermediary displays the Transaction Fee Refund information to the requesting 3rd party.
8. The requesting 3rd party verifies that the displayed Transaction Fee and its components match the Transaction Fee and its components for the Transaction ID of the Meta Transaction when accessed directly on the L2 using the Transaction ID.

Test Passing criteria:

• The Intermediary is able to successfully retrieve and display the Transaction Fee Refund information for the requested L2 Meta Transaction.
• The displayed Transaction Fee Refund information matches the expected values based on the L2 Meta Transaction.

[R28] A Transaction Originator, a Transaction Sender and a Developer MUST be able to view a current Fee Price that a Transaction Fee calculation by the Transactions Sender or Transaction Originator can be based on.

[R28] Testability:

Preconditions:

• An L2 instance is live and operational.
• The Transaction Originator, Transaction Sender, and Developer have access to the L2.
• The Fee Price calculation is based on the current Operating Condition of the L2.
• A Fee Price Emulator that can accurately calculate a Fee Price based on current Operating Conditions on the L2.

Test steps:

1. The Transaction Originator, Transaction Sender, or Developer access the current Fee Price from the L2.
2. The L2 responds to the request by providing the current Fee Price.
3. The Transaction Originator, Transaction Sender, or Developer verifies that the Fee Price provided by the L2 network matches the Fee Price estimate using the Fee Price Emulator.

Test Passing criteria:

• The current Fee Price is successfully retrieved from the L2.
• The Fee Price provided by the L2 matches the Fee Price estimate using the Fee Price Emulator.

Transaction Fee Requirements for Layer 2 Transactions

In this section, the documents details Transaction Fee requirements for an L2 Transaction and its processing.

[R29] Every L2 Transaction MUST contain a Transaction Fee and its components.

[R29] Testability:

Preconditions:

• An L2 instance is set up and functional.
• There is a user account on the L2 with the necessary permissions to submit a transaction.
• There is a sufficient balance of funds available in the user's account to cover the transaction fee.

Test Steps:

1. Log in to the user account on the L2.
2. Create a new L2 transaction.
3. Verify that the transaction contains a transaction fee and its components.
4. Submit the transaction.
5. Wait for the transaction to be processed and finalized on the L2.
6. Retrieve the details of the processed and finalized transaction using using the Transaction ID from the transaction finalization confirmation notification from the L2.
7. Verify that the transaction fee and its components are still present and accurate.

Test Passing Criteria:

• The L2 transaction contains a transaction fee and its components.
• The transaction fee and its components remain present and accurate after the transaction is processed and finalized on the L2.

[R30] Every L2 Block MUST contain one or more L2 account addresses to which the accumulated Transaction Fees in said L2 Block are transferred either whole or in proportion based on the specification of the L2 protocol.

[R30] Testability:

Preconditions:

• The L2 protocol and its specifications have been implemented and tested.
• An L2 instance is set up and functional.
• A set of L2 transactions have been created and finalized on the L2.

Test steps:

1. Verify that every L2 block has one or more L2 account addresses specified to receive the accumulated Transaction Fees.
2. Verify that the accumulated Transaction Fees from each L2 transaction in the block have been transferred to the specified L2 account address(es).
3. Verify that the transfer of the accumulated Transaction Fees is done either whole or in proportion to the account addresses specified to receive the accumulated Transaction Fees in the L2 Block.

Test Passing criteria:

• Step 1, 2, and 3 must pass for all L2 blocks that have been finalized on the L2 that contain the test L2 transactions.

[R31] If one or more L2 Transactions are reverted before they are finalized on the L2's Layer 1, the Transaction Fees in the affected Transactions MUST not be charged to the Transaction Senders.

Note, that it is not important why an L2 Transaction has been reverted before it is finalized.

[R31] Testability:

Preconditions:

• An L2 instance is set up and functional.
• There are at least two valid L2 Transactions that have not been finalized on the L2's Layer 1.
• Each L2 Transaction has a valid Transaction Sender.
• The L2 Transactions have Transaction Fees associated with them.
• The L2 protocol supports the reversion of Transactions before they are finalized on Layer 1.

Test Steps:

1. Verify that the initial balances of the Transaction Senders are recorded.
2. Submit the L2 Transactions to the L2.
3. Verify that the L2 Transactions are valid and the Transaction Fees are calculated correctly.
4. Attempt to revert one of the L2 Transactions before it is finalized on the L2's Layer 1.
5. Verify that the reverted L2 Transaction's Transaction Fees are not charged to the Transaction Sender.
6. Finalize the remaining L2 Transactions on the L2's Layer 1.
7. Verify that the Transaction Fees are charged to the Transaction Senders for the finalized L2 Transactions.
8. Verify that the balances of the Transaction Senders have been updated accordingly.

Test Passing Criteria:

• The balances of the Transaction Senders are updated correctly after the L2 Transactions are finalized.
• The Transaction Fees for the finalized L2 Transactions are charged to the corresponding Transaction Senders.
• The Transaction Fees for the reverted L2 Transactions are not charged to the corresponding Transaction Senders.

[D1] If an L2 Meta Transaction is reverted before it is finalized on the processing L2's Layer 1 and the Transaction Originator has been charged the Transaction Fee by the Intermediary, the Transaction Fee in the reverted Meta Transaction SHOULD be refunded to the Transaction Originator by the Intermediary.

[D1] Testability:

Preconditions:

• An L2 instance is set up and available for testing.
• A set of L2 Meta Transactions has been submitted by the Transaction Sender and processed on the L2.
• Some of the L2 Meta Transactions have been reverted before being finalized on the L2's Layer 1.

Test steps:

1. Submit a set of L2 Meta Transactions to the L2.
2. Verify that the Transaction Sender and Developer can view the estimated Transaction Fees and their components before submitting the L2 Meta Transactions.
3. Verify that the Intermediary can view and record the Transaction Fees and their components after the L2 Meta Transactions have been processed on the L2.
4. Revert some of the L2 Meta Transactions before they are finalized on the L2's Layer 1.
5. The Intermediary returns the recorded Transaction Fees for the reverted Meta Transactions from the Transaction Sender Account or the account of the Intermediary to the account of the Transaction Originator.
6. Verify that the Transaction Originator received the Transaction Fee Refund and it has the right value.

Test passing criteria:

• The Intermediary, Transaction Sender and Developer can view the estimated Transaction Fees and their components before submitting the L2 Meta Transactions.
• The Intermediary can view the Transaction Fees and their components after the L2 Meta Transactions have been processed on the L2.
• The Intermediary returns the right amount of Transaction Fees as a refund to the Transaction Originator when L2 Meta Transactions are reverted.

Conformance

This section describes the conformance clauses and tests required to achieve an implementation that is provably conformant with the requirements in this document.

Conformance Targets

This document does not yet define a standardized set of test-fixtures with test inputs for all MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements.

A standardized set of test-fixtures with test inputs for all MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements is intended to be published with the next version of the standard.

Conformance Levels

This section specifies the conformance levels of this standard. The conformance levels offer implementers several levels of conformance. These can be used to establish competitive differentiation.

This document defines the conformance levels of EVM based Address Aliasing as follows:

• Level 1: All MUST requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs.
• Level 2: All MUST and SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs.
• Level 3: All MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs.

[D2] A claim that a canonical token list implementation conforms to this specification SHOULD describe a testing procedure carried out for each requirement to which conformance is claimed, that justifies the claim with respect to that requirement.

[D2] testability: Since each of the non-conformance-target requirements in this documents is testable, so must be the totality of the requirements in this document. Therefore, conformance tests for all requirements can exist, and can be described as required in [D2].

[R32] A claim that a canonical token list implementation conforms to this specification at Level 2 or higher MUST describe the testing procedure carried out for each requirement at Level 2 or higher, that justifies the claim to that requirement.

[R32] testability: Since each of the non-conformance-target requirements in this documents is testable, so must be the totality of the requirements in this document. Therefore, conformance tests for all requirements can exist, be described, be built and implemented and results can be recorded as required in [R32].

Rationale

---

Layer 2 (L2) Transaction Fees are a crucial element of financing the operations of L2 platforms. Therefore, there is a strong need for transparency in a open ecosystem to build trust, and adjust to the evolving legal and regulatory landscape around fee transparency and what type of fees can be charged. Therefore, we need to define the different types of L2 transaction fees and requirements around transaction fee transparency for L2 platforms.

Security Considerations

---

Data Privacy

The standard does not set any requirements for compliance to jurisdiction legislation/regulations. It is the responsibility of the implementer to comply with applicable data privacy laws.

Production Readiness

The standard does not set any requirements for the use of specific applications/tools/libraries etc. The implementer should perform due diligence when selecting specific applications/tools/libraries.

Internationalization and Localization

The standard encourages implementers to follow the W3C "Strings on the Web: Language and Direction Metadata" best practices guide for identifying language and base direction for strings used on the Web wherever appropriate.

Copyright

---

Copyright and related rights waived via CC0.