Orb Collective November 2022 Update

It’s my pleasure to share Orb Collective’s latest update with the Balancer community.

Vision & Roadmap

Orb’s ecosystem-wide strategic goals for Balancer for Q4 2022 are:


  • Strengthen the DAO’s financial position.
  • Make Balancer easier to use.


  • Scale Boosted Pools and veBAL.
  • Expand to Gnosis Chain and zkSync


  • Develop and launch Managed Pools use cases.


In our recently posted 3 month financial update we provided an overview of how the Orb team has reacted and adjusted to worsening market conditions from the time of our original funding proposal through today. We’ve made it a top priority to position Balancer as an ecosystem, and Orb as a company, to withstand a prolonged bear market while maximizing the productivity of a lean team; to allocate funds as efficiently as possible while gaining mind and market share.

This has meant continuously looking for and addressing inefficiencies, cutting costs, and re-evaluating our growth plans to fit the environment as it unfolds.

Through these efforts, we’ve managed to underspend our allotted budget by 31% during our first 3 months of operations, saving $350,865. We’re taking this opportunity to effectively return those funds to the DAO and bolster the treasury by voluntarily forgoing our December funding that is due from the Balancer Foundation. We will also revise our budget forecast for Q1 2023 based on the cost reductions we have made and our revised growth plans, again, so that more of those funds can remain in the DAO treasury and extend the DAO’s stable asset runway.

We’ve been very mindful of our spending from day 1, as we have always been firmly aligned with the financial health and longevity of the DAO and the long-term success of Balancer protocol.

As responsible stewards of capital, we’ll continue taking this same approach to maximize the efficiency of our utilization of DAO treasury resources.


Our bear market philosophy regarding personnel has been to halt our headcount growth and to shift resource allocation towards engineering.

During November, our team saw:

  • 1 role reassignment
  • 2 subtractions
  • 1 addition

This month, we reduced the number of people working on marketing from 4 to 2.

Bianca, who has a background in computer science, has shifted her focus from marketing and developer relations to documentation, which is technically within the domain of the Integrations team and is a key Q4 priority for the Balancer ecosystem, as discussed in our previous update. There are a lot of holes to fill in the Balancer docs, which makes this a large undertaking that will require her full attention through the rest of Q4.

I highly appreciate Bianca’s flexibility and willingness to step up to fill a need for the team and ecosystem, even though it was not part of her original job description. This is an example of the team-first mentality that is embedded in Orb’s culture.

We also made the difficult decision to discontinue working with Maria, who has been a valuable contributor to Balancer’s marketing efforts for ~1.5 years. We will miss Maria and we hope to have the opportunity to work with her again.

Maria’s responsibilities at Orb included:

  • Coordinating partnership promotions
  • Event planning & execution
  • Initiating the ambassador program
  • Management of international (non-English) communities

On the Integrations side, we saw the planned departure of Moose, who completed his 3 month contract with Orb after providing immense value as a part-time Director of Engineering. Moose’s deliverables during his time with the team can be summarized in two categories.


  • Integrations team quarterly planning
  • Integrations team sprint planning
  • Project kick-off process
  • Ecosystem-wide procedures for requesting support from Integrations team
  • Efficient onboarding process for new engineering hires


  • Engineering team interviews & retrospective analysis on the Boosted Pools project
  • Led designing the format and agenda of the ecosystem-wide Q3 retrospective meeting (which we will re-use for future quarterly retro’s)
  • Owned the Integrations team hiring process (fulfilled goal of hiring 2 engineers)
  • Optimized engineering cross-team communication
  • Led onboarding of Sebastian and Jõao
  • Management of the Integrations team
  • Mentorship and training of our Tech Lead, Rab, preparing him for the management role he has now taken on

The new addition to our team is an Integrations Engineer named Bailey who officially started on Nov 28.

We’ve now reached our headcount goals for the Integrations team and are freezing hiring for the foreseeable future, as we continue to monitor the macro picture and adjust accordingly.

Overall, our team’s resources are currently dedicated as follows:

