Exchange Updates

Recherche vérifiée par sources: Bybit

6 min

Le corps de l'article est affiché dans sa version anglaise vérifiée. La traduction sera ajoutée après revue des sources.

Direct answer

Bybit said it would support Zigchain v4.3.0 at approximately 09:00 UTC on September 17, 2026, or block height 12,197,000, and suspend ZIG deposits and withdrawals from 08:30 UTC. Trading was stated to remain unaffected. Because Bybit said there would be no further resumption announcement, users should use the deposit or withdrawal page alert and verify the live network state before sending funds.

Réduire

Verified source facts

1. Upgrade,The notice names Zigchain v4.3.0.,bybit-zig 2. Trigger,The expected trigger is 09:00 UTC or block height 12,197,000.,bybit-zig 3. Suspension,Deposits and withdrawals were scheduled to pause from 08:30 UTC.,bybit-zig 4. Resumption,Bybit said no further announcement would be issued and directed users to set an alert.,bybit-zig

Comparison at a glance

Tableau de l’article : faites défiler horizontalement ou placez le focus sur le tableau et utilisez les flèches.

Decision layerWhat to inspectMinimum safe action
Versionv4.3.0match release
Height12,197,000monitor explorer
Time09:00 UTC approximateconvert locally
Pause08:30 UTCstop transfers early
Tradingunaffected statementverify product
NetworkZigchain onlyselect correct route
Memodestination requirementretain exact value
Alertdeposit or withdrawal pageenable notification
Testsmall post-resume transferwait for credit
Evidencetransaction and account recordreconcile

1. Official-product check: Version

A venue announcement becomes useful only after its rule is translated into a testable account decision. Here, version concerns v4.3.0. Retain the dated first-party wording, identify the eligible entity and product screen, and then match release. A launch headline cannot prove access, suitability, liquidity, or the result for a particular account.

Separate the product's stated mechanics from promotional framing. Identify the funding source, matching or pricing rule, settlement trigger, fee formula, loss boundary, and suspension policy. The documentation can describe those controls, but it cannot resolve wrong upgrade. That unknown must remain visible rather than being converted into a prediction.

Finally, make version reversible where possible: match release. Retain non-secret evidence and reconcile the result with the rule for v4.3.0. This section evaluates operational mechanics; because wrong upgrade remains unresolved, it does not predict the underlying market or recommend taking the exposure.

2. Official-product check: Height

Here, height concerns 12,197,000. Retain the dated first-party wording, identify the eligible entity and product screen, and then monitor explorer.

The documentation can describe those controls, but it cannot resolve estimate drift.

Finally, make height reversible where possible: monitor explorer. Retain non-secret evidence and reconcile the result with the rule for 12,197,000. This section evaluates operational mechanics; because estimate drift remains unresolved, it does not predict the underlying market or recommend taking the exposure.

3. Official-product check: Time

Here, time concerns 09:00 UTC approximate. Retain the dated first-party wording, identify the eligible entity and product screen, and then convert locally.

The documentation can describe those controls, but it cannot resolve timezone error.

Finally, make time reversible where possible: convert locally. Retain non-secret evidence and reconcile the result with the rule for 09:00 UTC approximate. This section evaluates operational mechanics; because timezone error remains unresolved, it does not predict the underlying market or recommend taking the exposure.

4. Official-product check: Pause

Here, pause concerns 08:30 UTC. Retain the dated first-party wording, identify the eligible entity and product screen, and then stop transfers early.

The documentation can describe those controls, but it cannot resolve pending deposit.

Finally, make pause reversible where possible: stop transfers early. Retain non-secret evidence and reconcile the result with the rule for 08:30 UTC. This section evaluates operational mechanics; because pending deposit remains unresolved, it does not predict the underlying market or recommend taking the exposure.

5. Official-product check: Trading

Here, trading concerns unaffected statement. Retain the dated first-party wording, identify the eligible entity and product screen, and then verify product.

The documentation can describe those controls, but it cannot resolve false assumption.

Finally, make trading reversible where possible: verify product. Retain non-secret evidence and reconcile the result with the rule for unaffected statement. This section evaluates operational mechanics; because false assumption remains unresolved, it does not predict the underlying market or recommend taking the exposure.

6. Official-product check: Network

Here, network concerns Zigchain only. Retain the dated first-party wording, identify the eligible entity and product screen, and then select correct route.

The documentation can describe those controls, but it cannot resolve chain confusion.

Finally, make network reversible where possible: select correct route. Retain non-secret evidence and reconcile the result with the rule for Zigchain only. This section evaluates operational mechanics; because chain confusion remains unresolved, it does not predict the underlying market or recommend taking the exposure.

7. Official-product check: Memo

Here, memo concerns destination requirement. Retain the dated first-party wording, identify the eligible entity and product screen, and then retain exact value.

The documentation can describe those controls, but it cannot resolve lost credit.

Finally, make memo reversible where possible: retain exact value. Retain non-secret evidence and reconcile the result with the rule for destination requirement. This section evaluates operational mechanics; because lost credit remains unresolved, it does not predict the underlying market or recommend taking the exposure.

8. Official-product check: Alert

Here, alert concerns deposit or withdrawal page. Retain the dated first-party wording, identify the eligible entity and product screen, and then enable notification.

The documentation can describe those controls, but it cannot resolve missed recovery.

Finally, make alert reversible where possible: enable notification. Retain non-secret evidence and reconcile the result with the rule for deposit or withdrawal page. This section evaluates operational mechanics; because missed recovery remains unresolved, it does not predict the underlying market or recommend taking the exposure.

9. Official-product check: Test

Here, test concerns small post-resume transfer. Retain the dated first-party wording, identify the eligible entity and product screen, and then wait for credit.

The documentation can describe those controls, but it cannot resolve large first send.

Finally, make test reversible where possible: wait for credit. Retain non-secret evidence and reconcile the result with the rule for small post-resume transfer. This section evaluates operational mechanics; because large first send remains unresolved, it does not predict the underlying market or recommend taking the exposure.

10. Official-product check: Evidence

Here, evidence concerns transaction and account record. Retain the dated first-party wording, identify the eligible entity and product screen, and then reconcile.

The documentation can describe those controls, but it cannot resolve unresolved balance.

Finally, make evidence reversible where possible: reconcile. Retain non-secret evidence and reconcile the result with the rule for transaction and account record. This section evaluates operational mechanics; because unresolved balance remains unresolved, it does not predict the underlying market or recommend taking the exposure.

Decision scenarios

Scenario 1: when version becomes decisive

Consider a reader whose main constraint is v4.3.0. The correct response is not to infer a universal platform or product winner. It is to match release, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.

Scenario 2: when height becomes decisive

Consider a reader whose main constraint is 12,197,000. It is to monitor explorer, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 3: when time becomes decisive

Consider a reader whose main constraint is 09:00 UTC approximate. It is to convert locally, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 4: when pause becomes decisive

Consider a reader whose main constraint is 08:30 UTC. It is to stop transfers early, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 5: when trading becomes decisive

Consider a reader whose main constraint is unaffected statement. It is to verify product, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 6: when network becomes decisive

Consider a reader whose main constraint is Zigchain only. It is to select correct route, retain the evidence, and define a stop condition before funds or permissions are committed.

Sources and editorial method

Sources

03
  1. BybitZigchain upgrade notice · announcements.bybit.com
  2. BybitMaintenance registry · announcements.bybit.com
  3. Upstream release registryRelease reference boundary
Choisissez la prochaine étape de recherche