mirror of
https://github.com/luxfi/dex.git
synced 2026-09-24 00:26:31 +00:00
zeekayandHanzo Dev
d9da4dd317
executeImport refused only when the C chain id was empty. executeExport also refused when shared memory was nil. The plugin server sets a C chain id unconditionally and leaves shared memory nil whenever the node wired no atomic server, which is the state of every live network today — so on the import side 60 self-authored bytes named a beneficiary and an amount and became real, spendable balance, with no C-side debit anywhere behind them. verifyImports exists to catch exactly that, and returned nil on the same nil handle. Its reason was that "executeImport rejects without a C chain id": true, and never the condition that holds. Both guards keyed on the wrong fact, and the two holes covered for each other. Bind both halves to the same condition. Execution refuses the credit without shared memory; the block that carried the import is rejected rather than accepted unproven. Either alone is sufficient, which is why there are two. A block carrying no import is unaffected — the check is per-import, so an absent rail is not an error, only crossing on one is. commitAtomic's nil-shared-memory branch asserted this was already unreachable while committing the state anyway and dropping the op. Now that both producers really do refuse, make the claim self-enforcing: accumulated ops with nothing to apply them to stop the node, the same answer an Apply that errors already gets. Co-authored-by: Hanzo Dev <[email protected]>