50% Integrations - 6 people
17% Marketing - 2 people
8% Ops - 1 person
8% Design - 1 person
8% Legal - 1 person
8% Executive leadership - 1 person


  • We launched our ecosystem’s very first Performance Review Cycle. Our 360 cycle consists of self, peer, upward and downward reviews to get a holistic view of how contributors are performing. We created and conducted trainings for managers and non-managers on how to write reviews, deliver feedback effectively, avoid biases and learn about the structure of our review system. We are currently in the review writing phase and the cycle will wrap up with performance review meetings the week of Dec-12.
  • We had our first ecosystem AMA. This one featured our ecosystem team leads. Why did we start doing these? We noticed that there wasn’t a dedicated space to ask questions. We sourced questions ahead of time, created a form to submit anonymous questions and took live ones. All in all, our first AMA turned out to be a great success and we are planning for our next one on Governance, Risk & Compliance next week.
  • We started to create Balancer University, which will be a part of our ecosystem onboarding. Balancer University will be a series of recordings that does a deep dive of each ecosystem participant, explains our ecosystem mission and values and goes over the founding story of Balancer protocol. As new contributors join our ecosystem, they will watch through the videos before having a live Q&A with the ecosystem leads. We are excited for this as we see how much value it can bring to new contributors as they start.
  • We conducted our November Ecosystem All Hands. At this month’s All Hands we heard about new ecosystem members, an update to our vision and mission, an update on our protocol fees and DAO stats, our next ONsite and held a retrospective. The retrospective was super helpful as it helped us highlight and identify areas that we are doing well in and where we should double down and also areas where there is room for learnings and improvement.
  • After a few months of surveys, research and contract negotiations we have locked in details for our April-2023 ONsite. Core ecosystem participants are excited to get back together in person next year!

Governance, Risk, Compliance (GRC)

First I want to acknowledge that we are learning on the fly how to best communicate to the community all the work that we do. We’re new to being a publicly reporting team and it’s a learning process. We appreciate everyone’s patience along the way.

One area where we’ve been providing significant value to the ecosystem from day 1, but weren’t quite sure how to communicate, is in the area of GRC, which is led by our team member, Beth.

Part of Orb’s role in the ecosystem is to protect the resiliency and growth of the DAO by creating a strategy for ecosystem regulatory and legal risks and as well managing the corporate governance and risks for the agents of the DAO and ecosystem stakeholders.

Our GRC work for the Balancer ecosystem, Orb Collective, the Balancer Foundation, and the Balancer OpCo includes:

  • Regulatory strategy & corporate governance
  • Vendor due diligence, oversight, and legal agreements
  • Support of ecosystem decentralization
  • Regulatory developments
  • Liability & risk assessments
  • Biz dev & marketing advice and support with partner arrangements & public communications as needed etc.

Here are a list of highlights of what we delivered on GRC during our first 4 months:

  • Leading decentralization efforts re: BVI VASP, regulatory strategy, proposed new US legislation, research re: DeFi Education Fund and opportunities in Panama and Marshall Islands
  • Contract negotiation for agreements for consultants, service providers, vendors to limit liability and manage costs with termination clauses etc.
  • Draft policies for privacy, marketing, code of conduct and anti-fraud, sanctions etc.
  • Office hours and searching and analyzing issues such as requests for information, interpretations of opportunities and otherwise manage legal spend for the ecosystem

Going forward, I’ll continue to include updates from the GRC side so that the community has better visibility into the value we’re providing there.

Team-Specific Updates, grouped by ecosystem goals:

Make Balancer easier to use.


As part of a broader effort to improve the overall impact of Balancer’s documentation suite, the integrations team is currently focused on building and refining docs for two pivotal products: Boosted Pools and Managed Pools.

  • Boosted Pool docs: the first reference implementation of a more product- and integrator-focused docs suite

  • High-level concepts to educate the DeFi ecosystem on this uniquely composable building block

  • Detailed guides for:

    • Boosting a token’s liquidity using lending markets like Aave
    • Integrating a yield protocol with our Linear Pool framework to offer alternative boosting options for LPs
  • Technical deep dives on the system components that make up a Boosted Pool: Linear Pools, Composable Stable Pools, and Weighted Pools

  • Managed Pool docs: the first glimpse at a brand new and very powerful Balancer product offering

  • High-level concepts to educate the DeFi ecosystem on the complex array of products that can be built using Managed Pools

  • Architectural considerations for developing your own use case using the Pool/Controller design paradigm

  • Technical deep dive on our first of many Controller implementations:

    • Hierarchical, modular finite state machines for reducing the complexity space to a set of rigidly defined workflows
    • The propose/execute pattern for time locks: enforcing Manager transparency and leveraging a third-party Guardian’s veto power
    • State machine diagrams and a detailed specification for each workflow module that we’ve built so far, including:
      • Add/Remove Token
      • Emergency Stop
      • Reweight
      • Set Management Fee
      • Trade
      • Transfer Manager/Guardian
      • Update Circuit Breakers


