MetaFlux 0.8.10 — Withdrawals that pay, transfers that keep the remainder

This release is live. MetaFlux 0.8.10 swapped in at block height 15,250,000 on chain 114514, and all five validators are running it. Most of what it carries is not new capability — it is four defects on the paths that move your money, and each one is described below with what it did rather than what it was called.

A withdrawal could be signed correctly and still never pay — The exchange and the destination contract were counting the same signatures against two different tables. The exchange weighed each validator by its stake, the contract weighed all five equally, and the exchange therefore treated a withdrawal as complete on three signatures where the contract requires four. It then stopped collecting. The release closes it from both ends: the exchange keeps accepting signatures after it has enough of its own, and it now submits only a set the destination contract will actually accept, checking each signature the way the contract will before sending it. On the live validator weights, roughly one withdrawal in five was exposed to this — with no attacker and no operator error, only the order in which validators happened to sign. Any withdrawal set up under the old behaviour is not repaired by code; that is a separate action.

A partly-failed batch was recorded as fully paid — Withdrawals are submitted in batches, and a batch can confirm while skipping one entry inside it. The exchange read only the transaction's overall status, so a skipped withdrawal was marked released and its record was cleared — deleting the evidence that it had never been paid. Release is now recorded only when the destination reports that specific withdrawal succeeded. A batch is also capped in size now, so a large queue can no longer build one submission that cannot fit in a block.

Deposits credit again — The deposit watcher had not been running since August 10. Nothing polled, nothing warned, and a deposit simply sat in custody with no signal that anything was wrong. That is the worst shape a fault can take, so it is worth being plain about it: at least one deposit sat uncredited for over a day. The watcher is re-enabled by a governance action taken at this upgrade rather than by a restart, and deposits made while it was dark credit when it resumes. If you deposited and saw nothing, you do not need to do anything.

Core to EVM transfers stop losing the remainder — A transfer to MetaFluxEVM is rounded down to the precision the destination token can represent. The debit took your full amount while the credit took the rounded one, and the difference was destroyed on both sides — small per transfer, but real, and it came out of the sender every time. The debit now equals the credit exactly, and the remainder stays in your balance. An amount too small to credit at all is refused rather than accepted for nothing.

sendToEvmWithData is available again, and one of its fields no longer lies — This action moves a spot token to MetaFluxEVM and runs a payload against the recipient. It was withdrawn earlier and is back. The field that names a destination chain used to be signed and then ignored: if you named another chain, the value was delivered locally and nothing told you. It now accepts only the local chain and refuses anything else. Two other fields behave the same way — they are refused rather than silently dropped. In particular, source_dex must be 0. A payload built for the older behaviour carries 1, and that payload is now rejected, so this is the row to check before you re-send one.

Buying power stops over-advertising — The figure reported as available to trade was resolved from a market's published maximum leverage, while admission applies a cap derived from the maintenance requirement. The two disagreed, and the read was the optimistic one — measured at 72% too high on SOL. It now reports the number admission actually applies, so an order sized from it is not refused for a reason the interface never showed you. This corrects the reading flagged in the 0.8.6 notice.

Chase orders no longer starve their own queue — The limit on how many chase orders may exist and the budget for repricing them per block were set independently and disagreed. Once the registry filled, orders past a certain point stopped being repriced at all rather than every order slowing down evenly. The three numbers are now bound to each other so they cannot drift apart again, and the change takes effect one block after the activation height.

A transfer fee exists in this release and charges nothing — You will find a fee described on both Core to EVM transfer actions in the reference. It is currently zero, so no fee is taken. It is set by chain governance and can become non-zero without a client release, which is exactly why it is documented now rather than when it starts charging. No read returns the amount, so a client cannot pre-compute it; if it is ever armed, the refusals are the signal. Two of those refusals do not depend on the token you are moving, which is the part worth reading before you build against it.

One thing this release does not fix — MTF still cannot be withdrawn through the bridge. Only USDC is held in custody, so a request for anything else is refused cleanly rather than leaving a balance in limbo. That is deliberate, not an oversight, and changing it is a custody decision rather than a code one.