Skip to main content

Bridge Recovery

Oro persists bridge intents so an interrupted transfer can be resumed without sending the same assets twice. Recovery attaches an existing on-chain deposit or burn to the relayer. It does not create a replacement transfer.

Do not repeat an on-chain action

If Rabby or Azguard already shows a submitted transaction, do not approve, deposit, or burn the assets again. Recover the existing transaction first.

First: check the transfer history​

Open the Bridge page with the same Rabby and Azguard accounts used for the transfer.

  • If the transfer appears with an active status, leave it running. The relayer will continue from its persisted state.
  • If the browser callback was lost, the chain indexers normally rediscover the finalized deposit or burn and attach it automatically.
  • Temporary RPC failures may delay the next worker step. The persisted transfer remains the reference for subsequent processing.
  • If the transfer is marked as failed, keep its transfer ID and contact the Oro operator. An operator retry resumes from the last recorded safe step.
  • Use the recovery forms below only when the on-chain transaction exists but no matching transfer appears in the history.

Recover an Ethereum → Aztec deposit​

The browser stores a pending-deposit recovery record before mXAUT is sent to the Vault. If the deposit succeeds on Sepolia but registration with the relayer is interrupted, the Bridge page displays Pending EVM deposit recovery.

  1. Reconnect the same Rabby account.
  2. Confirm that the displayed transaction hash is the expected Sepolia deposit.
  3. Download Export encrypted recovery file, choose a strong passphrase, and keep both separately.
  4. Select Attach existing deposit.
  5. Sign the new recovery authorization in Rabby.

Oro verifies the existing transaction and attaches it to the relayer. It does not approve or deposit mXAUT again.

Protect and import the recovery file​

The exported JSON is encrypted in the browser with AES-256-GCM. Its key is derived from the passphrase with PBKDF2-SHA256. The passphrase is never written into the file or sent to Oro. The encrypted envelope is bound to the bridge direction, network, chain and Vault address, so an import in another context is rejected.

  • keep the file and passphrase separately.
  • store it securely until ZGLD has been received.
  • use Import recovery file after a browser restart or on another trusted browser.
  • do not clear browser storage before exporting it when recovery is pending.

Legacy unencrypted packages require an explicit warning confirmation at import. Re-importing or attaching the same package is idempotent: Oro links the existing chain action and never creates a second deposit or burn.

If no EVM transaction hash was produced and Rabby shows no submitted deposit, the incomplete local record can be discarded safely.

Recover an Aztec → Ethereum burn​

Before opening Azguard, Oro stores a local recovery record containing the exact Outbox message parameters. If Azguard confirms the ZGLD burn but no transfer appears, open the permanent Aztec → Ethereum recovery panel on the Bridge page.

  1. Connect the same Azguard account and the intended Rabby recipient.
  2. Confirm that the saved amount and Ethereum recipient match the burn you submitted.
  3. Paste the 32-byte Aztec burn transaction hash if Oro did not capture it automatically.
  4. Export the encrypted recovery file and keep its passphrase separately until settlement completes.
  5. Select Attach burn to relayer and sign the recovery authorization in Rabby.

Oro registers the existing burn with the relayer. It does not burn ZGLD again. The relayer then waits for the Aztec Outbox proof, submits the Ethereum unlock, and completes the Aztec acknowledgement.

The return recovery file contains the acknowledgement secret needed for final Aztec settlement. Treat it as sensitive, never send it to support, and delete it after the transfer is settled. A burn transaction hash by itself is not enough to reconstruct the original Outbox message. If the local recovery record is missing, do not burn again: contact Oro support for reconciliation.

Autonomous recovery

Oro now keeps generation-scoped EVM and Aztec event journals, rescans finalized blocks, and reconciles bridge work independently of browser callbacks. This removes the browser as an operational source of truth, but it does not make a lost user recovery package reconstructable and it does not turn a chain outage into proof that a transaction failed.

When operator intervention is required​

Stop and contact the operator with the transfer ID and transaction hash when:

  • the transfer is already present but marked as failed.
  • an Ethereum unlock is visible but the Aztec acknowledgement is incomplete.
  • the interface reports an ambiguous submission.
  • the destination address or exact amount cannot be confirmed.
  • the recovery record or required L1 → L2 secret has been lost.

The operator must reconcile the recorded state with Ethereum and Aztec before retrying. This prevents duplicate submissions and preserves the bridge's replay protections.

Inaccessible Aztec destination​

If the intended Aztec account is permanently inaccessible, Oro does not redirect the mint to another account. After the deposit deadline, the owner may authorize cancellation. The relayer then submits cancel_atomic_deposit using the existing secret. Claim and cancellation consume the same Inbox leaf, so only one can succeed; an authenticated Outbox acknowledgement is still required before the EVM Vault refunds XAUT.

If the Inbox itself is permanently unavailable, absence of a claim is not proof that the message can never return. Oro therefore never refunds this case from bridge backing. After a replacement portal generation is active, the old generation is declared unavailable with public incident evidence and both the deposit deadline and a seven-day safety delay have elapsed, an approved claim may be paid from a separately funded XAUT insurance reserve. The original backing remains locked. A later claim is recorded and remains backed; it does not trigger a second compensation.

Compensation is not automatic or guaranteed when the reserve is insufficient. Verified cases are approved against an auditable allocation record and handled oldest first. Oro never uses another user's backing, accrued exit fees, or an administrative ZGLD mint to cover the shortfall.

Portal migrations and old messages​

Each transfer is bound to an immutable portal generation containing its Inbox, Outbox, Aztec bridge actor, rollup version, and supported message versions. New messages move to the newly activated generation while the previous generation drains. Historical Outbox routes are retained even after retirement so a late proof can still settle. Generation-specific workers and indexer cursors prevent an old message from being interpreted with a new contract or artifact.

If a process stops after a submission begins but before its transaction hash is persisted, Oro marks the transfer submission_ambiguous and disables automatic retry. This state must be checked against both chains before an operator resumes from an explicitly reconciled safe state.

Contact official Oro support​

Open a support request in the official Oro Discord and include only:

  • the transfer ID shown by Oro.
  • the public Ethereum or Aztec transaction hash.
  • the bridge direction and approximate start time.
  • the status and public error message shown in the interface.

Official Oro Discord: support link to be added.

Never send a private key, seed phrase, wallet recovery phrase, bridge recovery file, bridge secret, API key, or full wallet datastore to support. An operator should never ask for them.