Documentation is a key pillar in increasing the number of teams building on top of Balancer. Balancer’s content and docs are where we want to funnel builders and devs, so this past month we created a central knowledge hub for content and made notable upgrades to the docs.

  • Migrated the Knowledge Center onto the Balancer blog - Created a central hub for Devs, Liquidity providers, and the general public to go when searching for Balancer content.
  • Introduction of Twitter Snaps to showcase answers to the most frequent questions from Discord in a visually-attractive format that can be shared on Twitter
  • Published a Balancer Relayers and Pool Migrations article as a guide for devs
  • Documentation
    • Created internal and external documentation to reflect the standards and best practices to adhere to when making commits to be merged into the Balancer codebase or building on top of Balancer.
    • Updated documentation around Mental Model for LBPs, emergency subDAO, and audits.
    • Created documentation overview on “Composable Stable Pools”
    • Created a contribution guide for the internal Balancer team to be used as a reference when documenting new products and updating the documentation of existing ones


  • Marketing website updates (balancer.fi)

    • New designs and layout to better reflect the clarified vision of Balancer being a protocol not a product.
    • Removed content about the Balancer product (including invest and trade sections and pages).
    • Our role was to design, copy-write, coordinate with stakeholders and build the new site sections and animations.
    • These changes help set the foundation for the next version of the Balancer website which aims to focus on developers and the value proposition of building on Balancer. The changes in terminology also help to reduce regulatory risk.
  • Web app messaging updates (app.balancer.fi)

    • Removed traditional finances terms and replaced them with more consistent DeFi native terminology across the site.
    • This better reflects the DeFi actions in the product, increases clarity for users and reduces regulatory risk.
  • Other minor web app UI/UX improvments

    • Designs to add rate provider details to pool pages.
    • Filters for the veBAL table
    • High level designs APR tooltips in Managed Pools where there are 5+ tokens with intrinsic yield.

Scale Boosted Pools and veBAL.


  • Boosted Pool scalability: building a central repository for custom Linear Pool integrations

    • One-stop shop for all known Linear Pool implementations
    • Includes contribution guide for third-parties
    • Complements documentation effort outlined above
  • Boosted Pool integrations in flight

    • ERC-4626: upgrades (Rebalancer + re-entrancy fix) nearly finished, will unblock several integrations
    • Gearbox: custom impl nearly finished
    • Euler: custom impl nearly finished
    • Yearn: custom impl to be reviewed
    • Beefy: custom impl to be reviewed


  • Boosted Pools Launch Support
    • Created an external contribution guide to help teams build on Balancer
    • Worked together with the Integrations and Smart Contracts teams to design and set the structure of the documentation for Boosted Pools
  • Partner Boosted Pools Promotion
    • Onboarded new design resource for Overnight Finance campaign
      • Interviewed him, took him up to speed on balancer brand, sent reference images, multiple design notes


  • For generalized deep boosted pools:
    • Various UX/UI tweaks and support to the front end team during their implementation of joins & exits.
    • Helped to perform testing of the new flow.
    • Minor front-end development tweaks to sharpen the UI before launch.
  • For veBAL
    • Minor claim page front-end development updates for clearer claim table headings with tooltips. This should help people better understand what the incentives in each table represent and where the yield comes from.
    • Design tweaks to the PR for notifying users to resubmit their votes if they acquire new veBAL after previously voting.

