Gas price flow analysis: 20% markup in getRecommendedGasPrice applies to both estimation and send

[TaprootFreak]

Kontext

Bei der Untersuchung von Transaction 307721 (stuck ETH→ETH Swap, PR #3529) wurde die Gas-Preis-Berechnung im EVM Coin Forward-Pfad detailliert analysiert.

Kernfrage

getRecommendedGasPrice() addiert 20% auf den Basis-Gas-Preis:

// evm-client.ts:162-165
async getRecommendedGasPrice(): Promise<EthersNumber> {
  // 20% cap
  return this.provider.getGasPrice().then((p) => p.mul(12).div(10));
}

Frage: Wird diese 20% Markup in beiden Pfaden (Fee-Schätzung UND tatsächlicher Send) angewendet?

Analyse

Pfad 1: Fee-Schätzung (gecacht, 30s TTL)

EvmStrategy.doSend()
  → SendStrategy.getEstimatedForwardFee()
    → PayoutService.estimateFee()
      → PayoutEvmStrategy.estimateFee()                    // 30s Cache (CacheItemResetPeriod.EVERY_30_SECONDS)
        → EthereumCoinPayoutStrategy.getCurrentGasForTransaction()
          → PayoutEthereumService.getCurrentGasForCoinTransaction()
            → PayoutEvmService.getCurrentGasForCoinTransaction()
              → EvmClient.getCurrentGasCostForCoinTransaction()   // evm-client.ts:809-814
                → gasLimit × getRecommendedGasPrice()             // ✅ 20% Markup

Pfad 2: Tatsächlicher Send

2a) Frische Gas-Kosten Schätzung (nach PR #3529):

EvmCoinStrategy.dispatchSend()
  → PayInEvmService.getGasCostForCoinTransaction()
    → EvmClient.getCurrentGasCostForCoinTransaction()             // evm-client.ts:809-814
      → gasLimit × getRecommendedGasPrice()                       // ✅ 20% Markup

2b) Tatsächliche Transaktion:

EvmCoinStrategy.dispatchSend()
  → PayInEvmService.sendNativeCoin()
    → EvmClient.sendNativeCoinFromAccount()                       // evm-client.ts:308-312
      → EvmClient.sendNativeCoin()                                // evm-client.ts:823-848
        → gasPrice = +(await this.getRecommendedGasPrice())       // evm-client.ts:832 ✅ 20% Markup
        → wallet.sendTransaction({ gasPrice, ... })

Selbe Client-Instanz

Beide Pfade nutzen denselben Singleton:

PayoutEthereumService → EthereumService (Singleton) → EvmClient (eine Instanz)
PayInEthereumService  → EthereumService (Singleton) → EvmClient (selbe Instanz)

Beweis: EvmService.getDefaultClient() gibt immer dieselbe this.client-Instanz zurück (evm.service.ts:4-15).

Ergebnis

Aspekt	Pfad 1 (Schätzung)	Pfad 2a (Frisch)	Pfad 2b (Send)
Methode	getRecommendedGasPrice()	getRecommendedGasPrice()	getRecommendedGasPrice()
20% Markup	✅ Ja	✅ Ja	✅ Ja
EvmClient	Singleton	Selber Singleton	Selber Singleton
Caching	30s Cache	Frisch	Frisch

Die 20% Markup hebt sich auf — sie ist in allen drei Stellen identisch. Der einzige Unterschied zwischen den Pfaden ist die Zeitdifferenz beim Aufruf von provider.getGasPrice():

• Pfad 1 (alt, vor PR Fix native coin forward gas buffer #3529): Bis zu 30 Sekunden Differenz durch Cache → Gas-Preis kann sich ändern
• Pfad 2a (neu, PR Fix native coin forward gas buffer #3529): Wenige Millisekunden Differenz zu Pfad 2b → Gas-Preis ist praktisch identisch

Relevante Dateien

Datei	Zeilen	Rolle
integration/blockchain/shared/evm/evm-client.ts	162-165	getRecommendedGasPrice() mit 20% Markup
integration/blockchain/shared/evm/evm-client.ts	809-814	getCurrentGasCostForCoinTransaction()
integration/blockchain/shared/evm/evm-client.ts	823-848	sendNativeCoin() mit gasPrice
integration/blockchain/shared/evm/evm.service.ts	4-15	Singleton EvmClient
supporting/payout/strategies/payout/impl/base/evm.strategy.ts	17	30s Fee-Cache
supporting/payin/strategies/send/impl/base/evm-coin.strategy.ts	44-54	dispatchSend() (gefixt in #3529)
supporting/payin/services/base/payin-evm.service.ts	26-28	Neue getGasCostForCoinTransaction()

Verwandte PRs

• Fix native coin forward gas buffer #3529: Fix native coin forward gas buffer

[TaprootFreak]

Geschlossen: Die Analyse enthält faktische Fehler (falsche Datei-Zuordnung bei payin-evm.service.ts, Call-Chain von dispatchSend() stimmt nicht) und die Kernaussage ist irreführend formuliert. Die relevante Erkenntnis (30s Cache-Problem) wurde bereits mit PR #3529 gefixt.