Engineering Workstream Monthly Update - Dec 2025

Workstream Discussion Engineering
1

Highlights

  • On December 10, we released our Chainflip integration, a collaborative effort between an open-source community contributor (hat tip to David Cumps) and our core engineering team. This release paves the way for bringing assets into the Solana ecosystem and enabling additional swapping routes through Jupiter.
  • On December 20, we completed and released our Jupiter swapper integration, marking our first major Solana-based feature with support for both SPL and Token2022 tokens.

Lowlights

  • Avalanche functionality has been in a degraded state since December 18 due to an unresolved issue with our upstream data provider. Unfortunately, this problem has persisted through the holiday season, causing notable disruptions for users. Restoring full functionality for Avalanche remains a top priority, and we are actively working to resolve the issue as quickly as possible.

Last Month

This month saw significant progress in cross-chain integrations and swapping capabilities. The Chainflip integration, launched on December 10, and the Jupiter swapper integration, launched on December 20, marked major advancements. Additionally, we added native ledger support for Solana to enhance accessibility for Ledger device users. Together, these integrations significantly expand our platform’s functionality, strengthening our commitment to cross-chain compatibility and enhancing user experiences within the Solana ecosystem.

The team also completed work on the updated trade confirmation flow, which offers a more user-friendly interface and reusable UI components. Development for CowSwap-based limit orders was finalized, and both features are now undergoing final operations testing ahead of their January release.

The platform’s usability saw further enhancements this month as well. Human-readable error translations were added to the Jupiter swapper to improve error reporting. Swapper functionality was improved by enabling the flipping of input and output assets, now including fiat-based conversions to provide accurate estimates. If a user attempts to flip assets without a wallet that supports the input asset, we now display helpful warnings alongside accurate quotes. The rate change modal has been updated to include percentage differences, providing users with greater transparency when rate changes occur.

We addressed several maintenance issues and bug fixes as well. In mid December Thorchain underwent a major upgrade (v3.0.0) that caused disruption to hardware wallet users (both Keepkey and Ledger). The upgrade and regressions during this release required significant intervention from our team. We also performed some code cleanup to remove deprecated ZRX v1 code paths from our web app. Several bugs were resolved over the month, including:

  • Fixed a problem where the wallet connect modal was buried under the dashboard
  • Added a graceful failure state for rare LiFi swapper errors that previously resulted in blank screens for users.
  • Increased the buffer for compute units in Jupiter Solana-based trades to prevent intermittent failures and introduced dynamic slippage parameters to reduce failed trades due to overly optimistic slippage settings.
  • Resolved a regression that caused BTC sends from Phantom wallets to fail and added taproot support for Phantom wallets handling BTC transactions.
  • Fixed issues with stale network fees in LiFi-related trades and ensured updated final quotes are fetched for accuracy.
  • Remediated errors where ZRX allowance checks could be skipped during a loading state and cleaned up outdated code paths from ZRX v1.
  • Resolved a problem where the ShapeShift fee was always displayed in USD terms, fees are now shown in the user’s preferred fiat currency.
  • Fixed a bug where auto-slippage was being enforced for Portals instead of respecting user-defined slippage settings.

This Month

As we enter the new year, our immediate priorities include stabilizing Avalanche functionality to restore full service. Base has also been experiencing intermittent issues that have been affecting users on a smaller scale and will become a focus once Avalanche issues are resolved ahead of the Thorchain release introducing support for Base swaps. On the feature side, we will focus on supporting the import of keystore files and updating the wallet selection and connection flow UI. Additionally, we plan to introduce support for LP tokens within rFOX. Later in the month, we will collaborate with Marketing and Product on the “FOX wif Hat” initiative and begin work on a memo-less standalone application for Chainflip.

3 Likes
2

Again big props to David for his Chainflip integration and to our Engineering WS for helping/fostering such contributions and improvements!

@0xean Do you think that this kind of contribution could be incentivized with FOX grants/bounties in the future, but whitelisted to past contributors who have demonstrated their knowledge of the project through similar major contributions?

I’m not saying they would automatically be interested/available, but maybe it could be a way to get around the big hurdle we’ve encountered when we’ve tried Engineering bounties in the past?

2 Likes
3

Thanks for raising the question, its certainly worth thinking about. As a DAO across the board we need to consider ways to bring in and welcome new community members to keep growing.

We do have some flexibility in the discretionary budget to incentivize community contributors as it stands without a formal program in place. I do think David is deserving of some recognition in this regard. We are also currently using his Chainflip broker as a service (https://chainflip-broker.io/), which makes this all a really nice win-win.

In your idea, how would one become whitelisted to be able to participate in bounties in the future?

1 Like
4

Considering the number of external contributors who would qualify right now, even with very low thresholds, I’m not sure if we have to have strict requirements besides being recognized by the current Engineering Workstream contributors :sweat_smile:

But I suppose it could be quantified if necessary, for example having merged functional code used in any release in the past x months? Or anything that demonstrate that they are at least acquainted with our codebase.

That would disqualify most of the drive-by bounty hunters who have actually no interest in the project or even the crypto domain in general… or maybe get some of them to do smaller contributions first and build reputation. I think that was one of the bad experience we had with the Engineering bounties initially, right?

The other was that there’s not that many candidates to begin with, but losing time one the unserious ones was already discouraging or even wasteful. That’s my recollection of how it went as a bystander of the public bounty board, so correct me if I’m wrong of course!

1 Like