Develop and launch Managed Pools use cases.


  • Managed Pool documentation: ongoing effort, outlined above

  • Managed Pool Controller development

    • Completed a major code base refactor including a ~15 kB size reduction

    • Kicked off a peer review with the Balancer Labs team

    • Managing the ongoing audit process with Certora

    • Discovered a potential vulnerability in the Managed Pool Controller (not deployed yet)

      • Description:

        • Managed Pool Controller V1 includes a rather complex feature which allows the Manager to:
          • Add a new token to the constituent set without providing any seed capital
          • Remove an existing token from the constituent set without taking intermediate custody of the removed balance
        • To enable this feature, we introduce a mechanism that creates incentives for arbitrageurs to fill (from zero) or drain (to zero) the pool’s balance of one token
        • This mechanism performs its desired function for swaps, but has unforeseen negative repercussions for joins and exits
        • There is a potential fix which requires making small changes in the Managed Pool contract and updating the Managed Pool Controller accordingly
        • There is still some uncertainty as to whether the side effects of this fix are acceptable
      • Takeaways:

        • Unfortunately, it took us too long to notice this issue: we should have begun our internal review process sooner
        • Managed Pools are a completely novel product, and bumps on the road are to be expected
        • Our team’s recent growth should help us to plan better and have more eyes on our code moving forward
      • Effect on the Index Coop partnership:

        • Ongoing discussions to solidify which solution to employ for the V1 launch
        • Timeline pushed to early 2023: deconflict with winter holidays, accommodate extra time for vulnerability discussions


  • “Managed Pools in DeFi” keynote presentation at NBX in Berlin, educating potential future users and developers on the Managed Pools concept ahead of our launch
  • Had meetings with the Index Coop marketing and content team about the launch plan for Managed Pools. Created marketing and comms plan and set KPIs. A significant amount of time was spent in November planning for this launch, which has now been pushed back to January.
    • Started content planning
    • AMA plan and setup
    • Index Coop and Balancer explainer video script started
    • Promotional video planning for launch
    • Graphics ideas planned
    • PR strategy started which includes what journalists we wanted to offer an exclusive to surrounding the launch


  • Product Management of Managed Pools
  • Collaborating with Index Coop on their first Managed Pool, Diversified Staked ETH (dsETH). Also meeting to help high level design discussions for the next Managed Pool.
  • Collaborating with Autonolas – shared designs of a potential join/exit flow for how they could handle this on their front-end.
  • Assisted Business Development efforts – joined meetings with Aera and Enzyme Finance which could offer new use cases, like Treasury //Management on top of Balancer Managed Pools.
  • Started creating high level Managed Pool documentation which can be used for marketing purposes.

Brand Building - Marketing Team

In November, we spent more time getting Balancer’s name into the discussion. We’ve increased our Twitter content and facilitated Balancer’s presence in traditional media publications.

  • Increased Twitter engagement

    • Number of tweets increased 130%
    • Tweet impressions increased 180%
    • Profile visits increased 26%
    • Mentions increased 14%
  • Balancer feature in Nasdaq

    • Secured a Balancer/Orb team member interview in a tier 1 publication

Marketing also spent a significant amount of time on partner marketing and promotion. These efforts give valuable exposure to the teams who are currently building on Balancer and encourage new projects to join our developer ecosystem.

  • Now that Orb has transitioned business development, the marketing team has taken on more responsibilities in communicating/negotiating with partners, and is doing so earlier in the lifecycle than before. We have conducted marketing discussions with the following partners in the past month:

    • Index Coop
    • Fjord Foundry
    • Solace
    • Immunefi
    • Aura
    • Overnight
    • Gyroscope
    • Tranchess
    • QiDAO
    • Autonolas
    • Polygon
    • 1inch
    • Element Finance
    • Stablenode
    • Beethoven
    • Lido
    • Stader Labs
    • ParaSwap
    • Galxe
    • Frax
  • Increased partner marketing, showcasing key Balancer use cases:

    • Three episodes of DeFi Tweets Twitter Spaces
      • Increase Community Participation using Liquidity Bootstrapping Pools” with Fjord Foundry (expanded awareness on Fjord, LBPs, and the exclusive partnership with Balancer)
      • Professional Delegation Setting New Standards for DAOs with Stablenode (educating the community about delegation and Balancer’s gov system)
      • The Importance of Self-Custody with Element Finance (integrating protocol co-marketing + educating the community about DeFi)
    • Twitter threads spotlighting our partners and what they are building on Balancer
      • Fjord Foundry - expanded awareness on Fjord, LBPs, and the exclusive partnership with Balancer
      • RocketPool and Beethoven - Promo on the new Pool that went live on Optimism
      • Frax Finance - promoted the sfrxETH/wstETH/rETH Pool. Created a thread and custom gif about Frax entering the Balancer ecosystem and promoting the three-staked ETH pool
    • Managed comms and created Twitter thread to support Gyroscope Protocol’s launch of E-CLPs
    • Managed comms and created content (Twitter, potential blog), scheduling Twitter Spaces to support Solace team on a Balancer Friendly Fork on Aurora
  • Balancer Grantee Promotion- Promoting Balancer grantees on social media and highlighting what can be built on Balancer:

    • Skytale
    • Notional
    • Cron Finance

