Zeddex: why Zeedex v0.3.0 changed its Watcher
Zeedex changed its Watcher in v0.3.0 because short Binance Smart Chain (BSC) block times and incomplete node responses disrupted order-result checks. The update separated the decentralized exchange’s frontend from its Watcher, which repeatedly checked pending transactions and sent successful results to the backend.
- updated
Kyunghun Cheong described the redesign in Zeedex v0.3.0 - The Origin, published on May 15, 2021.
Why the earlier approach caused stoppages
The earlier Watcher ran alongside the blockchain and validated order results. Cheong reported that this approach worked on Ethereum, while shorter BSC block times and incomplete data about blocks and transaction results caused Watcher problems. The release account attributed stoppages of the DEX to those problems.
How the services divided responsibility
- Frontend
- Token enabling and disabling used direct calls to RPC nodes, separate from the Watcher.
- Watcher
- The revised loop checked pending transactions. On success, the Watcher saved data and sent it to the backend for distribution.
- Feed
-
The Watcher emitted a
newTradeevent to backend services. When notified, the Feed calculated updated market data and sent it to clients.
The separate rule for missing transaction results
To address dropped BSC transactions, the team described submitting transactions at the "highest gasPrice", waiting
n
seconds for a result, and treating a transaction as dropped if no result appeared within that wait.
The announcement gave no numerical value for
n
and did not explain how "highest gasPrice" was determined. It therefore supplies no specific timeout or reproducible gas-price calculation. Because the classification was triggered by a missing result, the dropped label alone would not establish an on-chain execution failure.
Example: Interpreting a market refresh
In this hypothetical v0.3.0 BSC case, the Watcher emits
newTrade
for one successful trade while a reader’s separate transaction awaits a result. The reader wants to know whether the market feed can update while that separate transaction remains unresolved.
The Feed would recalculate market data from the first trade’s event and send the update to clients. A market refresh could therefore occur without confirming the reader’s transaction. A successful result for that transaction would trigger the Watcher to save its data and send it to the backend. If no result arrived within the release’s unspecified wait instead, the documented policy would classify it as dropped.
Availability and version scope
The former project homepage now displays a domain-parking notice. The May 2021 release describes the historical BSC design, without confirming current trading access or the configuration of a later deployment.