The ONEX Liquidity Playbook

Discussion
1

The ONEX Liquidity Playbook

The DEX Market is saturated. How can ONEX not only carve out a portion, but also become a leading DEX?

TL;DR:

1. Abstraction
2. Specialization in Forex & Real World Assets

History Repeats, But We Don’t

The liquidity merry-go-round, where capital chased the hottest yield, only to leave ecosystems as ghost chains? All attempting to recreate Sushiswap’s vampire attack on Uniswap - a classic heist of liquidity. Repeat the same process and observe the same fate.

Leveling Up: Beyond Basic Incentives

Incentives are more effective when done through DAO-to-DAO incentive matching. This isn’t new to us - shoutout to our Osmosis collab where liquidity more than 10x’d in the NOM/OSMO pool with incentives paid in both NOM and OSMO. Not only does liquidity grow, but collective awareness, community exposure, and co-marketing opportunities come along with it. ONEX should look to replicate this DAO-to-DAO incentive matching for not only IBC, but non-IBC ecosystems too. Played right, ONEX can become the AMM+Orderbook DEX Hub for exposure of IBC assets to a non-IBC world, and vice versa. The Arc Bridge Hub is a core piece here, but more on this later.

Diving Deeper: Liquidity’s New Frontiers

What if instead of attracting liquidity to you, you are able to bring liquidity to the user? This is done through liquidity aggregators. The net effect is that assets not yet listed on ONEX can still be traded in ONEX through intelligent routing. Examples of this includes Squid Router, built with Axelar. While I believe the product itself is great, ONEX aims to generate protocol revenue via spread capture (effective fees) on trades. Routing through Squid Router will effectuate a fee paid to Squid Router and not generate revenue for ONEX – potentially outweighing the benefit of an aggregator as it does not serve ONEX’s protocol revenue goals.

Enter the Skip API. I propose an exploration of integrating Onomy’s ecosystem with the Skip team. For context, Skip started out as extremely efficient MEV extractors and have since grown to various public goods for the Cosmos stack. One solution Skip offers is the Skip API. In their own words:

Skip API is a unified REST/RPC service that enables developers to create seamless cross-chain experiences for their end users using a variety of underlying cross-chain messaging protocols, including IBC, CCTP, and Axelar. We’re on a mission to make all interop dead easy

We’ve designed it so that even developers who are completely new to interoperability and have never worked with any of the bridges or DEXes we use can build applications and frontends that offer:

  • Single transaction any-to-any cross-chain swaps with built-in cross-chain DEX aggregation under the hood
  • Cross-chain contract calls that allow users to take actions on remote chains without having to explicitly bridge in separate transactions
  • Multi-hop cross-chain transfers with automatic denom & path recommendations for any asset and chain
  • Composite bridging paths that use multiple underlying bridges for different stages of the path
  • Real-time cross-chain workflow tracking, along with gas + completion timing estimates
  • Fast / prioritized relaying
  • Protection from common cross-chain UX failures (e.g. bridging to a chain where the end user doesn’t have gas)
    … and much more

The API is completely free to use and permissionless to integrate with. Unlike Squid Router, Skip does not take fees on swaps or transfers now and never will. The cross-chain swapping, transferring, and routing functionality is completely free now and always will be.

Therefore, Skip API provides the benefits of liquidity aggregation enabling users of ONEX to trade any pair from any DEX/Chain integrated with Skip. All the while, everything is abstracted away from the user so they do not have to manually choose a bridge, network, etc. Additionally, ONEX can customize its own fees for facilitating the path via the Skip API. This would require some customization to then work its way into the programmatic buy & burn model of NOM.

This is very similar to the goals of the Arc Bridge Hub. While Arc deserves a nuanced discussion thread of its own, I did bring this up to the Skip team. After a very engaging discussion (h/t to awesome team at Skip), we identified the following:

  • Skip can integrate ONEX to their API. Users of any other DEX, Wallet, or dApp that uses the Skip API (Osmosis, Stargaze, Leap, Astroport, etc) can access and utilize ONEX. This opens ONEX to many more users, all of which would generate more protocol revenue via ONEX fulfillment of trades provided that ONEX has the best quote for the desired asset. These assets will most likely initially be NOM, ONEX, and other native Onomy Ecosystem assets like the upcoming stablecoins from the Reserve, along with additional community projects / consumer chains as they come online.
  • Skip API can also integrate the Arc Bridge Hub. If Arc provides the best routing for a particular asset, Skip API will take it.
  • Skip API for onboarding experience on front end over existing bridges into NOM so outside users can easily enter Onomy with any asset from integrated bridge.
  • Skip API enables Onomy to charge a fee for routing trades for ONEX users and apply the buy and burn. It can also only be customized to enable Skip API routing if a user wants to trade a pair ONEX doesn’t already have sufficient liquidity for yet, rather than on all pairs by default. This can be “back-up” behavior so that ONEX does not lose a user to insufficient liquidity of a desired asset.