Closing thoughts

It’s been another busy month for the Orb team. Despite the painful events in the greater space/markets, we remained focused on our goals and performing at a high level for the Balancer community.

It’s tough to fully encapsulate what we do in these monthly updates, and in past editions we optimized for being concise. Based on community feedback, we’ve taken a different approach this month to provide more details on the “what” and the “why” of our work. If you have any feedback on this new format, please let us know as we’re always looking to improve our communication with the community.

Overall, we’ll continue to be nimble in making adjustments based on market conditions, community requests/concerns, and serving Balancer’s best interests.


Hi immutbl,

Thanks for the detailed update and your efforts - also greatly appreciate the cost-cutting given current market conditions.

Not sure if this is the right thread for it, but would like to share some feedback on landing page design:

1- The anatomy of a high-converting landing page traditionally entails 7-11 word summary of value proposition with a high converting CTA button. The current landing page breaks the 8-second rule as it rotates value proposition. We should not expect the user to sit and read the rotating text.

2- The CTA button is very muted and I am unsure ‘explore pools’ is a good CTA-text. Also segregating “Build” on the navigation bar is a very unusual design choice - navigation buttons should be grouped together. I see you have google tags enabled (assuming it’s properly set up for the latest version), would recommend comparing bounce rate and behavior flow of old version and the current version to measure success.

3- Over 90% of high-converting landing pages feature at least one link; the more links you put up the more chance to lead users to off-site. The current landing page purposefully looks designed to lead users off-site, is this the intention? There’s no header to give context to the logos of ecosystem partners that a first-time user sees on the screen. Imagine a user clicking on 1inch to swap; you just lost fees to competitors. I think a better approach that would lead to reduced drop-off would be to have Ecosystem as your second container and embedding logos by partner importance as an image on the right with a button and copy text on the left that leads to another page.

4- Information hierarchy is pretty messed up - you want Ethereum mainnet stats to be on top as your easily digestible social proof rather than burying it near the footer. Would be great if we can have consolidated stats of all chains.

I understand positioning Balancer as a protocol or product enabler, but considering aggregators currently accounting for 25-30% of DEX volume and the current state of the treasury; I think it is of utmost importance to have a high converting landing page that leads to a great trading interface to boost Balancer share of DEX volume.

While I’m on this topic, Coingecko API is constantly flashing errors, so I would consider reducing dependencies or improving performance as it gives a bad UX for the end-users.

Would also consider removing Coingecko price chart, trending pairs, my wallet fluff on the sides of trade page to give a more clean and non-diluted trading experience for the users.

Happy to ask my UX/UI designers to give feedback pro bono during design stages should you guys require the additional help.


Thanks for the feedback @C0_G1

I designed and built the new sections on the website, with consultation with other members of the Balancer ecosystem.

You may not agree with our decision decisions, but here is some context that may help you understand our choices:

  1. Balancer is a protocol not a product.
    The Balancer protocol is open-source, neutral technology. Think of the first versions of the web app as a proof-of-concept build on Balancer protocol. As the ecosystem evolves into a vibrant community of builders, the Balancer web app should transition towards being a neutral ‘block explorer’ of the Balancer ecosystem. Ideally, most new pools will be created by third party partners who will also control the UX and liquidity management on their own UI’s. Over time, balancer.fi should reflect this neutrality and not necessarily give preferential treatment to specific products building on Balancer.

  2. This is step 1 of a multi-part project
    Think of this update as a reset point. We deployed a stripped down version this month to address risks with keeping content that didn’t align with the protocol and which has been recently identified as confusing the lines between DeFi and regulated finance exchanges. Our plan is to have a more robust home page shortly. This could include creating more content around the core concepts of the protocol and potential use cases that inspire builders.

Addressing your points:

