Developers post live apps, integrations, or demos.

Ecosystem Showcase & Launches


The idea started from a simple question: can an onchain app feel fast enough for short market rounds without forcing users to sign a wallet popup every few seconds?

For a normal dApp, waiting for confirmations can be acceptable. But when the product is built around 60 second rounds, that delay changes the entire experience. It starts to feel less like a real product and more like a slow demo.

So I wanted to test a different model: deposit once, receive internal credit, join short rounds, let the contracts enforce the rules, and let keeper bots handle execution in the background.

That became 3XTREMES.

Live app:




3XTREMES is a 60 second onchain prediction arena where users take Long or Short positions based on market direction inside short rounds.

The system uses extreme leverage style mechanics, internal credit accounting, keeper based execution, liquidation logic, and onchain settlement. 

It is not a perp exchange, and it is not a traditional trading platform.



It is a testnet experiment around speed, risk, UX, and automated execution on Arc. The main thing I wanted to explore is whether an onchain prediction game can feel fast without removing the important contract level rules underneath.




A lot of onchain apps still ask users to sign too often.

That works for slower actions, but it breaks the flow when the product is built around 60 second rounds. Every extra wallet popup makes the experience feel heavier than it should.

So I designed 3XTREMES around a faster session based flow. Users deposit testnet USDC once, receive internal USCC credit, and use that balance inside the app. After that, the keeper handles execution in the background while the contracts keep accounting, settlement, liquidation, and risk rules in place.



The goal is not to pretend this is fully trustless today.

 The goal is to test a practical architecture for fast onchain interaction and understand the tradeoffs clearly.




Each round runs for 60 seconds. During the active window, users can take Long or Short positions.
The final 5 seconds are locked. No new positions and no closes are accepted during that window.

This lock window is designed to reduce last second sniping and settlement timing abuse. If someone waits until the final movement and tries to enter right before settlement, the contract rejects the action during the lock window.

When the round ends, settlement happens through the onchain flow.



3XTREMES uses testnet USDC as the deposited asset and USCC as the internal credit balance.

When a user deposits USDC into the CreditVault contract, the contract holds that USDC and credits the user with USCC inside the system.



USCC is not a public token, not a tradable asset, and not meant to exist outside 3XTREMES.

 It is only an internal accounting unit used for margin, settlement, liquidation accounting, and withdrawals.

The flow is simple. A user deposits USDC, receives USCC, locks part of that USCC as margin when opening a position, and then the contract updates the balance after settlement or liquidation.

When the user withdraws, available USCC is reduced internally and the matching testnet USDC is sent back to their wallet.

Withdrawals are blocked while positions are open. This prevents users from removing balance that is still tied to active round risk.





The contract system is split into five parts.

FeeManager handles fees, platform revenue, liquidation penalties, and the insurance fund. CreditVault handles USDC deposits, internal USCC balances, withdrawals, and balance protection. VRFConsumer creates the round seed. RoundEngine manages the round lifecycle, lock window, price updates, settlement, and emergency cancel flow. PositionManager handles positions, PnL, liquidation, exposure checks, and round settlement.

I separated the system this way because I wanted the architecture to be easier to reason about. Custody and credit accounting should not be mixed too tightly with position logic. Round lifecycle should not be mixed too tightly with fees. Each part has its own job.




For the current testnet version, 3XTREMES uses a custom seed generation contract based on block randomness and round specific data.



This is not Chainlink VRF and not a true external VRF provider.



For testnet, this is enough to generate a deterministic candle path and test the product flow. For a more serious mainnet version, this part should be upgraded to a stronger external randomness provider such as Chainlink VRF or another verifiable randomness system.

I want to be clear about this because randomness is one of the most important assumptions in the design.




3XTREMES has four leverage style tiers: NORMAL at 10x, WILD at 100x, INSANE at 1,000x, and EXTREME at 10,000x.

At 10,000x, a 0.01 percent move against the position can wipe it out.

Liquidation is based on entry price and leverage. For Long positions, the danger is price moving down. For Short positions, the danger is price moving up.

The liquidator watches candle high and low in real time, not just the close price. That means wicks matter. If the wick touches the liquidation level, the liquidation flow can be triggered.




3XTREMES uses a hybrid execution model.

The main keeper manages the round lifecycle. It starts rounds, reads the seed, computes candles, streams updates to the frontend, pushes price updates, and settles the round.

The liquidator watches open positions and checks whether any position has reached its liquidation level. If a position is eligible, it checks the condition onchain and submits the liquidation transaction.

The bots are important for speed and UX, but they are not meant to replace contract rules. The contracts still enforce the important limits. The bots are there to execute actions around those rules.




Because the leverage mechanics are extreme, the system needs boundaries.

I added max positions per wallet, max position size, net exposure caps per user, global open interest imbalance caps, withdrawal guards, nonReentrant protection, round bound settlement, authorized keeper controls, emergency pause and cancel flows, and an insurance fund circuit breaker.



None of this makes the system perfect, but it keeps the experiment from becoming completely uncontrolled.

The leverage is extreme. The infrastructure should not be reckless.



3XTREMES needs fast round execution, frequent state updates, keeper based settlement, liquidation handling, and a frontend that does not feel slow.

Arc Testnet has been a good place to test that. If the chain feels heavy, a product like this breaks immediately. The whole experience depends on short cycles feeling smooth.

That is why Arc made sense for this experiment.




This is still an early testnet build.

The randomness is not Chainlink VRF. The keeper has an important role in execution. The candle path becomes deterministic once the seed is known. The insurance fund can be stressed if many winning outcomes happen at the same time. Some metrics, like volume tracking, still rely on server side persistence and need stronger infrastructure before anything more serious.



So I do not want to present 3XTREMES as fully trustless or production ready.

 It is a working experiment to test architecture, UX, risk design, and what fast onchain prediction apps could feel like.



I would really appreciate feedback from the Arc community.

The areas I care about most are the USCC accounting model, keeper and liquidator design, round structure, risk controls, UX clarity, and security assumptions.

If you have time to try it, I would love to hear what feels unclear, what could be improved, and what parts of the architecture need stronger thinking.

Thanks for taking a look. I am excited to keep improving 3XTREMES on Arc.

3XTREMES: A 60 Second Prediction Arena Built on Arc Testnet

Home

Forum

Events

Content

Courses

People

Contributors

Albums

Groups

Chat

Channels

Not being used

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

Profession

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via noreply@arc.network if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via noreply@arc.network for any questions.

Accounts are unapproved when profile information cannot be verified or when activity patterns indicate spam, inorganic participation, or behavior that undermines trust in the program.

To strengthen your profile for future consideration, sign in with a verified LinkedIn account, use real and current profile information, and participate constructively in other community spaces.

Commercial customers should raise concerns through their support channel.

https://www.arc.network/community-guidelines