Additional UX Improvements: Fee Abstraction and PFM

Fee abstraction and Packet Forwarding Middleware (PFM) are on the horizon. FeeAbstraction enables users to pay gas for transactions with any IBC token. This can be NOM, ONEX, or Reserve Stablecoins for example. Whereas PFM enables token transfers to automatically forward through multiple IBC channels, allowing for improved UX. This can be useful to “unwrap” IBC tokens that have been bridged through multiple networks. This can also be used to transfer non-native assets from one chain to another, multi-hopping through the native chain in between, with only a single transaction signing. PFM translates to you being able to sign one transaction to complete a swap that could have been 3 or more via bridging, swapping, and bridging back.

Foundation Set for The Big Picture: Specializing in Forex and Real World Assets (RWAs)

Fast Forward. ONEX is highly optimized and abstracts away many technicalities that provides a buttery smooth UX integrated with every relevant ecosystem. How does it scale? Forex and RWAs. We’re not merely speculating about potential growth—stablecoins are on a trajectory to encapsulate a market cap in the trillions, incorporating major global currencies such as the EUR, JPY, GBP, and more, alongside the USD.

It’s not just about creating a seamless experience, either. It’s about providing real solutions to real needs. Onomy’s approach is grounded in the practical application of stablecoins to revolutionize how we interact with the global financial system. Imagine having the capability to onboard with your local currency and seamlessly transition into a global currency like the USD, accessing a broad spectrum of services in DeFi without ever leaving the digital realm. This scenario is not just a convenience; it’s a radical shift towards empowerment and inclusion, offering instantaneous transactions, global payments, and trades with full control over your assets. It is the Internet Financial System.

Specifically, Onomy aims to:

  1. Enhance Accessibility and Inclusion.
  2. Bridge liquidity, reduce fragmentation.
  3. Streamline cross-border transactions and on-chain Forex trading by providing familiar tools and traditional exchange features.
  4. Democratize access to Real World Assets (RWAs) to improve liquidity and access for RWAs like commodities.

Proposed Operational Steps

  1. Onomy Reserve: Launch a suite of stablecoins through the Onomy Reserve with minimum required liquidity constraints and collateral. Each stablecoin issued requires DAO approval via governance.
  2. Liquidity Pools and Incentives: Create dedicated liquidity pools for major Forex pairs (e.g., EUR/USD, USD/JPY) on ONEX. Consider liquidity mining incentives to bootstrap additional liquidity to ensure competitive spreads and depth from the outset. DMM programs as well.
  3. Aggregation & Distribution: Facilitate distribution in and out of ONEX through Skip API, Arc Bridge Hub, and/or other means to enhance liquidity and access to the Forex pairs.
  4. Derivative Products: Add derivatives products, including futures and options, allowing users to hedge positions or speculate on currency movements. This will attract a more diverse user base, including institutional traders and sophisticated retail investors.
  5. Stablecoin Value-add Partnerships: Enhance Onomy Reserve issued stablecoin liquidity, backstops, and access via on-off ramps, pools with USDT / USDC / DAI and other stables.
  6. Building on Forex Foundation: Add RWAs, including commodities and other tangible assets. Tokenize access to assets such as gold, enabling instant transfers of ownership and new proof-of-reserves technologies, on a global 24/7 trading platform owned and operated by validators and contributors across the world.

Ambitious? That’s why we are here with 60K+ community members and contributors situated around the globe. This is just the beginning!

Interchain Security and Beyond

With Onomy becoming the second provider chain in all of Cosmos, after the Cosmos Hub, its ambition is not to compete with the Cosmos Hub as a generalist Hub, but to become an on-chain hub specific to FX and RWAs for all crypto.

Your Part in This Journey

This is a call to arms for the Nomads, the visionaries, and the builders. Our collective input, expertise, contributions and passion are what will drive Onomy forward. Reach out, get involved, and let’s build the Internet Financial System.

I look forward to discussing with all of you.

Onwards and upwards,

Lalo

19 Likes
2

Hey Lalo! Thanks for this. I think a lot of us were trying to understand what liquidity would look like on ONEX.

Totally agree with your point here. We can’t just do NOM incentives forever - sure, we have chain inflation and a portion of that could be allocated to incentives but as we’ve seen in gamefi over and over, if the incentives are not sustainable, price falls short.

Anyone could say that ‘bring them over and they’ll stay because of the experience’ to favor the liquidity incentives approach, but while naturally true it’s shortsighted as the price still suffers. Skip could be the way to go here to target liquidity from all other DEXs, but I’d also expect having one committed capital partner that allocates significant liquidity to ONEX because they’re bullish on it and want it to succeeed. Of course, that’s never a permanent solution as it could be pulled at any moment to capture a potentially more profitable opportunity.