I understand positioning Balancer as a protocol or product enabler, but considering aggregators currently accounting for 25-30% of DEX volume and the current state of the treasury; I think it is of utmost importance to have a high converting landing page that leads to a great trading interface to boost Balancer share of DEX volume.

It sounds like your core premise is that aggregators only account for around 25-30% of Balancer DEX volume, so we should be driving people to the app.balancer.fi swap UI.

This 25-30% DEX volume you mention is not accurate for Balancer. I understand that the Balancer UI contributes no more than 4-5% of all swap volume on average. The reality is, Balancer relies on third party aggregators (especially 1inch) to provide swap volume and therefore, protocol revenue via swap fees.

[Dune – Balancer volume sources]

This means, it is not as critical as you suggest to convert people to the swap interface. On the other hand, it is critical to get more developers to build on Balancer and attract more liquidity. Partner liquidity can then more easily be incorporated into aggregators like 1inch (so long as we continue to foster strong relationships). More Balancer liquidity available to aggregators leads to more protocol revenue via swap fees.

1- The anatomy of a high-converting landing page traditionally entails 7-11 word summary of value proposition with a high converting CTA button. The current landing page breaks the 8-second rule as it rotates value proposition. We should not expect the user to sit and read the rotating text.

I agree with your sentiment here, and we can look to tweak the timing of the animations.

In my opinion, the line ‘Build DeFi liquidity Applications’ is the core value proposition for the target audience of DeFi developers and this is displayed immediately. I think it’s fine if this is the only message someone sees and understands from this page. But after 4 seconds (comfortably within that 8 second window), the text animates to the next line. If someone is interested, they’ll understand this is dynamic text and can continue to watch the remaining items. These extra lines help to show additional possibilities of building on Balancer but are ancillary to the core message that Balancer is a place to ‘Build DeFi liquidity’ products.

2- The CTA button is very muted and I am unsure ‘explore pools’ is a good CTA-text.

Again, I agree with the sentiment. I feel a little uncomfortable not leading with a high contrast primary CTA button, which is certainly a best practice on traditional marketing sites.

However, as mentioned above, the Balancer protocol should aim to become more neutral over time and give less preference to app.balancer.fi. A neutral protocol will attract more developers into the ecosystem, including those who want to build competing front-ends, which will further decentralize the ecosystem. However, it’s too early to completely remove the CTA.

Another minor reason for keeping it muted is this CTA leads people off the site. This is unlike most traditional marketing websites that try to keep people on the same website to convert. To take the user immediately off the site could also feel abrupt.

The CTA text ‘Explore pools’ reflects the decision to remove financial terms. I’m happy to hear alternate suggestions.

Also segregating “Build” on the navigation bar is a very unusual design choice - navigation buttons should be grouped together.

I agree. As mentioned, this is a multi-step process with the first step being to remove any pages that could incorrectly present Balancer as a financial service.

The plan is to create new content pages and return back to a more traditional primary navigation with links soon. Some suggestions for pages to be linked to from the primary navigation include:
– A page on core concepts of the protocol
– A page about the DAO
– A page outlining the token
– A page about Grants

Let me know if you have other content suggestions.

3- Over 90% of high-converting landing pages feature at least one link; the more links you put up the more chance to lead users to off-site. The current landing page purposefully looks designed to lead users off-site, is this the intention?

This ecosystem section aims to show a vibrant community of partners and protocols building on or with Balancer. As mentioned, it aims to be more neutral compared to the previous version. Some additional work needs to be done around the content and descriptions of each partner but overall, this should be a place where people can see the breadth and depth of the building community, along with example use cases.

In my opinion, we shouldn’t feel that people adding liquidity to other partner protocols like Beets and Element are ‘off-site’. These are partners which generate revenue for the Balancer Treasury (assuming the DAO is able to negotiate revenue share).

Imagine a user clicking on 1inch to swap; you just lost fees to competitors.

1inch is the lifeblood for swap volume on Balancer. It generates 10x the volume versus the Balancer UI. This leads to swap fees for LPs and protocol revenue. In this regard, I don’t see 1inch as a competitor but as a valued partner. It’s more beneficial for Balancer for someone to use 1inch vs Uniswap.

There’s no header to give context to the logos of ecosystem partners that a first-time user sees on the screen. I think a better approach that would lead to reduced drop-off would be to have Ecosystem as your second container and embedding logos by partner importance as an image on the right with a button and copy text on the left that leads to another page.

