Ecosystem v6.4.1

Release Date: August 13, 2026 Tags: DEPOSITS, WALLETS, ADDRESSES, MATCHING-ENGINE, RELIABILITY, HIGH-AVAILABILITY, BUG-FIXES

Overview

A deposits release, and the defect it closes took real money. A chain could be offered for deposit while this deployment had no way to watch it. Generating an address needs no connection to the chain at all, so the customer was given a real, valid address, sent real funds to it — and the monitor that credits the deposit then failed to start. The money arrived on-chain and was never credited here. The only record was a line in the backend log.

An address is now only issued on a network this deployment can actually monitor, and a customer who reaches a currency with no such network is told which check failed rather than being handed an address that leads nowhere.

The matching engine gains the same failover repair as Futures: an engine that was killed hard used to leave the deployment with no matcher at all until somebody restarted it a second time.

Read Upgrade Notes before updating — one entry asks you to check whether any deposit is currently stranded. Requires Core v6.6.5.

Update Instructions

pnpm updator

Restart the backend afterwards. No database change and nothing to run.

After the restart, check the backend log for lines beginning Hiding — they name every enabled token whose network this deployment cannot monitor, and the environment variable to set for each. On a correctly configured install there are none.

Upgrade Notes

A deposit address could be issued for a chain nothing was watching

Put the two halves together and the gap is obvious, but neither half looks wrong on its own. Address generation is pure key material — it never touches the chain, so it succeeds whatever the deployment's connection state. The deposit monitor is what needs a working RPC endpoint, and it is built much later, when the platform tries to watch for incoming transfers.

So the customer's experience was: pick the currency, pick the network, receive an address, send funds. Everything up to that point behaved normally, because everything up to that point genuinely had. The failure happened afterwards, out of sight, when the monitor could not start.

The eligibility rule now asks the full question — is the chain's network named, does it have a working endpoint, and does the chain's own catalogue define it — and it asks it in the three places that matter: the deposit currency list, the deposit network list, and address issuance itself. They all read one definition, so an address can no longer be issued for a network the other two would have hidden.

• Fixed a deposit address being issued for a chain this deployment had no endpoint for. The address was valid and funds sent to it were never credited.
• Check for stranded deposits. If your backend log has been reporting a missing RPC endpoint for a chain, any deposit sent to an address issued for that chain is still on-chain and uncredited. Set the endpoint, restart, and the monitor will pick up the balance.

Withdrawal pricing deliberately still uses the looser rule

One place was left alone on purpose, and it is worth explaining because it looks like an oversight.

When the platform needs to know which stored row describes a token — its fee schedule, its precision, its contract address — every candidate row already belongs to the same chain. The endpoint and catalogue checks cannot tell those rows apart; all they can do is match nothing and fall back to whichever row the database happened to return first.

That row prices withdrawals. Applying the stricter rule there would mean an operator who cleared a chain's endpoint could silently move a customer's withdrawal fee from the mainnet row's schedule onto a leftover testnet row's. So the question "which row describes this token" is still answered by the network name alone, and only the offering surfaces ask "can a deposit be monitored".

• Changed the token-row lookup used for withdrawal pricing to keep matching on the network name only, so a missing endpoint cannot change what a customer is charged.

A hard-killed matching engine stayed read-only

Identical to the repair in Futures v6.1.8, and the same cause. Only one process may run the matching engine, and it holds a lease to prove it. A process killed without shutting down cleanly leaves that lease behind for about twenty seconds; a supervisor restarts the replacement immediately, so the replacement starts inside the window, is correctly refused, and becomes a read-only follower. The lease then lapses with nobody left watching for it.

Every step is individually correct, which is why it survived. The deployment ends up serving normally with no order matching at all, and only a restart that happens to land outside the window fixes it.

• Fixed an ecosystem matching engine that lost the lease at startup never becoming the leader again, leaving the market with no order matching until it was restarted a second time.

Changed

Deposits

• Changed the enabled-token lookup used for deposits to require a network this deployment can monitor, matching the deposit currency and network lists.
• Changed the message a customer meets when no such network exists. It said "No enabled tokens found", which reads as though an administrator switched the currency off; the usual cause is the opposite — the rows are enabled, but name a chain this deployment cannot reach.

Failover

• Changed a follower engine to watch for the matching-engine lease and take over when it becomes free, instead of staying read-only until restarted.

Fixed

Deposits

• Fixed a deposit address being issued for a network with no working endpoint, producing a valid address whose incoming funds were never credited.

Failover

• Fixed a hard-killed matching engine leaving the deployment with no matcher until a second restart.