This is why I think pairing liquidity with our stablecoins which we’ll technically have a lot of is the key. No sell pressure on the token, while sell pressure on stablecoins is arbitraged and (hopefully) doesn’t move price. I’d also love to see a native centralized stablecoin issued on Onomy and paired in tandem with onomy’s stables to boost cross stable liquidity.

4 Likes
3

very well written. i look forward to seeing it play and and trading on the OneX!

1 Like
4

it looks very large-scale and you need to do a large amount of work. I hope everything will work out for you and we will be able to use Onex as written above in the post.Liquidity for cryptocurrencies have developed a good solution,but I wonder what method will be built for liquidity FOrex and RWA?maybe I didn’t fully understand something, thank you.

5

All clear but I have one question. where we are on derivative? we know it can bring over billion dollars in volume each day. is this something onomy will be adding in the near future? i think its key and fx is almost always a lot of leverage

1 Like
6

Skip API can also integrate the Arc Bridge Hub. If Arc provides the best routing for a particular asset, Skip API will take it.

can the bridge fees be paid in nom and can this be integrated across the board? imagine we do fee abstraction on eth for example.

1 Like
7

Thanks for writing up your thoughts. I agree with everything written, but I do have a few questions. Going to break up this response into multiple replies. From development standpoint ONEX development is complete and ONEX consumer chain is prepared for mainnet launch.

  1. What is timeline for Skip API integration? Upon review of Skip repos the only functionality that is developed is front end routing. It looks like they are at least a year out from being able to provide any of the claims.

  2. ONEX was built as a cross-chain aggregator (bridge hub) with a DEX similar to what Skip is proposing to build. Why would we support spending Onomy DAO resources to help develop and increase liquidity for a direct competitor? We could build a similar API utilizing IBC / Arc and ONEX hybrid DEX.

1 Like
8

Reply 2: IBC / Arc liquidity

It was mentioned that collaboration with other IBC chains and EVMs is an obvious route to increasing liquidity on ONEX. I agree with this.

  1. Which coins / tokens / chains are currently committed to deploy liquidity to ONEX? What are the amounts that are committed?

  2. Which coins / tokens / chains are currently being targeted to collaborate to deploy liquidity but have not yet committed?

1 Like
9

Reply 3: The write up comes across that ONEX consumer chain liquidity is completely reliant on Onomy Reserve stablecoins. Operational steps start at deployment of reserve for ONEX liquidity.

  1. How did other successful DEX launch without a stable coin system?

  2. Why is the playbook operational steps to hold off from deployment of ONEX waiting for Reserve? This effectively stalls the momentum that ONEX contests / testing provided.

  3. Why aren’t we moving forward with ONEX, building out the ONEX coin / NOM pair as initial liquidity as originally planned?

1 Like
10

always supporting the team

11

Charles, I have consolidated your questions into one reply so that we may have a fluid conversation as these are interrelated and require important context for historical reference.

1. What is timeline for Skip API integration? Upon review of Skip repos the only functionality that is developed is front end routing. It looks like they are at least a year out from being able to provide any of the claims.

2. ONEX was built as a cross-chain aggregator (bridge hub) with a DEX similar to what Skip is proposing to build. Why would we support spending Onomy DAO resources to help develop and increase liquidity for a direct competitor? We could build a similar API utilizing IBC / Arc and ONEX hybrid DEX.

Timeline for Skip API Integration: Assuming that it is a favorable option to continue exploring with any or all the 4 mentioned levels of integration the Skip team discussed with Onomy:

  • Skip API adding ONEX to the Skip DEX aggregation to swaps generated by integration partners’ users (eg Keplr, Leap, Metamask Cosmos Snap, Stargaze, Osmosis, etc…)
  • Skip API adding Arc Bridge support for all integration partners to leverage
  • Onomy leveraging Skip API to connect users with liquidity on other chains when a trade is not yet available on ONEX, and still earn fees for Onomy for doing so
  • Onomy leveraging Skip API as a way to help onboard users and tokens to ONEX

… then each one of these likely has a timeline of its own dependent on both our own and Skip’s timelines. I would be curious to get further input from the Skip team directly on the items listed as it is still in an exploratory stage between Skip and Onomy. However, I will immediately push back on your “direct competitor” comment, as Skip consists of a brilliant team building public goods infrastructure to accelerate the growth of Cosmos and all of IBC. Collaborative success is the best success and good faith relationships carry everyone involved to new heights. Let me dive deeper.

ONEX as an aggregator of its own via Arc: This point was specifically mentioned in my original post. Arc is a cornerstone of the original Onomy vision requiring more nuanced discussion. The exploratory idea of leveraging the Skip API is not intended to be a stopgap nor a replacement, but as a strategic expansion of ONEX’s capabilities and market presence from day one. The Arc Bridge Hub remains a major goal for aggregation.

