Skip to content

USDS Ethereum–Solana Bridge

The current USDS Ethereum–Solana bridge will be down on Nov 17 starting at 14:00 UTC (2 PM GMT, 9 AM EST, 6 AM PST, 10 PM CST/GMT+8) for a scheduled migration for approx. 31 hours, until approx. Nov 18 21:00 UTC. Downtime could be extended depending on the number of pending bridge transfers. Users holding USDS on Solana or Ethereum who are not using the bridge are not affected; they need not take any action before, during, or after the downtime.

  • Sky Ecosystem is performing a planned migration of its USDS Ethereum–Solana bridge.
  • The migration is managed by Sky Ecosystem Governance and is scheduled to start on or around Nov 17 at 14:00 UTC (09:00 EST), with an expected downtime of approx. 31 hours, until the migration is complete and the new LayerZero bridge is fully activated.
  • During this downtime, all USDS bridge transfers between Ethereum and Solana will be paused. Any pending transfers on the current Wormhole bridge will be finalized during the downtime and will not be cancelled.
  • Bridge contract addresses and the functions you currently use to bridge USDS will change after the new bridge infrastructure goes live.
  • The USDS token address on Solana (and on Ethereum) will remain the same. All USDS balances on Solana will continue to function during the downtime and can be used with the new bridge once the migration is complete.
  • USDS balances held by the Wormhole bridge on Ethereum will be migrated to LayerZero infrastructure as part of this migration. USDS on Solana will continue to be backed 1:1 by USDS on Ethereum in the new bridge infrastructure.
  • First governance spell is introduced to Sky Ecosystem Governance and voting begins.
  • Wormhole bridge is active for all USDS bridge transfers.
  • First spell governance security delay of 24 hours before the governance spell can be executed.
  • Office hours alignment: execution after the governance security delay can only occur Mon–Fri between 14:00 UTC (09:00 EST) and 21:00 UTC (16:00 EST).
  • First spell executed.
  • Downtime begins.
  • Wormhole bridge is deactivated for initiating new USDS bridge transfers.
  • Wormhole bridge continues to be active to process all pending USDS bridge transfers that were initiated before downtime began.
  • We strongly advise against doing this, but the USDS LayerZero bridge can be used to initiate new transfers from this point onward. These USDS LayerZero bridge transfers cannot be finalized on the destination chain or completed until the new LayerZero bridge infrastructure is fully activated by Governance.

Approx. 3 to 7 hours after spell execution

Section titled “Approx. 3 to 7 hours after spell execution”
  • Technical checks are completed by various teams.
  • All previously initiated (before downtime began) and pending bridge transfers on the USDS Wormhole bridge can be finalized by users.
  • Downtime could extend beyond 7 hours if there are pending USDS Wormhole bridge transfers that have not been finalized.

Approx. on Mon Nov 17 @ 21:00 UTC (16:00 EST)

Section titled “Approx. on Mon Nov 17 @ 21:00 UTC (16:00 EST)”
  • This timing is provided as approximate reference:
    • It could be earlier if the pending bridge transfer queue is finalized early, but it could be later as well.
  • Second governance spell is introduced to Sky Ecosystem Governance and voting begins.
  • All USDS Wormhole pending bridge transfers would have been completed at this point with nothing pending.
  • Second spell governance security delay of 24 hours before the governance spell can be executed.

Approx. Tue Nov 18 @ 21:00 UTC (16:00 EST)

Section titled “Approx. Tue Nov 18 @ 21:00 UTC (16:00 EST)”
  • Second governance spell executed.
  • Downtime ends. Downtime may end early if the technical checks are complete and the pending bridge transfer queue is finalized earlier.
    • If checks complete early, the new USDS LayerZero bridge will be fully activated as early as Tue Nov 18 17:00 UTC (12:00 EST) — approx. 27 hours downtime.
    • If checks are delayed up to 7 hours, the USDS LayerZero bridge will be fully activated on Tue Nov 18 @ 21:00 UTC (16:00 EST) — approx. 31 hours downtime.
    • If checks are delayed beyond approx. 7 hours, due to office hours alignment on execution, the USDS LayerZero bridge will be fully activated on Wed Nov 19 @ 14:00 UTC — approx. 48 hours downtime.
    • If unforeseen issues occur, downtime can extend beyond 48 hours.
  • USDS Wormhole bridge is fully deprecated.
  • USDS LayerZero bridge is fully activated and available for USDS bridge transfers.

What happens if you initiate new bridge transfers on the Wormhole bridge after it is deprecated (when downtime begins)? All new bridge transfers initiated on Wormhole during the downtime or after will fail, and USDS will not be debited from your wallet or account.

What happens to your pending USDS bridge transfers through Wormhole after it gets deprecated and downtime begins? You can continue to complete your pending bridge transfers (those initiated before the downtime began) normally during the downtime on both Ethereum and Solana, depending on the destination.

Will the Wormhole bridge be re-enabled during or after the downtime? Once the downtime begins and Wormhole is deprecated, the Wormhole bridge will not be re-enabled. Prepare to start using the new LayerZero bridge infrastructure for USDS after the downtime ends.

When can the new LayerZero bridge be used for USDS bridge transfers? Please wait until the downtime ends and an announcement is made before using the new LayerZero bridge infrastructure for USDS. Note that initiating USDS transfers using LayerZero during the downtime will be possible, but those transfers will remain pending and cannot be finalized on the destination chain until the new bridge infrastructure is fully activated.

Will sUSDS be available on the new bridge? No. sUSDS will be available at a later time; initially, only USDS will be supported on the new bridge.

