Osmosis Support Lab Funding Round March 2025-2026 [Revised] [Revised(2) - 6mo. funding period]

Osmosis Support Lab Funding Round March 2025-2026 Revised

Over the past week, members of the Osmosis Support Lab have worked hard to reduce the budget as much as possible to accommodate the requests from our last proposal’s forum post. We were able to greatly reduce the ask amount by eliminating costs for team management, dev support, social media support and leaving the web support live. We will still continue monitoring social channels throughout the day, as well as the developer chats, but all support requests will be directed to the support website. Response times will largely remain the same, as we will still be providing 24/7 support through the web support widget which is the most highly praised feature by the users who come to support or leave feedback.

Maintaining 24/7 Coverage

Our main goal is to maintain 24/7 coverage for the protocol. There are many reasons we feel this is important to maintain outside of being attractive to users - some examples of this are:

  • OSL was aware of the liquidity duplication exploit incredibly early due to constant monitoring, which helped to prevent a very large loss of user funds. With downtime, larger issues may potentially be unnoticed for hours at a time.
  • Scammer posts and impersonators don’t take 8 hour breaks to try to scam through telegram or discord. There are always scammers responding in discord to every request, and often find ways to break filtering/message removal. As OSL has assisted in over $250k of token recoveries the past year, we know how quickly users can get scammed when unsupported or messages are left unattended. We are also able to rapidly blacklist phishing URLs as they appear or are reported, preventing other potential victims if they were allowed to remain accessible.
  • User retention by eliminating frustration when issues present - people tend to give up easily. Having a responsive team able to address concerns without downtime prevents users from giving up or leaving to a different platform.

Team Structure and Internal Changes

From an internal standpoint, embracing reductions to pay and implementing these changes allow us to largely keep our current team intact. While there is only one person ‘paid’ on shift at a time, having an active team to be able to relay issues to and discuss solutions with is often incredibly helpful - this prevents us from dropping down to a team of ~3 which would remove a lot of our ability to problem solve some of the more complex issues in a timely fashion.

Knowledge Base and Self-Support Implementation

Additionally, over the last funding cycle we have implemented a common issue tracker/knowledge base which is being flushed out to provide quicker support/supplement the live support chats. While this is a constant work in progress as issues are reported, the intention is to use it for chat flow/‘self support’ in the near future, which is a point that was mentioned in the previous forum post. We have played around with implementing chat flow already, and noticed several users giving up as soon as presented with menu options. We’re working on a better way to implement this in a way that doesn’t cause users to get frustrated or leave without being assisted.

AI Solutions

AI solutions were also mentioned in the last proposal thread. While we dont feel this is currently a good replacement for having real knowledgeable responses to issues, we have moved to incorporating AI tooling as a form of message moderation. As of now this is being employed to the Discord as an extra layer of security, and so far in testing has reduced a large amount of manual intervention. We’ll be looking to continue employing these solutions to other platforms going forward.

Polaris Support

Polaris support at this stage is a complete unknown. There were suggestions of a staged approach in the last post - we agree with this, and any requirements or scaling related to support of this protocol will be addressed at a later date. The OSL had allocated capacity towards this in the past request, however with the unknown nature of this launch (timing, users, support volume, etc) we agree it doesn’t make sense to proactively try to allocate resources. The Polaris team will be covering support for this platform in its early release stages, and once there is a wider release we can come back and discuss requirements further with the team and community should it be required.

Budget Reduction

Overall, these changes will reduce our funding request by over 43% from $485k (with a 50% OSMO request) to $275k in USDC.

Monthly Cost Yearly Cost
Web support $21,900.00 $262,800.00
Tooling $1,000.00 $12,000.00
Total USDC Requested $22,900.00 $274,800.00

By fully removing the $OSMO ask from the proposal, we’re eliminating concerns about sell pressure that were brought up by the community. However, we are unsure if the community would still find a mix of funding including $OSMO more favorable, and would love to hear feedback on this point in particular. To add some further perspective, this budget in its current form would be covered by around 2 weeks of protocol revenue accrual for the year, or around ~3% of yearly accrued protocol revenue.

Conclusion

Overall, we hope these changes address some of the concerns that were brought up in the last forum post. Our team is dedicated to supporting the protocol and community - we greatly value the input provided on both fronts, and remain open to any feedback, comments, or suggestions.

6 Likes

Much more reasonable and the removal of the $OSMO from the payment is a big plus.

USDC should be the go-to whilst the markets are weak and there are enough funds to cover spend props in the reserves.

2 Likes

This is in the right direction, but it is still too vague.

Given the climate, price points, and maturity of the product… I think it makes more sense to re-open the discussion around the Osmosis Support Ecosystem from the ground up instead of the top down traditional route that’s been taken over the last 3 years.

Why have we gone 3 years as an ecosystem and not had a better system in place that leads to improved efficiency? This is something the Community, OSL/ISG, OGP, and the Osmosis Dev team should all reflect upon and address.

