Make lamports per signature dynamic

[michaelh-laine]

Is your feature request related to a problem? Please describe.
Solana will in the near future introduce more complex transaction fee pricing and there won't be a singular "lamports per signature" value. Transactions will be priced more accurately based on the compute units they consume.

Describe the solution you'd like
Octane would need to pull the fees from the chain for each transaction as it isn't reliable to assume a fee in advance. This is not an issue right now but for future proofing this is important.

[CMEONE]

Adding on to that, it would be good to adjust how token amount is configured to adapt for the new fee model.

1. Token amount should be configured using a tokens per lamport model, so if the fee increases, the token amount should increase proportionally.
2. We might want to potentially add a "slippage" parameter of some sort to accurately reflect the lack of reliability for assuming fees. For instance, if the fees aren't consistent from more recent transactions, the token amount should be higher to account for this discrepancy in case the fee ends up being higher than expected.
3. Not really related to fee model, but in general, the conversion rates between Solana and the token change, so although the Octane relayer manager could update the configuration every few hours or once a day, it might be good to have a way to dynamically pull data from DEXes for the conversion rate between tokens and Solana if trading pairs exist (for instance, we could have a parameter for a Serum market).

If there is any time where the fee to send through Octane is cheaper than sending directly, this is an arbitrage opportunity especially for bots that send a lot of transactions on the network. It's probably better to lean on the side of charging a bit more for the transaction in the token (in terms of #2 and #3) rather than less, since if a relayer is found to be giving discounts on transactions, the relayer's wallet might be drained fairly quickly.

[michaelh-laine]

The relayer would also want an economic incentive (haven't figured out the economic model in detail but there must be some form of payment? I'd expect this to be reflected in the exchange rate).

As to point 2. "Slippage" it would be nice to have a "max fee" but with the final fee being dynamic up to that max amount based on the actual final fee on the network.

Would also be cool to add options for relayers to auto-convert the received tokens to SOL through a DEX, this way they benefit from the slightly better exchange rate with no future exchange risk

[jordaaash]

This is kind of mentioned in #5 but it may be possible to structure the tx so that the user has to swap for SOL then pay the relayer in kind instead.

However this doesn't leave as much headroom for compute or accounts in the tx. We'd probably want to get some numbers on compute use.

I've had some inbound interest from games and other platforms that have some kind of utility token that they'd like to use for gas.

I also think for something like USDC, a merchant using Solana Pay would be happy to pay tx fees for purchases at the merchant, so the fee model doesn't necessarily need to be complex upfront.

What do you think about us working on specific use cases / endpoints like this before approaching the general relayer use case first?

[jordaaash]

The idea for most of this is that we could have multiple endpoints that do different things and someone running Octane can choose between them and configure, so the structure and security IMO is more important than the specifics.

[CMEONE]

it may be possible to structure the tx so that the user has to swap for SOL then pay the relayer in kind instead.

I don't think this would work, but it's not for the reasons you mentioned (compute and account limits). In swapping SPL tokens to SOL, swap accounts need to be set up, which requires a rent fee. If the user pays for the rent fee, they must already have SOL to do that and could have just paid the transaction fee as normal (without a relayer), and if the relayer pays for the rent fee, then the user can just close the account in the next transaction to refund the rent cost back to them, so people could use this loophole to gain a lot of free SOL from the relayer's wallet.

I've had some inbound interest from games and other platforms that have some kind of utility token that they'd like to use for gas.

I also think for something like USDC, a merchant using Solana Pay would be happy to pay tx fees for purchases at the merchant, so the fee model doesn't necessarily need to be complex upfront.

I was thinking exactly that, Solana Pay and games were the two use-cases that first came to mind when thinking about where Octane could be used. In fact, @SolBlazeOrg was already planning on hosting a USDC fee paying system for Solana Pay based on Octane, which would further reduce the friction for adoption on the merchant side if the SolBlaze Octane relayer was integrated at the wallet level.

The idea for most of this is that we could have multiple endpoints that do different things and someone running Octane can choose between them and configure, so the structure and security IMO is more important than the specifics.

I think that might be best given all of the different ways a relayer could operate (stablecoins, non-stable SPL tokens, a range of multiple possible SPL tokens, feeless if user only interacts with specific program, etc.).

[jordaaash]

In swapping SPL tokens to SOL, swap accounts need to be set up, which requires a rent fee.

I think this may only be true for some DEXs. I don't believe AMM-style DEXs like Orca or Raydium require this. Bonfida/dex-v4#30 in the dev branch of Serum appears to implement an atomic Swap instruction that doesn't seem to require an account being created for the user. Perhaps I don't follow?

if the relayer pays for the rent fee, then the user can just close the account in the next transaction to refund the rent cost back to them, so people could use this loophole to gain a lot of free SOL from the relayer's wallet.

This seems relatively simple to prevent with Octane's instruction inspection -- just make sure the user included an instruction to close the account in the same transaction and refund it to Octane. The complexity of structuring this tx can be handled by a dapp or wallet.

[CMEONE]

If there's a way to do it without an account, that could work, or yes we could have an instruction to close the account with the refund to Octane to ensure that a user can't steal the rent fees from Octane. However, that will still add extra instructions and compute, so it won't be super optimized and will likely be suited for more simple transactions. However, this same method could be used to allow for feeless swaps using Octane, which could be an interesting use-case.