The DBXEN Protocol Fee Formula

The formula to calculate the protocol fee is given by:

PF=GS×(1−0.00005×NB)×NB

Where:
PF is the Protocol Fee.
GS is the Gas Spent.
NB is the Number of Batches.

Scenario 1: Burning One Batch

When burning just one batch, the number of batches NB is equal to 1. The fee for burning one batch is almost the exact amount of gas spent, reduced by a very small factor (0.99995 times the gas).

PF(1batch)=GS×(1−0.00005×1)×1
PF(1batch)=GS×(1−0.00005)
PF(1batch)=GS×0.99995

Scenario 2: Burning 10,000 Batches

When burning 10,000 batches, NB is equal to 10,000. When burning 10,000 batches, the total cost increases simply due to the sheer number of batches, but there's a 50% discount per batch. Essentially, each individual batch is subjected to a larger discount compared to the one before.

PF (10,000batches)=GS×(1−0.00005×10000)×10000
PF (10,000batches)=GS×0.5×10000
PF (10,000batches)=5000×GS

Comparing the Two Scenarios

So to summarize, while the absolute cost for 10,000 batches is high, the cost per batch is halved, leading to significant savings when burning in bulk.
Meaning, if you burn batches individually, each time you'll pay nearly the full gas cost, but if you burn 10,000 batches all at once, the average fee per batch is just half the gas cost.
Hence, you'd achieve better economies of scale by burning XEN for DBXEN in larger quantities.

Reference

DBXEN LITEPAPER: https://dbxen.gitbook.io/dbxen-litepaper/dbxen-functionalities

Excerpt:

Access Lists and Gas Savings

Access lists were introduced with EIP-2930 (came online with the Berlin network upgrade on Ethereum at block 12,244,000 on April 15, 2021) in the context of the Ethereum network to optimize the gas usage of transactions, especially when contracts access storage.

Prepayment at Discounted Rates:
By specifying storage slots and addresses upfront in the access list, the EIP-2930 transaction allows you to prepay the "cold access" of these storage slots at a discounted rate. Cold storage access is typically more expensive because the Ethereum Virtual Machine (EVM) has to fetch this data for the first time. By prepaying, you effectively avoid the higher cost associated with on-the-fly fetching during the actual execution.

Optimized Execution:
Since the Ethereum node is made aware of which storage slots will be accessed during the transaction's execution, it can prefetch these values. This prefetching means that during execution, only the "warm fee" is paid, which is typically lower than the cold fee. This optimization reduces the computational overhead, leading to gas savings.

Less Surprise Costs:
One of the challenges with executing smart contracts is unpredicted costs due to storage reads and writes. By specifying an access list, the transaction sender has better predictability over the gas consumption, which can lead to fewer surprise costs.

Application to the DBXen Protocol:
Given that the DBXen Protocol calculates the protocol fee based on the gas consumed for the burn, optimizing the gas usage can directly translate to savings on the protocol fee. By utilizing an access list and pre-specifying the storage keys and addresses that the burn function would interact with, users can:

• Reduce the overall gas used for the transaction.
• Have a more predictable gas estimate for their transaction.
• Potentially pay a lower protocol fee since it's calculated based on gas consumed.

DBXEN Example:

As can be seen in the JSON structure above, it specifies two addresses and their respective storage keys to be accessed during the transaction. As these are the keys relevant to the burn function in the DBXBen Protocol, by including them in an access list, users has achieved further optimization and cost reduction.

I haven't tested this, but adding access keys to DBXEN Ethereum transaction should be as easy as just adding another accessList parameter to your transaction:

# Transaction details
nonce = w3.eth.getTransactionCount(from_address)
gas_price = w3.eth.gasPrice
chain_id = w3.eth.chainId

# Access list 
access_list = [
    {
        "address": "0xf5c80c305803280b587f8cabbccdc4d9bf522abd",
        "storageKeys": [
            "0x0000000000000000000000000000000000000000000000000000000000000006",
            # ... other storage keys for this address
        ]
    },
    {
        "address": "0x06450dee7fd2fb8e39061434babcfc05599a6fb8",
        "storageKeys": [
            "0x6bbdb462c01c928cab3f983428335ef08af69ac4d8f9eadb09c31648c796ec2a",
            # ... other storage keys for this address
        ]
    }
]

# Create the transaction data
transaction = {
    'to': 'TO_ADDRESS',
    'value': w3.toWei(0.1, 'ether'),
    'gas': ....,
    'gasPrice': gas_price,
    'nonce': nonce,
    'chainId': chain_id,
    'accessList': access_list
}

# Sign the transaction
signed_tx = w3.eth.account.signTransaction(transaction, private_key)

This way, the accessList specifies a list of addresses and storage keys and a gas cost is charged, though at a discount relative to the cost of accessing outside the list.

I am unsure of the total discount, but EIP proposes only a 10% initial discount to access lists, so the additional DBXEN discount could be somewhere in this range and combined with max batching transaction could easily become 60% cheaper when compared to a single batch burn without access lists.

Comparison of two methods

EIP-2930 Access Lists

A detailed specification and rationale behind access lists are provided here: https://eips.ethereum.org/EIPS/eip-2930

s3py

This is the gasWrapper function that's in the DBXEN contract:

You're correct that this is looks different from what we see in the litepaper, but it's really the same. The 5 in the equation corresponds to the 0.00005 from the whitepaper formula because MAX_BPS = 100,000, which comes also from the smart contract:
uint256 public constant MAX_BPS = 100_000;

So the calculation is:
discount=batchNumber×(100,000−5×batchNumber)

Both formulas are essentially the same, the only difference is that the representation in the contract has accounted for finer granularity (with MAX_BPS = 100,000).

Now, the part that isn't in the litepaper is the addon of 39400 gwei and @razvancostin14 can comment on why that was added as a constant overhead into the gasWrapper function, but it's likely a gas buffer to account for a gas consumption related to executing the rest of the code (something Raz hinted about).

I guess the main reason this wasn't captured in the original litepaper was to give a high-level overview instead of the technical details that would complicate the narrative for a general non technical audience. If this is the cost to complete the execution, 39400 gwei overhead would not be a central part of the project's value proposition and I guess it shouldn't be featured in the mathematical formula either (albeit it could be a note somewhere in the appendix for the technical audience).

@joe this is some good information... as I said, I've never tested it, so I went by the official documentation which says the initial discount is 10%:

Reference:
EIP-2930: Optional access lists
https://eips.ethereum.org/EIPS/eip-2930

So I guess, based on your research 10% is a minimum and the real discount could be as high as 40% (from what we can see from your screenshots). Good research, thanks for further digging into this.