← Back to posts
Engineering/5 min read/March 3, 2025

Launching the First Opyn Market on Arbitrum

The real challenges and excitement of launching Opyn's first perpetual market - from contract size limits to keeping pool prices stable.

OpynProduct LaunchSmart ContractsArbitrum

This was the first ever market on Opyn Markets. WETH/USDC market with 4 power perps: 0, 1/2, 1 and 2.

Seeing real people trading on a real market with test funds was definitely exciting. Our idea that we'd been working on for so long was finally coming to life, being used by real people. But there were a lot of challenges to make that work.

Contract Size Hell

The first major problem hit us early - our contracts kept growing bigger and bigger. We had to keep them under the 24,576 bytes (24KB) contract size limit that Ethereum enforces through EIP-170. This wasn't just about one contract, but multiple contracts that all needed to work together.

Every time we added a feature or optimization, we'd bump up against the limit again. It became this constant battle of refactoring, splitting functionality, and finding clever ways to pack more logic into less bytecode. The limit exists to prevent DoS attacks, but when you're building complex DeFi infrastructure, those 24,576 bytes disappear fast.

One thing that really helped was using the ERC-1167 minimal proxy pattern. I didn't know about this before, but it lets you deploy much cheaper proxy contracts that delegate calls to a master implementation. Instead of deploying full contract code every time, you deploy a tiny proxy that just points to the main logic. This was a game-changer for reducing deployment costs.

The whole process of reducing contract sizes and refactoring was a learning experience in itself. Dealing with "stack too deep" errors, figuring out how to restructure functions to use fewer local variables, breaking up complex logic into smaller pieces - I learned tons and tons about Solidity optimization that you just don't encounter in smaller projects. Every optimization technique became necessary, not just nice-to-have.

Block Gas Limit Nightmare

Then came the block gas limit problems. We had to deploy a lot of contracts and wanted to do it all in one go:

  1. Deploy Factory
  2. Deploy market
  3. Seed market with initial liquidity

The plan was that anyone could come and click a button, supply either token from the pair (BTC or WETH for a BTC/WETH market), and our contract would handle deploying the market and seeding it with initial liquidity. It would split the supplied tokens based on what was needed.

All of this had to happen in the same block, which created serious gas limit issues. Ethereum's block gas limit was 36 million when we launched in February 2025, and Arbitrum has an effective execution limit of 32 million gas despite showing much higher numbers. We spent way too much time fighting to get everything under these limits.

Testnet Deployment Costs

Deploying on testnet was surprisingly expensive and complex. We had to:

  • Find existing Uniswap v3 pool addresses for our pairs
  • Deploy our own versions of ERC-20 tokens because we needed minting control
  • Deploy new pools based on those tokens

The whole infrastructure setup was more involved than we initially expected.

Keeping Pool Prices Stable

This was probably the biggest ongoing challenge. We had to keep the pool prices in check, otherwise they'd just sway in one direction or the other, making it hard for people to trade since that directly affects the perp prices.

Solution: arbitrage bots. Whenever the price swayed away from the index, we needed to pull it back by making trades. This required:

  • Monitoring price deviations constantly
  • Having bots ready to trade when needed
  • Ensuring enough liquidity so prices didn't move dramatically on small trades

Liquidity Management

Adding enough liquidity to the pools was crucial so that prices wouldn't move much whenever someone traded. This was a balancing act - too little liquidity and every trade would cause massive price swings, too much and we'd tie up unnecessary capital.

We had to constantly monitor and adjust liquidity levels based on trading activity and price stability requirements.

The Excitement Factor

Despite all these technical challenges, watching real users interact with our market was incredible. Each trade felt like validation that the concept worked. People were actually using our power perpetuals, trying different strategies, and the market was functioning.

It's one thing to have something work in your local environment or testnet, but seeing it handle real user behavior in production is completely different. Every edge case we hadn't thought of, every user flow we hadn't optimized - it all became immediately obvious.

What I'd Do Differently

Looking back, a few things I'd approach differently:

Contract architecture: Start with gas optimization and size limits in mind from day one, not as an afterthought.

Deployment strategy: Have a more robust script for the sequential deployment process, with better error handling and rollback capabilities.

Liquidity planning: Model liquidity requirements more thoroughly before launch to avoid the constant adjustments.

Bot infrastructure: Build the arbitrage bots earlier in the process rather than scrambling to get them working around launch.

The Real Learning

The biggest takeaway wasn't technical - it was seeing how real users behave differently than you expect. Our assumptions about trading patterns, liquidity needs, and user flows were only partially correct.

Building in production with real users is fundamentally different from any amount of testing. The market taught us things about our own product that we couldn't have learned any other way.


This was our first market launch, and definitely not our last. Each subsequent market benefited from these hard-learned lessons.