One of the biggest selling points for Solana is its ability to provide super cheap transactions no matter the amount of activity happening on the chain because of its feature of local fee markets. But with great power comes great responsibility as gas fee is one of the biggest security measures against spam/attack vectors Solana has been dealing with the issue for a while where many different bots fill up the blockspace with useless transactions and normal users are unable to do anything. As with the concept of local fee markets, it also forms a cap on the dapp blockspace.

Here in the thread, Jito team shares how 585 of the validator processing time is spent on failed mev transactions which clog up the block space and waste the validator, and how in the end only 2% of the mev transactions are actually verified.

a big example of this is especially with defi markets where hft bots are trying to front-run the normal users whenever they see an opportunity to make a buck. As these failed transactions are in nobody's interest but hurt the developers as these txns eat up their dapp blockspace and still not turning up in profit or volume. One of the solutions to this would be the implementation of QUIC.

Solana uses udp (User Datagram Protocol) where the data is sent directly to the other Party without any bi-lateral authentication. Let's say bob sends Alice a packet of data containing the transaction that it wants to process on the chain, Alice being a good validator takes the txn and includes it in the block but seeing the good behavior of Alice Bob starts sending countless small txns to Alice and overflooding its resources, as Alice doesn't really know where the packets are coming from they are unable to block the inflow/spam. This leads to super fast communication but as the IP address and details are not of much concern here Bob could be a spam bot and the chain won't be able to censor it to stop the overflow of packets.

One of the defenses against this is the introduction of QUIC a better version of UDP where a network handshake is done before sending the data packets making it easier for the network ops to censor in case of bad behavior.

One of the other ways of solving this issue is by implementing an application fee which is paid by the user every time they interact with a dapp. It's up to the dapp developer if they wanna use the fee as a source of profit or rebate just to make the dapp more secure/penalize bad behavior like hfts.

• Make sure to check out the SIMD!

As the fee goes to the program account which can then be transferred by the authority of that account(aka developer/team) to another team it incentives developers to onboard more single users rather than just increasing the activity. Something similar to imposing a fee on write instructions has been discussed in the write lock fee issue but one of the demerits is that it would increase fees not just for bad actors but everyone and the dapp won't be able to rebate.

A new native Solana program would be needed to build like App_fee to check the rebates and check transfers to the dapp program. new instructions like set_appfee would be added to the dapp program by developers to set the application to the amount of sol they like.

The final fee would be

\(base\_fee + App\_fee + priority\_fee = total\_fee\)

The App_fee is not rebated when the transaction fails, it decreases the chances of a rogue agent sending useless transactions for the sake of filling blockspace and denying users of transaction verification.  

Ps: a big part of the post comes from the proposal so make sure to check it out if you wanna dive deep! Big shout out to Xoheb for giving me the idea to write about this topic! Joe and Jacob for the feedback!

• Resources used-> https://github.com/godmodegalactus/solana-improvement-documents/blob/application_write_account_fees/proposals/0016-simd-application-fees.md#checkapplicationfees-instructionhttps://github.com/quic-go/quic-go/issues/2586 https://github.com/solana-labs/solana/issues/23211 https://github.com/solana-labs/solana/issues/21883

One of the biggest selling points for Solana is its ability to provide super cheap transactions no matter the amount of activity happening on the chain because of its feature of local fee markets. But with great power comes great responsibility as gas fee is one of the biggest security measures against spam/attack vectors Solana has been dealing with the issue for a while where many different bots fill up the blockspace with useless transactions and normal users are unable to do anything. As with the concept of local fee markets, it also forms a cap on the dapp blockspace.

Here in the thread, Jito team shares how 585 of the validator processing time is spent on failed mev transactions which clog up the block space and waste the validator, and how in the end only 2% of the mev transactions are actually verified.

a big example of this is especially with defi markets where hft bots are trying to front-run the normal users whenever they see an opportunity to make a buck. As these failed transactions are in nobody's interest but hurt the developers as these txns eat up their dapp blockspace and still not turning up in profit or volume. One of the solutions to this would be the implementation of QUIC.

Solana uses udp (User Datagram Protocol) where the data is sent directly to the other Party without any bi-lateral authentication. Let's say bob sends Alice a packet of data containing the transaction that it wants to process on the chain, Alice being a good validator takes the txn and includes it in the block but seeing the good behavior of Alice Bob starts sending countless small txns to Alice and overflooding its resources, as Alice doesn't really know where the packets are coming from they are unable to block the inflow/spam. This leads to super fast communication but as the IP address and details are not of much concern here Bob could be a spam bot and the chain won't be able to censor it to stop the overflow of packets.

One of the defenses against this is the introduction of QUIC a better version of UDP where a network handshake is done before sending the data packets making it easier for the network ops to censor in case of bad behavior.

One of the other ways of solving this issue is by implementing an application fee which is paid by the user every time they interact with a dapp. It's up to the dapp developer if they wanna use the fee as a source of profit or rebate just to make the dapp more secure/penalize bad behavior like hfts.

• Make sure to check out the SIMD!

As the fee goes to the program account which can then be transferred by the authority of that account(aka developer/team) to another team it incentives developers to onboard more single users rather than just increasing the activity. Something similar to imposing a fee on write instructions has been discussed in the write lock fee issue but one of the demerits is that it would increase fees not just for bad actors but everyone and the dapp won't be able to rebate.

A new native Solana program would be needed to build like App_fee to check the rebates and check transfers to the dapp program. new instructions like set_appfee would be added to the dapp program by developers to set the application to the amount of sol they like.

The final fee would be

\(base\_fee + App\_fee + priority\_fee = total\_fee\)

The App_fee is not rebated when the transaction fails, it decreases the chances of a rogue agent sending useless transactions for the sake of filling blockspace and denying users of transaction verification.  

Ps: a big part of the post comes from the proposal so make sure to check it out if you wanna dive deep! Big shout out to Xoheb for giving me the idea to write about this topic! Joe and Jacob for the feedback!

• Resources used-> https://github.com/godmodegalactus/solana-improvement-documents/blob/application_write_account_fees/proposals/0016-simd-application-fees.md#checkapplicationfees-instructionhttps://github.com/quic-go/quic-go/issues/2586 https://github.com/solana-labs/solana/issues/23211 https://github.com/solana-labs/solana/issues/21883