Contents
The Wormhole integration announcement gave a glimpse of what will be further possible with sBTC in the web3 ecosystem. Cross-chain activity, continued bitcoin programmability, diverse bitcoin yield strategies, and much more. Bridging sBTC from the Stacks network to other notable chains such as Solana and Sui will continue to further the underlying mission of building on bitcoin. But, how exactly does sBTC bridge from Stacks to another chain and back?
Breaking down the sBTC cross-chain flow
Let’s visualize step-by-step what the actual process flow would look like in the case of transferring sBTC on Stacks to Solana, for example:
- A user would initiate a cross-chain transfer on a Stacks’ dApp, will interface with an sBTC NTT manager contract, which will then call into the Wormhole core Clarity smart contract.
- During this contract call, the user would have to send sBTC to the NTT manager contract, which will lock the sBTC.
- The activity on the NTT manager contract calls into the Wormhole core contract, which will then emit a message to the set of Wormhole Guardians, who will then sign and package up these events taking place as an attested message in the form of a VAA. A VAA, “Verified Action Approval”, is a cross-chain message attestation signed by the Wormhole Guardians.
- The VAA payload will then be relayed over to a Solana-implemented sBTC NTT manager contract.
- The invoked contract will then verify the signatures of the VAA, parse the message payload, and then trigger the final set of actions that need to take place.
- The Solana-native sBTC token, representing locked sBTC on Stacks, will then be transferred to its target Solana address.
This cross-chain flow for sBTC will look similar for other SIP-010 tokens when they become formally supported.
Challenges and Support
Stacks contract addresses are a combination of a standard Stacks principal, and a contract name. Concatenated together, they form what is collectively called a contract principal.
<code-rich-text>SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-token<code-rich-text>
A unique issue that arose was that Wormhole only allows 32 bytes for addresses, while a Stacks contract principal can be much longer than that. Most other chains have contract addresses which are the same as standard account addresses, which is why they fit into 32 bytes, but Stacks uses the account address of the contract deployer + human readable ASCII, which makes it longer than 32 bytes. So the workaround with this is that Stacks contract addresses will have to be hashed into a new 32 byte string when identified on other chains. This helped to guarantee compatibility with address format standards with Wormhole.
Another area where Hiro has been supporting the integration involves helping Guardians operate their own Stacks node infrastructure. Because security is paramount for the Wormhole Guardian set, they cannot rely on public APIs — they need to run full Stacks nodes to directly observe and verify on-chain activity. To support this, Hiro has been assisting with the modification and review of the Go-based watcher code to enable it to monitor the Stacks network. This Go-based watcher code allows Guardians to efficiently parse and react to relevant on-chain events, ensuring both performance and security in their Wormhole operations.
Current Status
The current status has the core contracts already written and finished, but awaiting a final formal audit. Upon completion of an audit, a preliminary phase of testing will most likely be needed. This would involve a deployment to testnet with sufficient edge case stress testing on the contract to gauge its performance in a live environment.
There is also ongoing work on improving the performance of the way VAAs are being parsed in a Stacks transaction. At the moment, the ingestion and decoding of VAAs have considerably high runtime costs on Stacks, as evident in Stacks’ usage of Pyth’s oracle model. Proposals for code optimization are already underway that will cut runtime costs down significantly. The fetching and ingestion of VAAs in Clarity smart contracts is what enables contracts to handle messages to and from the Wormhole network. In order to handle the foreseeable future of increased cross-chain activity for sBTC and other Stacks assets, performance improvements to the way VAAs are handled are only going to be necessary.
What’s Next
Once the Wormhole core contracts for Stacks are completed, decentralized ownership and deployment will be handed off to the Wormhole Foundation. Any further technical support will continue to be provided by Hiro and the Stacks Core team. Additionally, efforts to bridge sBTC via Axelar are underway to provide options for cross-chain bridging solutions on Stacks.
Stay up to date on the Wormhole integration by following our socials, and keep an eye out for an upcoming technical deep dive on how developers can leverage the Wormhole core contract in their applications.
