Summary:
Xave Finance (pronounced “Save Finance”) aims to enable financial services companies (such as “fintechs’’ and neobanks) to leverage DeFi for actual use cases, such as real time remittance transfers and high yield consumer savings. Xave does this by building an FX accurate AMM via a custom “FXPool ‘’ now and eventually a stablecoin lending market that shares liquidity with the Balancer V2 Vault via a BoostedFXPool.
References/Useful links:
Pasting links in reply due to new user limit
Protocol Description:
Xave has deployed its first custom pool type - the FXPool - that brings FX markets and lending to the Balancer DAO.
Motivation:“Bringing FX markets to the Balancer ecosystem”
Stasis, the licensed issuer of fiat backed stablecoins EURS, and its community will be supporting this pool to enable liquid FX trades and eventually work towards instant, on chain cross border remittance between Europe and Asia (EUR-SGD, EUR-PHP, EUR-IDR). Leading blockchain providers have tried to achieve this “on demand liquidity” but stablecoin FX is the true 10x improvement to traditional financial rails. This is especially true as stablecoin rails are able to offer end to end remittances at <1 % per transaction (if anyone is interested, we have a real world cost breakdown). This real world use case will bring sustainable fee generation via real economic activity to the BalancerDAO. Xave would like to work with the BalancerDAO to incentivize this initial pool with BAL rewards towards a real world use case in DeFi.
Specifications:
Governance:
Governance will be done via snapshot for now. Later on Xave’s own VE governance structure will be deployed (forked from veBAL). Current admin of the EURS:USDC FXPool is the team’s ops 3/3 multisig 0xA4d521ae4302ffcf3cD5b257B45B16DAC726A057 (Ethereum Mainnet), until the community is ready to take on ownership of the Xave protocol. The FXPools have various parameters (read more AMM - Xave Finance) that affect the range of FX accurate swaps across the bonding curve. These parameters are updated and optimized over time, thus the need for nimble response while the pool is new.
Oracles:
The EURS:USDC FXPool utilizes a Chainlink oracle to allow FX accurate swaps for a predetermined range of the bonding curve. Beyond this range (called the “beta region”), LP ratio then dictates the price of trades. At this point, arbitrageurs are incentivized by significantly cheaper fees to trade the pool back to the “beta region” where FX price is followed. LPs are also incentivized to keep liquidity in the pool especially while it is outside the “beta region”, due to existing parameters that yield much higher fees charged to traders swapping the pool away from the “beta region”. See linked docs to learn more
Centralization vectors:
3/3 operations multisig that owns contracts until contracts are “battle tested” and community is ready to takeover. The owner of the pool will be changed to the Balancer recommended address 0xbalbalbalbalbalbalbalbalbalbalbalbalbalb once the pool has been running for sometime without issue to allow for quick response time in the event of an emergency. Until then the Xave operations multisig will be assigned as the pool’s owner.
Market History:
EURS is an asset backed stablecoin, fully collateralized and issued by Stasis - the licensed issuer of fiat backed stablecoin EURS. USDC is an asset backed stablecoin issued by Circle
Pasting links of gauge and pool in reply due to new user limit
Value:
FXPools deployed on Xave are highly capital efficient allowing for the pool to support larger trade volumes despite the minimal liquidity.
Gauge with 2% emissions cap: 0xE629c43BCad1029E12ED51432B9dd3432b656cc9
Pool: 0xAd0e5e0778cAC28f1ff459602b31351871B5754a
1: I think that the general idea has been that pools with gauges have their administrator set to the Balancer community which then has final say over fees and A-factor. This hasn’t ever been stated clearly, but it gets mentioned a lot and there’s been problems in the past with people abusing governance rights of pools with gauges. Is there a reason that Balancer can’t take over admin to this pool before the gauge is created and you can work through the community to make changes?
2: I don’t see a link to the pool anywhere in the governance and would like to take a look at the a-factor and fees and other settings you have in place. Can you include a link to the pool without a gauge in this governance text?
There are some red flags about Statis EURS, namely:
1- 93% of its balance sheet consists of high risk corporate bonds.
2- The bond values are accounted for at historical costs; current values may differ.
3- No clear documentation on minting / redemption flow for customers.
Thanks @Tritium good thoughts. I suppose the considerations of the team are the ff (1st being most important and 2nd being less):
Emergency scenarios
If an attack is happening, the team would like to be able to freeze the pool or enact other emergency actions asap and mitigate any damage (this goes without saying that we have our usual practice of getting 2 audits before deploying anything to production). Having the community communicate and reach consensus on emergency activation while an attack is ongoing will severely limit the team’s reaction time. In line with this thinking, the goal is to have the pool run under ownership of our ops multisig for the first 3 months or so, then transfer ownership to Balancer (because audits don’t ensure 100% safety in the wild). Our invariant logic is quite a bit more complicated and novel compared to other Balancer pool types, so quick emergency reaction might not be possible in the near term without a thorough understanding of the FXPool’s workings/behavior. However, once the pools have been running for some time (maybe 3 mos minimum?) without incident, then we would be more comfortable to turn over governance to Balancer. Does this make any sense?
Changing of FXPool parameters
This is not so much of an issue and can be done via Balancer governance, agree on this. Please see the pool details (pool ID, gauge) in the additional comments below
Hey. Sorry if it’s too many questions, but trying to improve/understand our governance process for custom pools.
It seems to me like you already requested 1 gauge for xSGD on polygon. I was trying investigate and understand this pool is generating fees for the Balancer Treasury, but it’s not easy to see entry/exit and swap transactions in the pool from your UI. I see that the xSGD pool on polygon is currently generating 300%+ ROI for users. Based on my understanding, half of that should be getting flowed through BalancerDAO. Do you have evidence such fee flows happening?
Hey @Tritium no worries at all. You can see stats for the first XSGD:USDC FXPool on Polygon here AMM v2 Polygon (Xave Finance), including the LP fees being generated. And yes our UI is a bit new, so those stats are still being built in.
We aren’t actually charging any protocol fees on our end, everything is currently going to LPs as far as we’re aware (our protocol fee switch is off atm). If any fees are being charged, it would be the Balancer Vault doing it directly - our current understanding is that no fees are being charged by the Balancer Vault yet. Something for the Balancer team to confirm as well.
Personally, I’m not quite sure why we should keep approving BAL emissions to flow to gauges if the pools they incentivize aren’t paying any fees back to the DAO and there is not a clear agreement about what that should be. Maybe you should use your native gov token to incentive liquidity on some pools until they’re up and making money that you can pay to Balancer in exchange for the emissions being allocated.
All other pools flow 50% of fees through balancer. On side-chains some of these are used to pay incentives and increase liquidity in the pool. Is there any reason why custom pools seeking gauges shouldn’t pay the same tax/receive the same benefits?
I’d like to see more information about this. I don’t have a delegation nor significant sized bags though, so maybe you can convince others.
It also seems to me like some more clear guidelines/rules should be drafted around custom pools and gauges.
We’re happy to conform to any defined rules on fee implementations for custom pools. We’ve tried to follow spec as much as we could find on Balancer docs / coordinating w core team. We came across this Snapshot after we finished development on the FXPools. Ideally we’d like to get what we have now live so that we can either raise money or get further grants to support further work. We will continue developing with the DAO in lockstep - we understand that everything in this space is a work in progress and we’re here to work w the community and core team. We also understand that up to date documentation is not always readily available due to various reasons
I just don’t understand how it makes any sense for Balancer to grant emissions to a pool that pays nothing back into the ecosystem. Do you really need the gauge up to launch the pool? You have no other way to inceltivize liquidity?
I’m not sure who else to ask about this. I know you guys are building off a Balancer Grant, so maybe it makes sense to talk to this BizDev folks who you worked with on that or whatnot.
In the end, I’m:
Against emissions to pools that pay no fees
Expect DAOs to think a little about how they create value for the ecosystem when building on top of veBAL.
Think this pool, and the xSGD pool should if anything be capped at 2% until reasonable fee flows are demonstrated.
Object to Xave remaining control of pool parameters (which should include fees collected and paid to balancer) on pools with gauges until some sort of standard is in place and clearly being followed.
I’d like to see you guys go back to the drawing board and think about all this stuff if you want to keep building balancer emissions/tokenomics into your product/protocol. As I said tho, I’m not a veBAL whale.
I understand your concerns and I’m not saying we’ll never pay fees back to Balancer DAO (it’s actually not very clear how custom pool fees are supposed to work and this has been a sticking point - so we’ve just created a mechanism to be able to mint LP tokens as fees to a fee collector address so that we can share fees once there is clarity). We’re committed to building with the Balancer core team to bring liquid FX markets to the DAO and compete on a meaningful level with other stablecoin protocols. However, co-development is definitely not a “one off” event where we can assume everything is going to be completely “done” esp given the distributed nature of the teams working on this.
To try and address your points:
Against emissions to pools that pay no fees
→ we have the ability to pay fees to Balancer, despite no well communicated/documented standard. For now we have the ability to mint LP token fees to an address that the Balancer team can provide
Expect DAOs to think a little about how they create value for the ecosystem when building on top of veBAL
→ this seems more of a general suggestion to all token holders rather than a question for us to answer
Think this pool, and the xSGD pool should if anything be capped at 2% until reasonable fee flows are demonstrated
→ not agreeing or disagreeing, but this is a bit of a chicken and egg. The initial driver of volume will be stablecoin arbitrage, which would need some initial liquidity which would be attracted via a desired token (BAL much more than any token we issue in this market). You can see the current trading volume (5M + USD on 1M TVL) of XSGD:USDC Polygon here AMM v2 Polygon (Xave Finance) . We’ve manually sourced this initial liquidity from LPs who are keen to bring liquid FX markets to Balancer like we are as builders - but we believe BAL rewards will attract further liquidity across other pools more than our own efforts.
Object to Xave remaining control of pool parameters (which should include fees collected and paid to balancer) on pools with gauges until some sort of standard is in place and clearly being followed.
→ We’re happy to go either way, ownership of the pools is not critical to us. Xave not owning the pools will just mean that the Balancer team will have to familiarize themselves with operational flows to be able to react quickly in any emergency scenario.
→ We can also renounce ownership of the pools if the community feels strongly that there should be no owner from the get go
Indeed, the Stasis portfolio consists of bonds, but claims regarding the risks are not true. These are A+ or better sovereign and corporate bonds. We were asked about this before, and none of our customers considered this to be a “red flag”.
Transaction flows are actually clear for the customers we provide service for. The STASIS team is very dedicated to solving any issues associated with the process.
The market needs a stablecoin that is purely related to the EU, connected to European payment infrastructure directly and bears no risk outside the European market. EURS is the only euro stablecoin that has no conflict of interest or additional risks of foreign tax systems.
Stasis allows linking a digital wallet to European cards and spending directly at stores or withdrawing from an ATM. EURS is the only stablecoin that utilizes multiple capital channels (SEPA, ISIN, SWIFT, ISDA).
Stasis has signed agreements with Algorand, Ripple, XinFin and other companies to develop multichain infrastructure for EURS.
Ok. That works. So it sounds like Balaner just needs to pass some governance or otherwise issue some guidelines around fees on custom pools and you guys are in good shape to comply with both the EURS and the SGD pool? Is that correct? This seems good to me.
This is more an expectation that the pools that are being supported, and and added as gauges, create value for tokenholders. I guess in the end tokenholders vote on where the emissions go, but I think the point is to try to make sure that all options generate some flows back through the DAO such that some day veBAL can support it’s own value based on the fees it pays out.
In terms of caps, the more I think about it, the more we should follow the framework and not be arbitrary. EURS and USD are both very large cap coins, so baring new frameworks around caps I agree that this doesn’t make sense here.
Thanks for taking the time to go through this. It seems like the main focus here needs to be on a clear framework/set of guidelines for custom pools and how they interact with veBAL. That’s clearly not on Xave to do.
In terms of pool ownership, it probably makes sense for you to continue to manage it, within some boundaries. Your point that said boundaries do not currently exist is well taken. I’ll go poke around and see if there’s someone who wants to focus on defining that better.
We’ve already been trying to enforce the 50% protocol fee for custom pools that get gauges (see Index Coop proposal). Problem here is I assumed they were paying it, which was a mistake on my part. I don’t think we need to issue governance to say all gauges must respect the protocol fee as it’s sorta obvious they should in my mind. Clearly more due diligence is required going forward though, credit to you for asking good questions.
Ok. So it seems the expectations are that 50% of the revenue from pools is paid to the DAO as fees. Is this something that would be easy for you all to fix on both the SGD pool and then EURS pool before we move forward with more gauges?
@solarcurve is this requirement documented anywhere/do we have any set of guidelines written up in one place for custom pool devs looking to do veBAL? If not maybe we should work on a notion or a forum article or something and make it a point to go through that checklist with new custom pools requests.
no reason for it not to be verified if a gauge is being proposed