I agree that the hierarchy of this section can be improved. Since launching it, we’ve already had a lot of interest from other partners who’d like to be included. So we’ll also have to think about better ways to sort and filter these.

4- Information hierarchy is pretty messed up - you want Ethereum mainnet stats to be on top as your easily digestible social proof rather than burying it near the footer. Would be great if we can have consolidated stats of all chains.

The information hierarchy of the homepage (and entire site) can be improved. Stripping out the content that could be incorrectly present Balancer as a financial service has disrupted the narrative flow of the homepage. A content strategy is planned to determine the information architecture and content required to attract DeFi developers.

Regarding the stats: This was demoted from the top section of the page, simply because the data is not real time, which means that it is often out of date. This has led to some confusion and misinformation on Twitter. Once this issue is fixed, the positioning of this section can be re-evaluated.

While I’m on this topic, Coingecko API is constantly flashing errors, so I would consider reducing dependencies or improving performance as it gives a bad UX for the end-users.

I’ve also noticed this. The front-end development for the web app is driven by the Op Co (not Orb). I’ll pass on this information and think about graceful degradation when Coingecko’s API is down.

Happy to ask my UX/UI designers to give feedback pro bono during design stages should you guys require the additional help.

I’d be happy to collaborate. There is plenty of work to do to create a compelling cohesive narrative to attract builders. Feel free to reach out.


Thanks for taking the time for a detailed response.

I think the core issue that I have which is reflected in the feedback is the gap between current revenue streams and how Balancer would like to position itself as a protocol.

I think we can both agree AMM/APM side is the main revenue stream by far. From my experience, it’s a very risky bet for a high-growth, negative EBITDA company to re-position its product in prod betting on future value generation from these cool applications of its protocol.

I’m a regular user of both 1inch & CoW Swap, and very bullish on aggregators as a whole, but shouldn’t a protocol whose main revenue comes from swap fees try to at least make on-site swap volume / total swap volume a core metric to track and improve? I see tremendous opportunity to improve that metric.

Based on Binance Global Crypto user Index Research, only 10% of users identify themselves as DeFi native, which explains how MetaMask is able to generate revenue with its extractive fee model. Why does Balancer give extremely valuable real estate to CoW Swap on the trade UI, a protocol whose core settlement logic prioritizes bypassing liquidity providers, and then seeking best price across AMMs?

Do apologize if this is coming off as too confrontational - just curious about the business decision flows feeding into these design briefs.

Very happy for you to take the time to respond. Thanks.


I agree that more effort should be spent to attract swaps on app.balancer.fi.

Orb wasn’t involved with the decision to use Cow Swap as the primary interface for the Balancer swap UI. However, my understanding is that ecosystem members could see a clear trend towards the usage of aggregators. I understand Balancer’s strategy was to align closely with aggregators who could support innovative custom Balancer pool types and provide swap users with the best possible experience – i.e. the most efficient swap routes with MEV protection. Obviously, this was at the cost of directly routing people through Balancer pools. It also requires Balancer smart contracts to be extremely efficient in order to outcompete other protocols in order to be selected by aggregators, since there is no preferential treatment.

I also understand that having a Swap UI in the first place added some risk given regulatory uncertainty around the operation of exchanges. Due to this, there were discussions about completely removing it from app.balancer.fi. Since the CoW integration, little to no work has been done to improve the Swap experience on Balancer (due to this uncertainty). I believe with the decentralization efforts and change of organization who primary leads development of app.balancer.fi, the Swap UI shall continue on. Of course, in the meantime, other Swap interfaces including CowSwap have improved significantly. So it would require some effort to compete. I guess a cost-benefit analysis should be performed.

Sidenote: I think that the general DeFi 25-30% aggregator DEX volume you mentioned previously, may be distorted by Uniswap massive volume via their UI. Outside of Uniswap, I suspect most DEX’s are 95%+ driven by aggregators.


Hi @C0_G1,

First of all, thank you for your thoughtful points and questions.

To share my view of Balancer’s future, I envision revenue generated via multiple fee collection mechanisms, based on diverse liquidity pool types that handle different use cases.