Partnering with Skip presents a strategic opportunity to extend ONEX’s reach and utility before the full activation and proliferation of the Arc Bridge Hub on Mainnet. A potential partnership with Skip would be mutually beneficial, given Skip is already woven into a myriad of dApps, thus providing ONEX users with immediate access to a wider array of pairs and assets that would not yet be available on ONEX while the Arc Bridge Hub is being rolled out across numerous networks on mainnet. I vote in favor of capturing those ONEX users instead of allowing them to bounce out if ONEX doesn’t yet have their desired pair - and generating Onomy protocol revenue for doing so that could apply to NOM buy & burn.

It is simply a win-win. This approach not only accelerates ONEX market entry and adoption but also solidifies our long-term vision with Arc, ensuring Onomy’s prominence as a cross-chain hub. The end-user should never have to know which aggregator/bridge/network they are on, in the end. All of that should be abstracted away and we have the tech to do it. The ultimate goal is to serve the best experience to users from the start, not make them wait for Arc to carry the same features. Therefore, your question necessitates a logical counter-question of what Arc Bridge’s timeline is to launch across a variety of ecosystems on mainnet, validator coordination, and integration of other dApps as Skip currently has via its API. Although, I will reiterate that Arc and Skip are not mutually exclusive. By strategically leveraging Skip in the interim, we can then transition to a scenario where, following the successful integration of the Arc Bridge hub across a variety of chains on mainnet, Skip could favor routing through Arc and ONEX provided Onomy offers more optimal quotes. This is especially likely for Onomy’s native assets and Reserve stablecoins.

Reply 2: IBC / Arc liquidity

Keep in mind that ONEX is ready for launch awaiting BD to give go ahead.

It was mentioned that collaboration with other IBC chains and EVMs is an obvious route to increasing liquidity on ONEX. I agree with this.

1. Which coins / tokens / chains are currently committed to deploy liquidity to ONEX? What are the amounts that are committed?

2. Which coins / tokens / chains are currently being targeted to collaborate to deploy liquidity but have not yet committed?

IBC / Arc Liquidity

ONEX is gearing up to be the first validator coordinated consumer chain deployed on mainnet. However, the readiness is multifaceted, requiring preparation and deployment across more than just a “give ahead” by BD contributors. For instance, validator documentation has recently undergone an overhaul, ridding of outdated scripts and updating versioning to help streamline new validator onboarding in the new validator repo. You have voiced an effort to move that into the onomy repo, which I think makes sense. In the meantime, Decentrio’s contributions just got merged to supply a template for consumer chains and a guide for the validator setup to join ICS. Please voice if you feel anything else is needed to finalize the validator docs to merge into the onomy repo so that validators may prepare for ICS on mainnet. The ONEX contest itself was on devnet. Additionally, IBC paths to ONEX consumer chain must be established post-launch so that liquidity can move to and from. This is something Strangelove and Decentrio committed to supporting in their recent proposals (now accepted - welcome)!

Moving forward with this context, identifying partner chains / tokens / communities to deploy liquidity is a crucial next step as you highlighted. This can be through an array of means as I mentioned in my original post. What would be helpful for this is to clarify the procedural steps a partner chain would take. For example, Charles, do you favor DAO permissioned listings to be exposed on the front-end of the Venetian app provided by Pendulum? Or do you intend for fully permissionless listings with no vote? What about incentives - is there a programmatic module ready for liquidity incentive onboarding? These questions need good answers to quantify any amount of liquidity commitments from partner chains. While Onomy has great relationships with various IBC and EVM chains, we can take this so much further with concrete procedural steps. This can be easily done and I thank you for pushing toward quantifiable goals for the DAO to establish.

As in my original post, however, Forex and RWA is the ultimate UVP that Onomy was designed for since the beginning and ONEX is not intended to be a blanket competitor or just another DEX vying for attention. Done right and in collaborative spirits, however, Onomy can be a better DEX than others while also crushing the specialized FX & RWA game, too.

That said, target IBC chains that I will personally support include Noble, Osmosis, Injective, OKX Chain, Kava, among others. Target EVM chains require mainnet integrations of Arc to access ONEX, if not done through other means, and thus tangible conversations can be carried on for liquidity commitments once there is a clear route to deployment and not just theoretical. Theoretical conversations have already been done with many such chains signaling intent via co-announcements across a variety of EVMs.

I will do you one better than a simple “which chain” and “how much” because Onomy should not be beholden to any decisive central body to deploy liquidity. Dedicated Market Maker (DMM) programs are something of interest to many firms I have had discussions with such as Wintermute and AlphaLab Capital. In another thread, we should start considering a DMM program that led to substantial volumes for chains like Injective in years past and more recently for WOO X. Here’s an example of API documentation Woo provides that we could work to structure for ONEX. This will accelerate DMM programs with major market makers as the procedural steps, integration docs, and API is clearly and fully explained.

As a start to this on a larger community scale, rather than single firms, I have started conversations with strong contributors to Hummingbot, the largest open source market making bot and platform with thousands of community members. Establishing a Hummingbot connector to ONEX will unlock thousands of HBOT members to trade on ONEX, generating volumes, arb opportunities, a detailed DMM program and any other incentives the DAO can think of. Of particular excitement is to observe in-production APY as an LP to ONEX AMM as opposed to simple maker taker fees from traditional orderbook DEXs.

