devemos resolver este problema se quisermos adoção generalizada:

carteiras e aplicativos tratam o estado do nonce como algo privado, apesar de ser dados compartilhados globalmente que vivem no mempool.

sem uma camada de sincronização, diferentes interfaces front-end divergirã e os usuários enfrentarão deadlocks invisíveis, como o que tive hoje.

a correção pode ser:

> expor informações de nonce pendente através de uma API comum e trazer qualquer status "preso" nas interfaces do cliente da carteira + lógica de substituição de prompt para que os usuários não precisem resolver isso sozinhos.

os usuários *nunca* devem tocar em ginástica de nonce ou precisar ser expostos a heurísticas do mempool.

até que essa coordenação exista no nível de aplicativos/carteiras, precisaremos de @basedkarbon & @AgentChud para nos salvar toda vez.

quanto ao que aconteceu, se você estiver curioso:

> cada conta EVM mantém um número de sequência monótono chamado nonce.

> a cadeia só aceitará uma transação cujo nonce = o valor atual em cadeia da conta.

> uma vez que uma transação está pendente, o mesmo nonce é bloqueado até que essa transação seja concluída ou explicitamente substituída.

> eu subestimei uma transação na base, então ela ficou em limbo.

> meu cache local de nonce no rainbow disse que o próximo nonce é "x", mas a rede ainda esperava "n".

a carteira coinbase do rainbow e rabby assinaram novos payloads com o nonce x, mas sem o aumento de gás necessário para satisfazer a regra de substituição, todos os nós os descartaram e nenhuma transação passou.

como usuário, *todas* as carteiras não deram nenhum feedback ao usuário de que este era a raiz do problema.

para implementar efetivamente a solução, @MetaMask me resgatou porque seu painel avançado expõe tanto o nonce quanto os campos de taxas dinâmicas.

eu reenviei uma transferência de 0 eth para mim mesmo com o nonce idêntico ao da minha última transação e uma taxa de prioridade muito mais alta + limite de gás e o backlog foi limpo em segundos.