Four reasons why I think we should be looking beyond swaps and the pure DEX use case for Balancer long-term:

  1. AMM swap fees have been trending toward zero and thus, in my opinion, are not the most solid foundation on which to bet Balancer’s future.

  2. From a front-end UI perspective, swap activity has been trending toward aggregator marketshare consolidation. On Balancer in particular, it has been true for a long time that the overwhelming majority of swaps come through backend integrations, not our UI. Spending resources fighting against that trend as opposed to pursuing more promising growth opportunities doesn’t make sense to me.

  3. Balancer’s most unique value proposition and strongest competitive advantage is its flexible design, which allows the creation of liquidity pools that aren’t possible on other AMMs (ie LBPs, boosted pools, fixed rate markets, managed pools, TWAMMs). This positions us as the best solution for developers.

  4. The growth potential of a platform that is integrated into many different products is exponentially higher than that of a single product (ie DEX). As the DeFi space grows from its current infant state, Balancer has the opportunity to serve as liquidity infrastructure for the inflow of new projects that will be built, growing alongside each one simultaneously.

So, I actually think the risks and opportunity costs associated with betting on DEX volume (even moreso from direct retail users), as our driver of success, are not justifiable.

For the reasons above, I think that over time the percentage of fees collected on Balancer will shift away from swaps toward more novel mechanisms such as capturing yield from yield-bearing assets, auction-based fees from LBPs, AUM-based fees from Managed Pools (currently in development), and other mechanisms that our developer ecosystem will build with us in the future.


Hello, I am currently going through this process of deep diving into manager pools on an independent basis right now. I’d be curious to hear more about your progress on these steps so far, where your thinking is currently at and more details on what you plan on doing over the next month, thanks.

To me it seems like the best (and only) example is currently Valory/Autonelas

Without looking at any code and guessing, since you are relying on arbitrageurs to fill or drain the pool’s balance, the problem is around the 0 limit token weight comp.

If you start from 0 → desired weight, I imagine arbitrage swaps would be very inefficient/choppy because you trading at the extreme end of the liquidity curve. Conversely, once you go from desired weight → 0, around the 0 end, you hit those inefficiencies again as the token comp nears 0 for the same reasons. Curious what your proposed changes would be to solve this and whether they are sufficient.

Are you dead set on using arbitrage mechanisms for token additions/removals or is this something that might need to change in the future?

For the initial liquidity, there are two distinct phases that might not be immediately obvious.

  • The first is going from 0 liquidity, to minWeight (1%) liquidity. The current mechanism for this utilizes asset managers to set a virtual balance in order to get around zero (and near-zero) balance. We use swap fee rebalances (gradually shift from ~100% to ~0% swap fee) to address the otherwise inefficient/choppy arbitrage opportunities.

  • The second phase handles 1% → desired weight and is a simple gradual weight shift.

This is not the only add/remove token mechanism possible in managed pools; just the first one we are implementing. For example, a few examples of future techniques might include:

  • replaceToken – remove all of TokenA, trade it to TokenB, add TokenB at the same pool percentage TokenA was at
  • Seeded AddToken and Custody RemoveToken – these would have trust assumptions and custody risk for the manager. The idea here is that to add TokenA, the manager would need to provide a minimum of minWeight (1%) of the pool’s value denominated in TokenA

Thanks for your response.

  • If you are trying to remove a token from the MP, is it possible that there will be permanent token dust left in the pool (e.g. less than .01% token composition)? In practice, I am curious whether you need to rely on many swaps or if you can go from 0 liquidity to minWeight (1%) liquidity in just a handful of swaps? Do you also expect the swap rebalancing here to happen over a short period of time ( less than 5 blocks) or it just takes as long as it takes before the rebalance hits the desired minWeight?

  • Is the swap fee for rebalancing dynamic in that it can go from 10% → 15% → 5% → 10%? Or is it a monotonic linear decay that goes from 100% → 80% → 30% → … → ~0%?

One other question I have is around the composability of the Managed Pool Controller smart contracts and I apologize in advance if this is the wrong place to ask. Does the Managed Pool Controller have composability with the smart managed pool structures that Valory is building? Or are these two products being built in isolation and intended to be used seperately?

Congratulations to Immutbl and the whole team at Orb for realising these significant savings. The OpCo has returned Orb’s December Funding of USDC 291,238 to the DAO multisig, Tx hash: Ethereum Transaction Hash (Txhash) Details | Etherscan

Happy Holidays!