Reply 3: The write up comes across that ONEX consumer chain liquidity is completely reliant on Onomy Reserve stablecoins. Operational steps start at deployment of reserve for ONEX liquidity.

1. How did other successful DEX launch without a stable coin system?

2. Why is the playbook operational steps to hold off from deployment of ONEX waiting for Reserve? This effectively stalls the momentum that ONEX contests / testing provided.

3. Why aren’t we moving forward with ONEX, building out the ONEX coin / NOM pair as initial liquidity as originally planned?

This is more than just a cursory glance at historical precedents. ONEX’s strategy for success must account for current-day markets. That said, I would summarize key factors as first-mover advantages, liquidity incentives, effective partnerships with market makers, bridges and aggregators, substantial community base, and offering access to assets specific to the DEXs ecosystem that are not yet available on other exchanges - with a clear onboarding path.

The latter is most crucial at this stage, especially if the specific asset is trending, provides airdrops, or net-new use cases. Users must desire to access what they do not already have. This conversation should naturally lead to the design and development progression of the Reserve, yield bearing decentralized stablecoins, on-chain FX markets and impactful use cases in digital and physical realms. A void Terra left is still yet to be filled in the decentralized stablecoin arena. Meanwhile, there’s an oversaturation of general purpose DEXs and aggregators. The power to sustainably scale beyond what Terra once was and reshape the market’s view on decentralized stablecoins rests in Onomy’s hands.

Before I answer the question on simply launching with a ONEX/NOM pair, or reiterate my past commentary, do you anticipate that moving forward with a simple ONEX/NOM pair is sufficient for Onomy’s broader objectives? If so, can you demonstrate alternative operational steps for the DAO to consider?

For the record, I am open to voting yes on that approach but the Onomy DAO needs to vote responsibly to consider required time itself as a valuable resource. Onomy has long held a one-man-army attitude and while it can be effective, collaboration will accelerate our timeline and goals whilst further decentralizing and expanding the contributor set. This is what I have personally been pushing for with recent validators joining the set and Onomy is a conversation away from committed capital once the items I have highlighted are ready - it’s more than just BD go-ahead. It’s imperative that Onomy’s go-to-market strategy encompasses the full breadth of context required for success. I hope that we can collectively collaborate on optimal pathways to achieve the Internet Financial System we envision.

9 Likes
12

Yes, I suggest moving forward with launching the ONEX consumer chain bootstrapping initial liquidity with a ONEX / NOM pair. That allows Onomy to chart our own course and timeline.

Otherwise, my fear is that ONEX stays in limbo waiting with no target date of launching.

1 Like
13

Thanks for the posts and dialogue, (I wish I had more time this week but managed to scratch together a reply on the fly so excuse if it is a bit over the top but I am just putting my thoughts down) this DAO interaction is very interesting to me as it is an ongoing experiment in DAO mechanics at critical inflection points. The key problem that has been identified with DAOs is execution when compared to traditional start up organizational structures with strong leadership backed by vision but forced to pivot many times during product development. “Analysis paralysis” is something that can happen to under time sensitive pressure. Personally I can see both sides of the discussion clearly and both are calling for concrete steps and measurable time backed deliverables or a “SMART” framework which mixed with a little “KAIZEN” product building philosophy as ROME was not built in one day it was incrementally built over an arc of time, I believe we can have it ALL and love the ambitious vision but I am also realistic.

Maybe a path forward as a DAO is we need to agree on a base line for a “soft launch” and show a road map ( preferrably with time backed deliverables haha!) as the DAO builds up to the dream machine that fills the gap Terra left, liquidity begets liquidity.

As an example I have added the following: GTM strategy would focus on leveraging the unique strengths of the ONEX platform, its integration with Skip API, potential collaborations, liquidity strategies, and market differentiation.

1. Product Finalization and Technical Readiness

  • Skip API Integration: Fast-track the integration with Skip to leverage its DEX aggregation capabilities. This includes prioritizing the development of backend functionalities that enhance ONEX’s on-chain liquidity and cross-chain trading capabilities.
  • Arc and ONEX Hybrid DEX Development: Prioritize the development and any further testing of ONEXl to ensure a robust and user-friendly platform i.e. “create a CEX experience on chain” with the core features needed for a main net “soft launch”. Emphasize the additonal unique selling proposition (USP) of this hybrid model in offering both liquidity depth (via AMM) and price precision (via order book) with the core mantra of " ONEX-creating the CEX experience on chain".