I’m going to brainstorm and throw up a forum discussion with a bunch of ideas that are a bit more zoomed out. There are many aspects that aren’t touched on that really should be discussed (not the fault of OSL), but the Osmosis Support Ecosystem as a whole can likely benefit from a larger discussion.

  • I do think it’s important to maintain the existing support while optimizations/efficiencies are worked on btw, so will also brainstorm solutions there for the community to consider.

Hoping to find solutions the entire community can get behind, even the OSL.

(my ideas are my own, not a representation of the dev team’s)

2 Likes

What would you like clarification on?

Hi Aaron,
I have to admit I am a bit confused by your post to be honest.

  • What better systems do you want to have in place?
  • What about our proposal is vague? I think it is pretty clear what we offer
  • You mention optimization? Optimizing what exactly?

If you need clarification on any aspect of the proposal let me know :slight_smile:

Sure

  • How exactly does $485,000 drop down to $275,000. This is a substantial drop in funding requested, would be good to see the breakdown.
  • Edit * Additional Question. How large is the tradeoff in coverage that is being made? Sharing in detail what is specifically going to be sacrificed is important so the community can determine how to proceed. ie, pay more? make a trade off itself ? or figure out if it’s necessary to ensure that sacrifice is brought back some other way
  • AI Solutions, this is a new feature that requires work to implement which then in theory improves efficiency / reduces work. There should be a cost to that endeavor, ie whoever is doing it needs to be compensated. There’s no breakdown of that, estimated timelines, who would be doing it.
  • 24/7 support, the points are valid, but this discussion never really tries to argue for efficiency. This has been the case for the last 3 years, including when I was on the OSL. Should be looking at how other major support providers address this. How does uniswap do it? dydx? Solana eco? I think there are solutions to having the cake and eating it here. Will detail those in a separate post.
2 Likes

Dropping my comment in the other post here as well for visibility. @maxpower I’ll also reach out to you via DM to discuss!

1 Like

I personally see no point. What are we (“we” as in the protocol) gaining from that arrangement?
Involving an arbitrary middleman is just adding to the cost… isn’t the cost the whole concern to begin with?
I mean, either governance grants us the funds or they give it to you (or don’t get it back at the end of the funding round, or however that works out) which inevitably incurs additional admin cost.

1 Like

I’d see it as a cost reduction, both in governance overhead to you and the community:

and probably in actual financial cost as well. OGP funds other critical services for the Osmosis community (Fireblocks, DAODAO, Numia, etc), and ISG/OSL is very much a critical service, so in my opinion this is within our scope if it’s needed.

But to be clear, the OSL has been funded by governance since its inception, and as long as governance is fine continuing to do that it works for us. I just wanted you to know the option is available to you if you need it.

3 Likes

Yes I suppose it does get rid of any responsibility for us to create reports for metrics, do the dreaded PR thing, etc… we will discuss.

3 Likes

The drop in costs is directly the result of our organization’s optimization/efficiency improving as a whole. Historically if you look at what we were spending vs now, it’s a bit disingenuous to say we haven’t had any systems put in place to improve efficiency over 3 years.

Every proposal since inception has lowered and streamlined costs to the community. The biggest and most notable improvement was the OSLs collaboration with Interbloc to form the ‘ISG’ org - Every internal process with the staff has been streamlined, and costs have been dramatically cut. Internally, we’ve changed and adapted every paid member’s position to be more inclusive and cover more ground - this has led to the constant drops in funding ask every single round, including the current version of the proposal having a dramatic drop.

We’re at the stage now where this team doesn’t need a dedicated (paid) management system directly covering the staff for Osmosis. We had some hesitation that this was the right time to further slash these expenses, but when Polaris is removed from the equation for now and not ‘pre-allocating’ resources ahead of time, we came up with a lot of effective cuts to make without compromising the actual product offering on the table.

What’s not changing is the 24/7 service that the team has been providing. We will push more users away from support on socials to streamline web chat and make it easier for each agent on call. We have cut and eliminated the ability to scale if support becomes unmanageable for any one person, however as part of the feedback if we do need to ramp back up this could be part of a separate ask or addendum(eg, polaris support needing additional management/staffing at some point). With things the way they are right now, this isn’t currently something we need to worry about