Using the USDS LayerZero Bridge after activation

Section titled “Using the USDS LayerZero Bridge after activation”

Ethereum (Mainnet) — OFT Adapter (USDS): 0x1e1D42781FC170EF9da004Fb735f56F0276d01B8 The adapter wraps the existing ERC-20 USDS on Ethereum to participate in OFT transfers. It expects an allowance to pull USDS when you send from Ethereum.

Solana (Mainnet) — OFT Program (USDS side): SKYTAiJRkgexqQqFoqhXdCANyfziwrVrzjhBaCzdbKW This is the Solana OFT program (OApp) that mints/burns the Solana representation of USDS on messages from/to Ethereum.

Endpoint IDs (EIDs) used by this deployment:

  • Ethereum Mainnet EID: 30101
  • Solana Mainnet EID: 30168
  • Use EIDs in all quote / send calls and peer wiring. Do not use EVM chainId.
  1. Peers wired correctly:

    • EVM peers(30168) == 0x067c7c6c...2e661649 (Solana program).
    • Solana PeerConfig for 30101 == 0x000..001e1d4278...01b8 (Ethereum adapter).
  2. Adapter token = USDS (0xdc035d...7384f) on Ethereum.

  3. Quote → Send works both directions with sufficient options (lzReceive gas / lamports for ATA).

  4. Small test transfers succeed without manual redemption.

Because the Ethereum side uses an OFT Adapter for an existing token (USDS), while the Solana side runs an OFT program, the debit/credit behavior is:

  • Ethereum → Solana: the adapter locks USDS on Ethereum and the Solana OFT mints USDS to the recipient on Solana.
  • Solana → Ethereum: the Solana OFT burns USDS on Solana and the Ethereum adapter unlocks USDS to the recipient on Ethereum.

No claim step: once the message is delivered and executed with sufficient options/fees, crediting happens automatically on the destination (Executor executes the destination lzReceive).

  1. Inputs you must provide
  • Destination EID: 30101 (Ethereum).
  • Recipient: 20-byte EVM address encoded as bytes32 (left-pad zeros to 32 bytes).
  • Amount: USDS amount (local decimals on Solana OFT).
  • Options (destination execution on EVM): include enough lzReceive gas so the EVM credit step can run. (If your pathway enforces defaults, they are merged with your per-tx options.)
  1. Quote fees on Solana Use the Solana OFT SDK’s quote function for this program to get the nativeFee (denominated in lamports) for dstEid=30101, to(bytes32), amountLD, minAmountLD, options. (The SDK uses the Endpoint to aggregate DVN + Executor fees into nativeFee.)
  2. Send on Solana Call the Solana OFT SDK send instruction, paying the returned nativeFee (plus normal Solana tx fees — base 5,000 lamports/signature; add priority fee if desired). After delivery + execution, the Ethereum adapter unlocks USDS to the recipient.

If per-tx options are missing or too low, you may hit errors (e.g., insufficient lzReceive gas). Ensure options cover the EVM mint/unlock call. Options are merged with any enforced options on the pathway.

  1. Inputs you must provide
  • Destination EID: 30168 (Solana).
  • Recipient: 32-byte Solana address supplied to the adapter as bytes32 (ed25519 pubkey bytes).
  • Amount: USDS amount (ERC-20 decimals).
  • Options: if the recipient’s Associated Token Account (ATA) for USDS may not exist on Solana, include lamports for rent in options so the Executor can create it during lzReceive. A standard SPL token account requires 2,039,280 lamports for rent-exemption. Provide this per transfer rather than enforcing globally.
  1. Approve USDS to the adapter On Ethereum, call ERC-20 approve(spender, amount) where spender = 0x1e1D42781FC170EF9da004Fb735f56F0276d01B8. The OFT Adapter will pull tokens when sending. (This is standard for OFT Adapter with existing tokens.)
  2. Quote fees (EVM) Call IOFT.quoteSend(SendParam, payInLzToken) with payInLzToken=false to pay in ETH. Read MessagingFee.nativeFee. (If you choose to pay with ZRO, use lzTokenFee.)
  3. Send (EVM) Call IOFT.send(SendParam, MessagingFee, refundAddress) and pass nativeFee in msg.value. After delivery + execution, the Solana OFT mints USDS to the recipient’s ATA. If you included ATA rent in options and the ATA didn’t exist, the program can create it during execution.

Quoting is required before sending

  • EVM: quoteSend returns MessagingFee with nativeFee and optional lzTokenFee (ZRO). Most users set payInLzToken=false and pay nativeFee in ETH.
  • Solana: the OFT SDK returns a nativeFee in lamports which you include in your send instruction (you also pay normal Solana tx fees).

Options model (destination gas/value)

  • Your per-tx options are combined with enforced options on the pathway using LayerZero’s Option Builder semantics; don’t duplicate the same option or you’ll overpay. Use msgType = SEND (1) for enforced-options lookups.

Use these exact bytes32 values when verifying peers on-chain.

Solana OFT program as bytes32 (for EVM peer at eid=30168) SKYTAiJRkgexqQqFoqhXdCANyfziwrVrzjhBaCzdbKW0x067c7c6c60ba7f1aec14059100df74d6da07e7d31da5dd756c6308f02e661649

Ethereum adapter address as bytes32 (for Solana peer at eid=30101) 0x1e1D42781FC170EF9da004Fb735f56F0276d01B80x0000000000000000000000001e1d42781fc170ef9da004fb735f56f0276d01b8

Released into the public domain (CC0 1.0 Universal) – trademarks remain with their owners; no warranty. See full license.