2. Strategic Partnerships and Ecosystem Integration

  • Collaboration over Competition: Position ONEX as a complementary platform to Skip, focusing on mutual growth within the Cosmos ecosystem and beyond. Emphasize the collaborative nature of blockchain development and the benefits of shared liquidity and user bases. REMEMBER the best UI/UX applications will be sticky for users and it’s why for example DYDX has been able to shift L1s and grow.
  • Cross-Chain Aggregation Strategy: Highlight ONEX’s role as a cross-chain aggregator by securing partnerships with key blockchain networks and protocols. Focus on integrating with chains and protocols that add unique value and liquidity to ONEX.

3. Liquidity and Market Making

  • Initial Liquidity and Incentives: Secure commitments from partner chains and tokens for initial liquidity provisioning. Launch liquidity incentive programs to encourage participation from liquidity providers and market makers.
  • Dedicated Market Maker (DMM) Programs: Establish partnerships with leading market-making firms and leverage open-source platforms like Hummingbot to ensure deep liquidity from the outset. This will enhance the trading experience and price efficiency on the platform.

4. Marketing and Community Engagement

  • Brand Positioning and Awareness: Develop a strong brand identity for ONEX, focusing on its hybrid model, cross-chain capabilities, and user-centric design. Implement a comprehensive marketing campaign targeting both crypto enthusiasts and institutional traders.
  • Community Building and Engagement: Foster a vibrant community around ONEX through social media, forums, and direct engagement. Leverage community feedback for continuous improvement and feature development.

5. Regulatory Compliance and Security

  • Security Measures: Prioritize the security of the platform through rigorous testing, audits, and the implementation of best practices in smart contract development.
  • Regulatory Navigation: Stay abreast of regulatory changes in key markets and ensure compliance to facilitate smooth operations and foster trust among users.

6. Launch Strategy

  • Soft Launch with Select Partners: Initiate a soft launch phase with select partners to fine-tune the platform based on real user feedback. Use this phase to ensure that all technical and operational aspects are fully optimized.
  • Full Launch Campaign: Roll out a comprehensive launch campaign, highlighting ONEX’s unique features, partnerships, and liquidity options. This campaign should include targeted outreach to crypto media, influencers, and strategic advertising across multiple channels.

7. Post-Launch Growth and Expansion

  • Continuous Improvement and Feature Addition: Post-launch, continue to enhance the platform based on user feedback and technological advancements. Explore new features like advanced trading tools, additional liquidity options, and cross-chain functionalities.
  • Global Expansion: Gradually expand to new markets by ensuring compliance with local regulations, establishing partnerships with local entities, and tailoring marketing strategies to regional preferences.

8. Measurement and Optimization

  • KPIs and Analytics: Establish clear key performance indicators (KPIs) to measure success, including user growth, trading volume, liquidity depth, and community engagement. Use analytics to continuously optimize the platform and marketing strategies.

This go-to-market strategy aims to establish ONEX as a leading DEX in the rapidly evolving cryptocurrency market by leveraging its unique hybrid model, fostering strategic partnerships, ensuring deep liquidity, and building a strong community. The focus on technical excellence, user experience, and market differentiation will be key to capturing and sustaining market share in the competitive DeFi landscape.

—————————————————————————

Basic Example to organize the go-to-market (GTM) strategy for ONEX into measurable chunks, starting from a soft launch in week 0, we’ll break down the strategy into a detailed timeline. This phased approach allows for adjustments based on feedback and market conditions, ensuring a focused and adaptable rollout.

Week 0-4: Soft Launch Phase

Product Finalization and Technical Readiness

Launch Strategy

  • Week 0: Begin soft launch with select partners and early adopters to gather feedback. Monitor platform performance and user experience closely.
  • Week 1: Complete Skip API integration and finalize the hybrid AMM and order book model. Launch internal beta testing to ensure technical stability and user-friendly experience.

Strategic Partnerships and Ecosystem Integration

  • Week 2: Announce strategic partnerships with key blockchain networks and protocols. Start integration processes for cross-chain aggregation capabilities.

Liquidity and Market Making

  • Week 3: Secure initial liquidity commitments from partner chains and tokens. Begin discussions with market-making firms for DMM programs.

Marketing and Community Engagement

  • Week 4: Start a teaser marketing campaign highlighting ONEX’s USP and upcoming features. Engage with the community through social media and forums to build anticipation.

Week 5-8: Launch Preparation Phase

Regulatory Compliance and Security

  • Week 5: Complete security audits and ensure compliance with key market regulations. Publicize security measures and compliance status to build trust.

Marketing and Community Engagement (Continued)

  • Week 6: Ramp up marketing efforts based on soft launch feedback. Highlight unique features and partnerships, focusing on differentiators like UI/UX.

Liquidity and Market Making (Continued)

  • Week 7: Implement liquidity incentive programs and finalize partnerships with market-making firms. Announce DMM program details.

Week 8-12: Official Launch and Post-Launch Growth

Launch Strategy (Continued)

  • Week 9: Roll out full launch campaign, targeting a wider audience through crypto media, influencers, and strategic advertising.