The things we cut from the funding ask are

  • Costs for social channels - requests will be further funneled to the web chat service. This will provide very minimal impact to the community as a whole. This doesn’t mean these channels will be unmaintained, as a vigilant eye is part of the product offering that OSL provides. These are currently at activity levels where we don’t need to dedicate extra resources to maintain.

  • Dev support - While we plan to maintain this as a team, we have cut dedicated funding for it as this is something that can be incorporated as a team effort to current duties. On the previous proposal, this was a line item budgeted for and executed upon. The fact that we had one member assigned to this is exactly the efficiency being asked for - it’s also worth noting that one member being effectively assigned for oversight on this item is now being used to say this shouldnt be a part of OSL. These two thoughts seem counter to each other, as this has had quite a positive impact overall.

  • Tooling - This has again been cut back. There were contingencies in place to be able to adequately scale/create tooling if required for the new product release, but realise this makes more sense to address at a later date if required. Right now this accounts for costs for our web widget, agent seats, and things like Slack. There is still a little bit of room here for development of new tooling to assist the community if that becomes required, but the existence of this line item does not necessitate that all of it is spent each month

  • Management costs have been cut. Our team does not require active paid management to operate any more. Increases to efficiency and accountability mean this is largely a team effort. This doesn’t mean it’s the old days where there was nobody in charge at a higher level with OSL, it just means that the people who are assigned to be responsible at a higher level aren’t asking for extra pay to continue duties at this time. The level of involvement and required oversight without need to expand in the near future doesn’t currently call for dedicated funding, and getting our proposal to a level where our staff is able to keep their jobs is a much higher priority.

  • Contingency funding has been cut- there is no need for this, as the ask is currently in USDC. This line item was included to account for any price movements while we executed funding swaps.

Again, regarding mention of better systems to improve efficiency - it seems pretty apparent, at least to us, that these efficiency increases have been fairly dramatic over the last 3+ funding cycles. The costs have significantly reduced, and due to the Interbloc<>OSL merger to ISG being in place, costs to the protocol have plummeted from the early days.

Nobody on the team would have any issue discussing further improvements to the way we offer or streamline our services, but we’re at the point with this cycle where we won’t be able to pay the staff to continue past the end of this month - we’re always open to having these sorts of discussions at any period. Historically however, these sweeping concerns only ever seem to come up at a renewal regardless of changes we implement as a team, and a commitment to these sorts of talks from all sides over a longer time period would have a great impact on this.

We’d be completely open to putting together a group with the OGP or anyone else to chat about these concerns over a longer period - It should be clear from the changes introduced that we did our best to incorporate all concerns raised in the last thread in a way that allows us to continue service at a much more baseline cost level to the community. While further changes can absolutely be discussed and agreed upon, we do strongly feel (and agree with the above note) that these current processes should remain in place while any further changes are discussed. We’re listening to the feedback - but there needs to be some give and take in order to make this work.

All we’re currently asking in return from the community and devs is effort from all sides to discuss and move forward addressing concerns from here without those talks and outcomes being unnecessarily rushed. We’re a very fluid team - open to suggestions and open to change, as is evidenced by the effort of everyone on the team to listen and adapt based on what we hear.

We agree with Robos sentiment - if the community agrees to allow this proposal to process in its new reduced format, this will allow time for talks that should take place and incorporate protocol changes/developments over the next 6-12 months. If we all come to the conclusion that going forward funding should be requested elsewhere, at least there will have been proper amounts of time to collaborate and come to a mutual conclusion for all teams involved without those talks effectively being overshadowed by the threat/worry of service discontinuation. At this point, the funding is essentially to keep our admins who have left other positions to work for this community employed at some level of a living wage.

While not the fault of anything but the nature of the industry, our admins don’t get PTO, any sort of tax or benefit assistance, no health care to speak of, and as evidenced by the stressful nature of these proposals every cycle, no sense of job security. We sincerely hope that what we’ve presented is at a level where we can get some support back from the community and developers - we need to work together more closely going forward and have these sorts of discussions in a format that doesn’t necessitate the need to lay people off or to potentially shutter our services completely.

2 Likes

Thanks for all the alterations, work and openness to adjust @Kych @maxpower @ctrl-Felix

Where I can fully understand the frustration of having to go over and over these kind of conversations on every funding round, whereas other elements are funded without much discussion which cost way more and are less visible.

For now I would propose in this channel to just go with it and fund the OSL for at least a proper 4 months as mentioned in the other thread, while we work out how the desired form of support looks like. We can take a loooooot of time in here to iron out the last bit of pennies, but that is also time wasted which is not put into the future solution. If we look at it from a lean perspective, this is a small bit of waste with a trade-off of doing the right thing at the same time. I’ve worked in retail for a long time on lean subjects, and when proposing a similar solution to management, it would be a no-brainer.

So please let’s stop the final details in here, put this one on chain and focus on the other thread.

CC: @aaronxkong @RoboMcGobo

2 Likes

Hey guys.
we appreciate all responses and feedback and we are happy to discuss working with OGP during the upcoming funding cycle.

We will be moving forward with the proposal at a reduced time period of 6 months and have already reached out to have talks with OGP to move the funding structure to their purview if it’s feasible.

On chain budget will be reduced to a total of 137,400USDC - and funds can easily be returned or rolled in to any agreement made if theres an arrangement met at any point during the 6 month cycle.

4 Likes

Oops, I put up the revised proposal but forgot to edit the title.
The content is accurate though. Ignore title.

1 Like

I don’t understand how many people or hours of work is this covering. Wouldn’t it be fair to let the community know the hourly wage and the amount of hours worked during the last months? Is there a dashboard where we can see how many tickets were solved and similar metrics to evaluate the efficiency and effectiveness of this program that we are funding?

Did you see this thread?

There are a lot of numbers and figures in there already. On the forum for longer than this thread :wink: