I've got a transaction where I've already signed bytes and am ready to inject the operation.

If I inject it to my local node, I can see the txn in my nodes' mempool. But if I query another node, say giganode.io, it's not in their mempool, and not in mempool of other nodes I manage. The operation is inside the "applied" section of my mempool, indicating there is nothing wrong (ie: all fees are good, counter good, etc).

Eventually the txn disappears from my node; having never propagated.

I repeat the injection on to giganode. Now, I can see the txn in giganode's mempool, but not in the mempool of any other nodes. Eventually it disappears.

I can repeat this process over and over on any node which accepts injections. The txn appears only in the local node's mempool and never p2p's out to the network.

What would be the cause of this? What is fundamentally wrong with this txn that it won't go out to the network? Here's one such /mempool/pending_operations grab:

  "applied": [
      "hash": "ong6pLVyneQnE7GafJs4BLqvo4DjYJpcbPQusgRJ3tp8mnBTF7H",
      "branch": "BLaCmxW59eNLNWqvRMCoNxrxPo91pjwfx16knVdYZybPzbKmGfE",
      "contents": [
          "kind": "transaction",
          "source": "tz1eXXXXX",
          "fee": "1792",
          "counter": "5183887",
          "gas_limit": "15385",
          "storage_limit": "257",
          "amount": "516458",
          "destination": "tz1ZZZZZ"
      "signature": "sigRoymL59X2JB8WiiabowKSSSSSSS"

The op never leaves 'applied'. No error messages ever attached to the op. It just silently disappears after about 30m.


I don't agree that the mempool behavior indicate that the fee is all good. On the contrary. Public nodes like Giganode generally don't reject operations based on fee in the prevalidation, while most other nodes do apply the default filter. The fee is most likely too low. I don't know exactly how many bytes you got there, but increasing the fee with 10 mutez will probably do the trick.

| improve this answer | |
  • This operation, tzkt.io/oo8LxSZzYaA7qjCdSTqh9tHM1xmG5YRPvv5ng5PwTqYKNMjgjzT, has less fees, less gas, less storage, and processed/propagated right away. Why would I need an even higher fee? I'll certainly give it a try though. – utdrmac Sep 14 at 0:42
  • In both these transactions there are only enough fee to pay for 153 bytes. 1792 - 1539 - 100 = 153 & 1284 - 1031 - 100 = 153 The reason that the one with a storage limit on 257 fails is that it requires an extra byte. You need to increase the fee with at least 1 mutez. When I count bytes in your operation I get it to 154 bytes. – Klassare Sep 14 at 2:53
  • Yep. Increased fee to 1800 and this time it processed. I don't understand why though. This operation, tzkt.io/opMzVvUsnnXL6ha14CBcEF5hWyoRuJ4VRVmeW6H7XkJN6hYDT7L/…, used 1792 and processed fine. This one also had a storage limit of 257. How are you calculating those values? – utdrmac Sep 14 at 20:42
  • Based on this formula: fees >= minimal_fees + minimal_mutez_per_byte * size + minimal_mutez_per_gas_unit * gas. By default: minimal_fees = 100 mutez, ...per_byte = 1, ...per_gas_unit = 0.1 – Klassare Sep 14 at 21:51
  • You can get the size from the forge result and just count the bytes (including signature). – Klassare Sep 14 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.