Post-Launch Growth and Expansion

  • Week 10: Begin analyzing user feedback and market response. Start planning for new features and cross-chain functionalities based on feedback.

Regulatory Compliance and Security (Ongoing)

  • Week 11: Continue monitoring regulatory landscape and ensuring platform security. Address any new compliance requirements.

Measurement and Optimization

  • Week 12: Establish KPIs and implement analytics tools for continuous monitoring. Adjust strategies based on performance data and user feedback.

Ongoing: Weeks 13 and Beyond

  • Continuous Improvement: Regularly update the platform with new features and enhancements based on user feedback and technological advancements.
  • Global Expansion: Explore opportunities for market expansion, adapting strategies to comply with local regulations and meet regional user preferences.
  • Strategic Partnerships: Continuously seek new partnerships to enhance liquidity, expand the ecosystem, and offer new trading pairs and functionalities.
  • Community Engagement: Maintain active engagement with the community, offering transparent updates and incorporating feedback into development priorities.
  • Marketing and Brand Building: Keep the momentum with ongoing marketing efforts, highlighting new features, partnerships, and community success stories.

This phased approach ensures that ONEX is strategically positioned, technically robust, and market-ready, with a strong emphasis on user experience, security, and compliance. Each phase builds upon the previous, allowing for scalability and adaptability in the rapidly evolving DeFi landscape.

S-M-A-R-T
Specific

It’s important to have a clear end goal in place. It can be a good idea to constantly ensure that everybody who is working as part of the project is aware of the clearly defined end goal. This can help them achieve their end goal.

Measurable

If possible, use precise data points and locations in order to establish exactly what you want to happen. It’s also important to stick to a specific timeframe. These are important steps to ensure your data is measurable.

Attainable

As with any target that you set for yourself and the team, setting achievable SMART targets is key. This means that when setting your goals you may need to consider factors such as available labour, the resources you have available to you and the amount of time you have available. Doing this means that you can avoid falling into the belief that the project is unachievable, and you can keep morale high throughout.

Relevant

In the world of business, making sure that every positive step you take in a project is relevant can push you in the right direction. By ensuring that all of your projects have a relevant and tangible impact on the fortunes of the business, you can add value to the company. The alternative is setting goals with little to no business relevance, and taking the business in a meaningless direction with what are, ultimately, wasted resources.

Time-sensitive

Set a timeline for your goals, with individual deadlines for tasks and milestones, and your productivity is likely to increase. Doing so means you don’t have the flexibility to procrastinate through the majority of the project and can work at a steady and consistent rate throughout. Shorter deadline periods can reduce the risk of procrastination.

14

As to definitive Onomy path forward, development of ONEX front end 2.0 and chain was complete as of the last contest.

December 25th was the Onomy delegator snapshot date for ONEX coin distribution.

Next operational step IMO is to launch ONEX consumer chain. It is now February and there is no date so I am throwing out March 4th as a prospective ONEX consumer chain launch date.

Upon launch of ONEX the plan is to bootstrap initial pair ONEX / NOM as contributors will have plenty of both.

From there IBC relayers between ONEX and other cosmos chains are to be fired up. Lalo did a great job of lining up Decentrio and Strangelove to help create paths and run relayers. I will also be running relayers out of Pendulum.

Once an IBC path is established we will need cross community collaboration to build liquidity for each IBC bridged coin and NOM. While listing on ONEX is permissionless, it will require a DAO proposal to add the newly listed asset’s metadata that the front end UI reads.

1 Like
15

Agree and the ship has been steered and positioned well so far thru some incredibly stormy seas and at this stage of the market cycle it’s time to be decisive as the wind is at our backs finally although many still suffer from crypto winter PTSD ! imho growing networks are based on metcalfes law fundamentally (and if it is a blockchain network rising global liquidity also helps :slight_smile: ) so you need peers, partners and collaboration especially as the pie is growing, (say we go from 1 trillion to 10 T) at the end of the day if onex is ultimately a sticky application and finds its PMF it will win and keep the users : ) - carpe diem -

1 Like
16

Trying to gather some intel here some interesting insights from the co founder of skip

The other co-founder Sam Hart and Jack Zampolin seem to go back along way and have a history of collaboration and crossover side projects in cosmos eco system -

https://x.com/88danillo/status/1758055450874954205?s=46&t=B8Xi1i4mjU-3jAtisLexUw

A bit random but This was an interesting announcement a team member shared just now with me as well

https://x.com/jelenaaa____/status/1758215969116229965?s=46&t=B8Xi1i4mjU-3jAtisLexUw

Ann from skip and noble lol

17

In summary, with onex being its own consumer chain it should have its own road map going forward to drive its developement, as such, if you’re open to voting yes on a soft launch approach I would second that with a proposal to create a sub roadmap for the ONEX chain going forward.

So the proposed steps would be ;

  1. soft launch using NOM/ONEX pair to bootstrap (based on Charles steps and time line)
  2. with the soft launch release an ONEX road map for 2024 outlining the enhancments/ integrations to build out the IFS and with the core integrations being the trigger for 3.0 main net launch ( based on Lalo`s IFS vision)
18

I am following the developments with great excitement about this big step we have taken with super onomy onex. Don’t forget to support your nomads.

19

Thanks a lot for taking the time to write this long form post and it’s great to see the engagement with numerous replies, suggestions, ideas etc. At the very least this is a very decent exercise on proper community engagement.

Given I wasn’t very active on Onomy’s discord or other socials with the exception of providing some feedback during the multiple “ONEX wars”, I’ll just share a bit about my background, as I believe it might be a helpful context for understanding my perspective and feedback better.
I was a significant early investor in the project (circa Feb-21) and although I’ve invested in the last cycle in ~100-150 projects, Onomy is just one of a handful of tokens that I haven’t sold, but actually increased my holding of.
I am however not just an investor but a builder of projects (although I’m not very technical and don’t code myself) and some of the projects that our team had launched are BlinDEX (a 100% fairly launched decentralised multi currency and multi asset stables platform, on RSK chain that was eventually shut down, but more on this later on) and WombatDAO (a pure play DAO, which was also 100% fair launch and is still operational and is driven by its small, yet dedicated community). I mined my first bitcoin in 2013 (but lost all of them on Mtgox :slight_smile: ), so I’ve seen a thing or two in crypto land and will try to share my experience and suggest some things I would suggest to focus on based on it.

First of all, I’m a big fan of setting targets and deadlines. Someone much smarter than me once said that if you’re not setting your target, you’re all but guaranteed not to hit it… Be it March 5th as @charleston suggested or another date, but I’m 100% in favour of setting a date for the launch + a certain functionality and/or partnerships to be ready on the date of the launch.

Second - I’d like to focus on the stables as this is, in my view, the heart of the problem at hand (liquidity etc). Most of the LP’s are holding USDT/USDC as their main reserve token, so we either need to support them (this is why IBC to Kava, which in turn, is the main way in and out of the Cosmos ecosystem for “native” USDT, would be super important) and/or to provide a viable alternative with Onomy Reserve stables. Not sure how many others here had any experience launching a new stable coin/s, but this ain’t a walk in the park to say the least… I could fill many pages with our learnings from BlinDEX failure, so I’ll try to distill it to just a few of them here:

  1. Utilisation/usage - unless the stables are being used (for real and not just to farm some other tokens), it ain’t gonna work in the mid-long term.
  2. On/off-ramps - if users can take their fiat and easily turn it into stables and vice versa, this will greatly add to utility and trust in said stables.
  3. USD denominated stable is still the king (akin to USD itself) and no matter how much we hate it, it’s unavoidable to have it as the first (and perhaps even as the only) stable. It’s especially true about all these “exotic” currencies with triple digit inflation - no one wants to hold them, so no point in creating a digital version of a fiat shitcoin, as still no one would want to hold it.
    In BlinDEX we did also launch EUR, GBP and even Gold pegged stables (all of which we did following a community survey and a vote), but very few folks actually went ahead and minted them.
    All of the above doesn’t mean that we should flush Onomy’s “Forex on chain” vision down the drain, but for trading forex, it might be sufficient to have synthetic currencies, rather than fully pegged and collateralised stables.

Third - liquidity. Now in order to tackle this one seriously, first, we need to think who are the fx traders in the fiat world. In other words, who are our potential customers?
FX market is the most liquid market on the planet, but let’s have a look at the various segments of its users/traders:
Institutions, Corporates, Central Banks, Market Makers, Algo traders, Hedgers and Retail traders. The first 6 segments are highly unlikely to switch to on-chain trading (be it on ONEX or elsewhere), as they’re either heavily regulated, supervised, restricted to particular platforms, relying on proprietary/legacy platform or a combination of all the above. This basically only leaves us with the retail traders and these poor bastards are typically carrying the majority of the losses as they’re trading with high leverage and don’t have all the tools and information the big guys have, so their lifetime (as an FX trader) is very limited. In addition to that if we’d to cater to them - we’d be competing with all the traditional online forex companies/brokers and these guys are often paying CPAs (cost per acquisition) of hundreds of dollars.
So maybe forex traders aren’t our target market/audience at all? And if this is the case, what is our target audience? Are they the crypto native degens? Someone else?
Bottom line, prior to planning the liquidity provision for ONEX, we first need to figure out what assets would/should be traded there? Would it be just spot or also leverage/perps and if so - what’s our advantage over projects like Levana, who are focusing purely on perps and are already integrated with Osmosis?
Maybe we should start “simply” as an aggregator (e.g. 1inch, Jupiter etc) and become the leading aggregator on Cosmos, gradually augmenting the offering by our own liquidity?

I know, I probably asked more questions here than provided answers/suggestions, but given we’re having a lively community discussion, I though this could be useful.

7 Likes
20

Something is cooking .we are waiting