Jump to content

⤴️-Paid Ad- TGF approve this banner. Add your banner here.🔥

Recommended Posts

Posted

SuperEx Educational Series: Understanding Liquidity Network Model

 

 

#SuperEx #EducationalSeries

Cross-chain liquidity often works less like “moving a box” and more like withdrawing money in another city.

If you deposit 100 yuan in New York and withdraw 100 yuan in Washington, the exact banknote does not travel with you. The system verifies your balance, gives you local cash, and settles everything in the background.

The Liquidity Network Model works in a similar way. When users want to move value from Chain A to Chain B, the asset does not always need to literally travel across chains first. If liquidity already exists on Chain B, the user can receive funds quickly, while the protocol, market makers, solvers, or liquidity providers settle the backend later.

In plain English: the money did not teleport. Someone already had liquidity at the destination.

1*1nS_wh7U3BeLzZpEJgKyKg.png

What Is Liquidity Network Model?

The Liquidity Network Model is a system that uses liquidity pools, market makers, solvers, relayers, or liquidity providers distributed across multiple chains to complete cross-chain transfers, swaps, and asset routing.

Its focus is not necessarily “physically moving the same asset from Chain A to Chain B.” It is about finding available liquidity on Chain B so the user can receive the result first.

For example, a user wants to move USDC from Ethereum to Base. A traditional bridge may lock funds, mint assets, and wait for confirmations. A liquidity network may instead work like this: the user pays on Ethereum, a liquidity provider sends USDC to the user on Base, and the backend later handles settlement, rebalancing, or reimbursement.

In one sentence: the Liquidity Network Model uses “inventory in many places” to reduce cross-chain waiting.


How Does It Work?

A simple way to understand it is a multi-chain convenience store network.

  • The user places an order on Chain A: “I want to receive 100 USDC on Chain B.”
  • The system checks: who has 100 USDC on Chain B? Who offers the best price? Who is fastest? Who has acceptable risk?
  • Then a solver or liquidity provider says, “I can do it.”
  • They send 100 USDC to the user on Chain B first.
  • Later, they recover funds and fees through Chain A or the protocol’s settlement system.

Several roles are involved:

  • The user submits the cross-chain request.
  • Liquidity providers prepare assets on different chains.
  • Solvers or routers find the best path and quote.
  • Protocol contracts record orders, verification, and settlement.
  • Messaging verification layers confirm source-chain events.
  • Rebalancing mechanisms move liquidity back into healthy distribution.

So this is not just “sending a transfer.” It is a capital coordination system. The front end feels smooth, while the backend is doing all the accounting. The whole vibe is: user stays calm, system handles the mess.


Why It Matters

One of the biggest problems in a multi-chain world is liquidity fragmentation.

The same asset may be spread across Ethereum, Arbitrum, Base, Optimism, Solana, BNB Chain, and other networks. Every chain has some liquidity, but no single chain always has enough where users need it. The money exists, just not here.

That is painful.

The value of the Liquidity Network Model is that it organizes fragmented liquidity so users do not manually search for bridges, pools, gas, and the cheapest route. The system routes assets for them. Users only need to express the outcome: where funds start, where funds arrive, and what fee or slippage they accept.

This is why intent-based cross-chain experiences are becoming important. Users do not want to study routes. They want to say, “Give me this result.” How it happens should be handled by the system.


Technical Approaches

The first approach is the liquidity pool model.

A protocol deploys pools across multiple chains. Users deposit on one chain and withdraw from a pool on another. It is easy to understand, but pools need enough depth. Otherwise, large transactions face painful slippage.

The second approach is the solver model.

Users submit a cross-chain intent, and solvers compete to fulfill it. Whoever offers better pricing, faster execution, and lower fees wins the order. This creates a great user experience, but depends on solver liquidity and risk management.

The third approach is routing aggregation.

The system checks multiple bridges, DEXs, liquidity networks, and messaging protocols, then splits orders, combines routes, and optimizes cost. It is like cross-chain navigation: many routes exist, but the user sees the final plan.

The fourth approach is unified liquidity.

Some protocols try to abstract multi-chain liquidity into one unified pool or settlement layer, making users feel like they are using one market. Nice idea, hard execution. Security, finality, pricing, and rebalancing all need serious design.

The fifth approach is rebalancing.

A liquidity network is not a perpetual motion machine. If Chain B keeps paying out and Chain A keeps receiving deposits, balances drift. The system needs arbitrage, incentives, fee adjustments, or professional market makers to rebalance liquidity.


Difference from Bridges

  • A traditional bridge often feels like “asset proof plus minting or release.”
  • The Liquidity Network Model feels more like “local inventory plus backend settlement.”
  • A bridge asks: was the asset locked on Chain A? Can it be minted or released on Chain B?
  • A liquidity network asks: is there inventory on Chain B? Who will front it? What is the price? How do we settle later?

Of course, they are not mutually exclusive. Many systems combine bridges, messaging verification, liquidity networks, solvers, and settlement layers. Real systems are messy. Protocol design is not a textbook exercise.

A Simple Case

Now, it’s time for everyone’s favorite — Alice is back!

Suppose Alice wants to move 1,000 USDC from Ethereum to Base.

With a traditional flow, she may need to choose a bridge, confirm the destination chain, wait for confirmations, and prepare gas on Base. If anything gets stuck, she starts questioning reality: I just wanted to move money, why does this feel like a multi-step quest?

With a liquidity network, Alice submits the intent: use USDC on Ethereum and receive USDC on Base. The system finds a solver. The solver has USDC on Base and sends 1,000 USDC to Alice first. Alice receives funds quickly. Later, the solver recovers Alice’s payment and fee from Ethereum.

Alice sees: fast arrival.

The system does: quoting, matching, fronting liquidity, verification, settlement, and rebalancing.

That is the appeal of the Liquidity Network Model: users do not need to understand the kitchen, as long as the dish arrives correctly.


Common Misunderstandings

First misunderstanding: a liquidity network is just a bridge.

Not exactly. A bridge focuses on cross-chain proof and asset issuance or release. A liquidity network focuses on destination liquidity and settlement. Some systems use both, but they are not the same thing.

Second misunderstanding: fast arrival means safer.

Not necessarily. It may be fast because someone fronted liquidity on the destination chain. User experience is fast, but backend settlement risk may still exist.

Third misunderstanding: more liquidity makes the system unbeatable.

No. More liquidity helps, but distribution matters. Who provides it? Where is it located? How are fees priced? Will liquidity disappear under stress? Is it concentrated? More money does not automatically mean better design.

Fourth misunderstanding: solvers are doing charity.

Nope. Solvers front capital, take risk, and handle rebalancing because they earn fees, spreads, or incentives. Without proper returns, nobody funds your smooth UX. In the adult world, the spreadsheet always shows up.


Risks and Limitations

First, there is liquidity exhaustion risk. Popular routes may work smoothly, while unpopular routes may have no takers. Under market stress, solvers may become conservative. Then users realize: the system is not refusing service; the destination is out of inventory.

Second, there is concentration risk. If a few market makers or solvers control most liquidity, the experience may be good, but dependency increases. If they go offline, withdraw liquidity, or get attacked, the impact is obvious.

Third, pricing and slippage matter. Cross-chain cost is not only the visible fee. It includes exchange rate, route, waiting time, and final received amount. Some users only look at the fee and then quietly discover they received less.

Fourth, settlement and finality risk matters. A solver may pay the user first, but later recovery depends on source-chain finality, message verification, contract security, and settlement rules.

Finally, rebalancing costs exist. Liquidity distribution will not stay perfect forever. The system must constantly rebalance inventory, and that cost eventually appears in fees, pricing, or waiting time.

 

Conclusion

The core value of the Liquidity Network Model is turning “assets cannot easily get here” into “someone here can fulfill the order first.”

It does not remove cross-chain risk, and it does not make assets teleport. It uses liquidity providers, solvers, routers, pools, and settlement mechanisms to make the experience feel closer to ordinary finance: withdraw value where you need it.

If Web3 truly becomes multi-chain, users cannot spend every day studying which chain has deeper liquidity, which bridge is cheaper, and which pool has lower slippage. The mature direction is intent-based: I want to go from here to there, receive this asset, keep fees reasonable, and do not make me wait forever.

The Liquidity Network Model turns this from “users manually finding routes” into “the system finding liquidity, routes, and execution providers.”
In plain words: stop making users become cross-chain dispatchers. They are tired.

1*7X8uHBH_gI7z3NfkogmMzA.jpeg

 

Posted

SuperEx Guide:Futures Trading-Advanced Trading Journey(II)

 

Small-Cap Tokens Are No Longer Just Holdings — SuperEx All-Token Perpetuals Unlock Greater Asset Utility

In the first article, we introduced the overall concept of All-Token Perpetuals. In today's second installment, we'll take a closer look and dive deeper into how it works.

Small-cap tokens have long faced a practical limitation: you can hold them, but you can't easily use them to participate in mainstream market opportunities.

If users wanted to trade BTC or ETH perpetual contracts, they typically had to sell their small-cap tokens for USDT first before entering the futures market.

While this process may seem straightforward, it often introduces several hidden costs:

  • Trading fees and slippage during token conversion.
  • Frequent portfolio rebalancing that disrupts long-term investment strategies.
  • Missed opportunities when markets move quickly during the conversion process.
  • Small-cap holdings remaining passive assets with limited utility.

To solve this challenge, SuperEx introduces All-Token Perpetuals.

With All-Token Perpetuals, users can use their existing small-cap tokens directly as both margin and settlement assets while trading perpetual contracts linked to the index prices of major cryptocurrencies such as BTC and ETH.

This means small-cap tokens are no longer static assets sitting in your spot wallet—they become productive trading assets capable of participating in broader market opportunities.

Compared with traditional futures trading, SuperEx All-Token Perpetuals offer several practical advantages:

  • No need to convert small-cap tokens into USDT first.
  • Use small-cap tokens directly as futures margin.
  • Profits and losses are settled in the original token.
  • Trade contracts tracking mainstream market indices.
  • Balance long-term investing with short-term trading opportunities.

What has truly changed isn't simply which token you use for trading—it's the entire trading workflow.

In the past, users had to adapt to the platform's settlement model.

Now, SuperEx has redesigned its product around the way users actually hold their assets.

For long-term holders of small-cap tokens, this is particularly meaningful because it removes the need to choose between keeping your investment and participating in major market trends.

Futures-Trading-Advanced-Trading-Journey

The Core Value of All-Token Perpetuals

SuperEx All-Token Perpetuals deliver several key benefits:

  • Lower Trading Barriers: Participate in BTC and ETH perpetual markets without first converting your assets.
  • Greater Capital Efficiency: Put dormant small-cap holdings to work instead of leaving them idle in spot accounts.
  • Reduced Trading Friction: Eliminate unnecessary conversions, transfers, waiting times, and additional decision-making.
  • More Flexible Trading Strategies: Create new opportunities for long-term holders, professional traders, and quantitative strategies.
  • An Improved Trading Experience: Index-based pricing keeps trading focused on broader market trends rather than the volatility of individual collateral tokens.

Perhaps most importantly, you're not trading the price movement of the small-cap token itself.

Instead, you're trading the market performance of major assets like BTC and ETH through index-based perpetual contracts.

Your small-cap token simply serves as:

  • The collateral.
  • The settlement asset.

Meanwhile, the trading direction remains tied to the broader crypto market.

This creates a much clearer trading framework:

  • Small-cap tokens serve as your capital.
  • Mainstream crypto indices become the trading instrument.
  • Profits and losses are settled back into your original token.
  • Your portfolio remains intact without constant reallocation.

For everyday users, this provides a far more flexible way to participate in the market.

For long-term holders, it significantly improves asset efficiency.

For professional traders, it introduces new opportunities for hedging, arbitrage, and capital management.

Completing the SuperEx Futures Ecosystem

All-Token Perpetuals also strengthen the overall SuperEx derivatives product lineup:

  • USDT-Margined Perpetuals — Ideal for standardized trading and capital management.
  • Coin-Margined Perpetuals — Best suited for long-term holders of major cryptocurrencies.
  • All-Token Perpetuals — Connect small-cap token holdings with mainstream market opportunities.

Rather than building its derivatives ecosystem around a single settlement asset, SuperEx is expanding its product suite to better reflect how users actually manage diversified crypto portfolios.

Final Thoughts

As the crypto industry continues to evolve, users need more than additional trading pairs or higher leverage.

They need trading products that are more flexible, more capital-efficient, and better aligned with the way they actually hold assets.

The launch of SuperEx All-Token Perpetuals represents exactly that kind of user-centric innovation.

When small-cap tokens become more than assets waiting for the next bull run—and instead become tools for participating directly in major market movements—their utility, liquidity, and strategic value increase dramatically.

SuperEx All-Token Perpetuals put your small-cap assets to work.

%E5%BA%95%E5%9B%BE.webp

Posted

SuperEx Educational Series: Understanding Hub Routing Mechanism

 

#SuperEx #EducationalSeries

You move from Ethereum to Base, from Base to Arbitrum, from Arbitrum to Optimism, then to BNB Chain. Every chain has its own rules, gas model, confirmation time, and message format. The user only wants to transfer assets, send a message, or call a contract, but suddenly it feels like solving a transfer-map puzzle.

Hub Routing Mechanism asks a simple question: do all chains really need direct connections to every other chain? Or can they connect through a hub that handles routing, verification, forwarding, and settlement?

In plain English: stop making users become the traffic controller of the multi-chain world. They are tired.

Press enter or click to view image in full size
 

1*D-mSyBJbJd6AS56Ks8yZRg.png

What Is Hub Routing Mechanism?

Hub Routing Mechanism is a cross-chain architecture where chains do not necessarily connect directly to every other chain. Instead, they route messages, assets, state updates, or actions through one or more hubs.

Here, the hub does not have to be a centralized server. It can be a relay chain, a validator network, routing contracts, a messaging protocol, a liquidity hub, or even a network of multiple hubs.

It solves a very practical problem: the more chains there are, the more direct connections explode.

If there are 5 chains, direct connections may still be manageable. But with 50 or 500 chains, things get wild. Every new chain must integrate with many existing ones. Developers and infrastructure teams enter boss-fight mode.

In one sentence: Hub Routing Mechanism uses centralized or semi-centralized routing coordination to reduce multi-chain complexity.

 

How Does It Work?

Think of Hub Routing like an airport transfer.

Not every small city needs direct flights to every city in the world. Often, a smaller city connects to a major airport hub, and passengers transfer there. It adds one stop, but the route network becomes easier to manage and much more scalable.

Cross-chain routing works similarly.

A user or contract on the source chain sends a message, such as: “Alice locked assets on Chain A, please update her state on Chain B.”

The message first enters the hub. The hub checks source, finality, signatures, nonce, fees, destination chain, and execution rules.

If everything is valid, the hub forwards the message to the destination chain. The receiving contract on the destination chain verifies that it came from the trusted hub, then executes the action.

So the hub is not simply forwarding things. It usually handles several jobs:

  • Routing: deciding where the message should go.
  • Verification: confirming that the source-chain event is real.
  • Queueing: managing order and replay protection.
  • Billing: estimating and collecting cross-chain fees.
  • Adaptation: translating formats between different chains.
  • Monitoring: tracking stuck, failed, or retried messages.

The vibe is: chains, stop yelling across the room, come through the counter first.

 

Why It Matters

Hub Routing matters because multi-chain connectivity cannot rely forever on manually built direct links.

Peer-to-peer connections sound clean: Chain A connects directly to Chain B, Chain B connects directly to Chain C. But as the number of chains grows, the number of connections grows fast. Every chain needs to understand other chains’ consensus, finality, message formats, fee models, and security assumptions. That workload is not cute.

Hub Routing concentrates complexity into a more manageable routing layer. Developers integrate with the hub and gain access to more chains. Users submit one action, and the system handles the route underneath.

This is important for cross-chain messaging, assets, accounts, governance, and RWA compliance-state synchronization.

 

Simply put, Hub Routing is the transit hub of the multi-chain world. Without it, everyone takes random side roads, and the result is traffic, confusion, or both.

 

Technical Approaches

The first approach is the hub-chain model.

Some systems use a dedicated relay or hub chain to process cross-chain messages. Other chains connect as spokes, while the hub verifies, orders, records, and forwards messages. Networks such as Axelar help illustrate this model: external chains connect through gateways, messages enter the network, validators process them, and then they are routed to destination chains.

The second approach is the router-contract model.

A cross-chain protocol deploys routers or endpoints on each chain. Users and apps interact with the local router, and the protocol routes messages to the destination chain. LayerZero Endpoints and CCIP Routers are useful examples of this “local entry point plus cross-chain routing” design.

The third approach is the liquidity-hub model.

If the system routes assets, not just messages, the hub may also coordinate liquidity. It checks where funds exist, which route is cheaper, and which solver can fill the order. Users see “funds arrived,” while the backend is finding liquidity, route, and execution.

The fourth approach is the multi-hub model.

One hub is convenient, but it can become a bottleneck. A more mature architecture may use multiple hubs, each serving different ecosystems, security models, or use cases. In plain English: do not force everyone into one subway station. It will get crowded.

The fifth approach is policy-based routing.

Future cross-chain routing will not only ask “can this message arrive?” It will consider security level, cost, latency, finality, compliance needs, and app preferences. A financial app may prefer slower but stronger verification; a game may prioritize speed.

 

Difference from Direct Connections

  • Direct connection is like building a highway between every pair of cities.
  • Hub Routing is like connecting cities to a major hub and letting the hub distribute traffic.
  • Direct connections have a clear benefit: the path is direct, with fewer middle layers. The downside is that the number of connections becomes hard to maintain.
  • Hub Routing makes scaling easier, integration more uniform, and developer experience simpler. The downside is that the hub may become a bottleneck, risk concentration point, or fee center.

So one does not automatically destroy the other. Different scenarios need different architectures. Do not just say “give me everything.” Adult engineering is tradeoffs.

A Simple Case

Suppose SuperEx wants to build a multi-chain membership benefit system.

Alice stakes a membership NFT on Ethereum, but wants fee discounts on Base, Arbitrum, and BNB Chain. If every destination chain must directly read Ethereum state and build its own verification logic, the dev team may start silently staring at the wall.

With Hub Routing, the flow becomes cleaner:

  • The membership contract on Ethereum emits a state update.
  • The message enters the hub.
  • The hub verifies that the update is real, finalized, and from the official contract.
  • The hub routes the message to Base, Arbitrum, and BNB Chain according to configuration.
  • SuperEx contracts on the destination chains receive the trusted message and update Alice’s membership status.

The user feels: “Wherever I use SuperEx, my benefits are recognized.”

Behind the scenes: source-chain state, hub verification, cross-chain routing, destination execution, retry handling, and fee settlement.

The user does not need to know all that. The user simply thinks: finally, this feels like a normal product.

 

Common Misunderstandings

First misunderstanding: Hub Routing means centralization.

Not necessarily. A hub can be a centralized service, but it can also be a decentralized validator network, an on-chain contract system, a light-client architecture, or a multi-hub network. The key is the trust model, not the word “hub.”

Second misunderstanding: the bigger the hub, the safer it is.

Not always. A large hub may have more liquidity, more connections, and better operations, but it can also become a bigger attack target. The more important the infrastructure, the more attention it attracts.

Third misunderstanding: Hub Routing is always slower than direct routing.

Not necessarily. It adds a routing layer, but if the hub has better routing, liquidity, and execution services, the overall experience may be faster. A transfer flight is not always worse than a delayed direct flight.

Fourth misunderstanding: once you connect to a hub, everything is solved.

Not so fast. A hub reduces complexity, but does not remove risk. Developers still need permissions, limits, replay protection, failure handling, fee management, and emergency controls.

 

Risks and Limitations

Hub Routing is not magic. It is useful, but it has traps.

First, risk concentration.If many chains depend on the same hub, a hub failure can have a large impact. At best, messages are delayed. At worst, assets, state, and permissions are affected. One broken transit hub can jam the whole city.

Second, trust model.How does the hub verify messages? Validator voting? Light clients? Multisig? ZK proofs? Oracle networks? Each model is different. Do not just read “secure” on a landing page. Ask how it is secure.

Third, routing bottlenecks.If a hub handles too many chains, messages, and assets, congestion, higher fees, and execution delays can appear. Cross-chain systems can have rush hour too.

Fourth, configuration complexity.Hub Routing may simplify integration, but security configuration still matters. Destination chains, sender contracts, payload formats, nonce, gas limits, execution permissions, and retry policies all need care. Misconfigure one thing, and the system may do very creative nonsense.

Finally, composability and lock-in risk.Once an app deeply depends on one hub, migration can become expensive. If it later wants another routing protocol, verification model, or multi-hub setup, it needs abstraction from the beginning. Do not finish the house and then discover the door opens the wrong way.

 

Conclusion

The core value of Hub Routing Mechanism is turning multi-chain connectivity from “every chain talks directly to every other chain” into “chains coordinate through routing hubs.”

It does not make cross-chain systems mysterious. It makes them manageable. The more chains, messages, and fragmented assets there are, the more we need routing layers to handle connectivity, verification, fees, ordering, and execution.

But Hub Routing is not a cure-all. It reduces connection complexity, but may introduce risk concentration, trust-model issues, congestion, and configuration mistakes. A mature design does not blindly worship one hub. It asks: what does the hub do, who verifies it, what happens if it fails, can routes change, and can multiple hubs work together?

The future multi-chain experience should feel like a transit network: users choose the destination, while the system handles routes, transfers, fees, verification, and exceptions in the background.

In plain words, users do not want to study how every chain connects to every other chain. They want to click once and get the thing done. Stop making users become routers. Let users live. Let developers sleep.

About SuperEx

As the world’s first Web3-powered cryptocurrency exchange, SuperEx has remained committed to building the Web3 ecosystem. Over the years, it has introduced a comprehensive range of products and services, including SuperEx DAO, SuperEx Web3 Wallet, Super Start, SuperEx P2P, SuperEx Stock Markets, SuperEx Copy Trading, SuperEx Earn, and SuperEx DAO Academy, creating a full-spectrum ecosystem that spans every major sector of Web3.

Today, SuperEx serves over 10 million users, with a social media community of more than 600,000 followers across 166 countries and regions worldwide. The platform supports 1,000+ cryptocurrencies for both spot and futures trading. Seamlessly integrated with Super Wallet, SuperEx provides decentralized asset custody while combining the trading efficiency of a centralized exchange (CEX) with the security of a decentralized exchange (DEX).

 

 

1*7X8uHBH_gI7z3NfkogmMzA.jpeg

Posted

SuperEx Guide:Futures Trading-Advanced Trading Journey(VIII)

 

#SuperEx #Guide #CopyTrading

How to Become a Lead Trader in SuperEx Futures?

You can now use copy trading on the SuperEx Futures Trading Platform. Follow the steps below to become a lead trader and allow other users to copy your trades.

  1. Log in to your SuperEx account and click [Trade] — [Futures Copy Trading].
  2. Click [Apply Now] to become a lead trader.
 

1*nFuIM2L1cZicgYyjKuQXqg.png

 

1*e9xnxTda0SXHhJrtciLVpw.png

After your application is approved, go to your copy trading account and click Create Project.
Note:

  • After creating a project, funds will be transferred from your spot account to your lead trader account.
  • When the lead trading ends, funds will automatically be transferred back to your spot account.
  • During the trading period, you can manually transfer funds in and out of your lead trader account.
 

1*NVliKlcVnZDzODssaLYgPA.png

 

1*kDeUb-2X9EMCVYFWG1Gs4w.png

Once the project is successfully created, click [Trade] to enter the futures trading interface.

 

1*R_LZ2cI68i3XEzt5rhldNQ.png

 

1*CejsA2NC8j9depK1PyzE6Q.png

Lead Trading Project Management

  1. Click [My Lead Trades] to view the details of your lead trading projects and perform other actions.
  • [Adjust Margin]
    Add or withdraw funds (you must maintain at least 100 USDT in your lead trader account before the project is closed).
  • [Close]
    If there are open positions, the project cannot be closed. All followers will automatically stop copying, and profit sharing will be settled.
 

1*mkfmcuBvHgonxKrXnNrR0g.png

 

1*CCqb5JRoAFTEbvpqo4b8Ow.png

You can also go to [Wallet] — [Copy Trading Account] — [My Lead Trades] to view project details.

About SuperEx

As the world’s first Web3-powered cryptocurrency exchange, SuperEx has remained committed to building the Web3 ecosystem. Over the years, it has introduced a comprehensive range of products and services, including SuperEx DAO, SuperEx Web3 Wallet, Super Start, SuperEx P2P, SuperEx Stock Markets, SuperEx Copy Trading, SuperEx Earn, and SuperEx DAO Academy, creating a full-spectrum ecosystem that spans every major sector of Web3.

 

Today, SuperEx serves over 10 million users, with a social media community of more than 600,000 followers across 166 countries and regions worldwide. The platform supports 1,000+ cryptocurrencies for both spot and futures trading. Seamlessly integrated with Super Wallet, SuperEx provides decentralized asset custody while combining the trading efficiency of a centralized exchange (CEX) with the security of a decentralized exchange (DEX).

 

 

1*7X8uHBH_gI7z3NfkogmMzA.jpeg

Posted

SuperEx Educational Series: Understanding Intent-based Cross-chain

#SuperEx #EducationalSeries #Guide

Before, cross-chain felt like driving a long-distance route by yourself: you had to check the route, gas cost, tolls, traffic, and hope you did not take the wrong exit.

But users do not want all that drama. They do not want to study bridges, DEXs, gas, slippage, destination liquidity, and message verification. They just want to say: I have USDC on Chain A, I want ETH on Chain B, make it reasonable, fast, and safe.

Intent-based Cross-chain is about this shift: users no longer specify every step. They express the outcome they want. Solvers, routers, liquidity networks, and settlement systems figure out how to make it happen.

In plain English: stop making users become cross-chain project managers. They just want the funds to arrive.

1*vnIVuwdWLsFT7LQTa3xkjQ.png

What Is Intent-based Cross-chain?

Intent-based Cross-chain is a cross-chain interaction model where users sign an order or intent that expresses the desired outcome, instead of manually executing every step.

Traditional cross-chain is more like command-based execution:

  • bridge first;
  • wait for confirmation;
  • swap tokens;
  • prepare gas;
  • call the destination contract.

Intent-based Cross-chain is more outcome-based:

  • I am willing to spend these assets;
  • I want to receive these assets or complete this action on the destination chain;
  • the minimum received amount must be at least this much;
  • the deadline is this;
  • whoever can satisfy these conditions can execute it.

In one sentence: Intent-based Cross-chain means users do not find the route themselves. They publish the request, and specialized executors fill it.

 

How Does It Work?

Think of an intent as an order ticket.

The user writes: “I have 1,000 USDC on Ethereum. I want to receive at least 995 USDC on Base within 10 minutes.”Solvers or fillers then evaluate it: can I fill this? Do I have liquidity on Base? What fee do I need? Is source-chain settlement risky? Is this order profitable?

If a solver accepts the order, it may first send funds to the user on Base, then settle through the protocol and recover the user’s payment plus fees from Ethereum.

It sounds like “someone fronts the money,” and yes, that is basically it. Solvers use their own capital, routing ability, and risk management in exchange for fees or spreads.

ERC-7683 is an important standardization effort in this direction. It aims to provide a more unified order and solver-facing interface for cross-chain intents, making it easier for different intent systems, solver networks, and order dissemination services to interoperate.

In plain words: stop inventing a new menu format every time. At least standardize the menu, or the kitchen will suffer.

 

Why It Matters

Intent-based Cross-chain matters because multi-chain operations have become too complex for users to handle manually.

Users need to consider:

  • which bridge is faster;
  • which bridge is cheaper;
  • whether the destination chain has liquidity;
  • whether to swap first or bridge first;
  • who pays gas;
  • how refunds work after failure;
  • who is trusted by the route.

That is not user experience. That is a cross-chain final exam.

The intent model moves complexity away from users and toward specialized execution networks. Users express the result, while the system finds routes, matches liquidity, manages risk, and settles.

This is why intents often appear together with chain abstraction, path optimization, liquidity networks, and gas abstraction. They are all trying to do the same thing: stop interrupting users with low-level execution details.

 

Key Components

First is the intent order.

This is the request signed by the user. It defines input assets, destination chain, output assets, minimum received amount, deadline, recipient, and execution conditions.

Second is the solver or filler.

These are the actors that fill the order. They find routes, provide liquidity, take execution risk, and earn fees, spreads, or incentives. Do not misunderstand: solvers are not doing charity. The spreadsheet always shows up.

Third is the order dissemination network.

Solvers need to see the user’s intent before they can compete to fill it. If the order sits quietly in a corner, nobody is coming.

Fourth is the settlement layer.

After a solver completes execution on the destination chain, it needs to recover funds from the source chain or protocol contracts. Settlement must protect both users and solvers.

Fifth is verification and risk control.

The system must confirm that the solver actually delivered the result. “Trust me, I did it” is not enough. Message verification, state proofs, signatures, order hashes, nonce, and deadlines all matter.

 

Difference from Traditional Bridges

  • A traditional bridge feels like: “The user chooses the route, and the system follows it.”
  • Intent-based Cross-chain feels like: “The user specifies the destination, and the system competes to find the best execution.”
  • Traditional bridges focus on process. Intents focus on outcomes.Traditional bridges ask, “Which bridge do you want to use?”
  • Intents ask, “What do you want to receive?”

Of course, intents do not eliminate bridges. Many intent systems may still use bridges, DEXs, liquidity pools, messaging protocols, and settlement contracts behind the scenes. The difference is that this complexity is no longer dumped on the user.

 

In plain words, users do not need to know how many pans the kitchen used. They just need the dish to arrive correctly.

A Simple Case

Suppose Alice wants to turn 1,000 USDC on Ethereum into ETH on Base.

The traditional flow may look like this:

  • find a bridge;
  • check bridge fees;
  • move USDC to Base;
  • realize there is no gas on Base;
  • find gas;
  • go to a DEX and swap into ETH;
  • price changes halfway;
  • Alice goes silent.

The intent-based flow looks more like this:

Alice signs an order:“I am willing to spend 1,000 USDC on Ethereum, and I want to receive at least a certain amount of ETH on Base.”

  • Multiple solvers see the order and compete.
  • One route may be cheaper but slower.
  • Another solver may already have ETH inventory on Base and can fill quickly.
  • Another may offer better pricing but charge more.

Finally, one solver fills the order and sends ETH to Alice on Base. Then it settles through the protocol and recovers Alice’s USDC and fees from Ethereum.

Alice sees one action.Behind the scenes, there is quoting, competition, routing, fronting liquidity, verification, settlement, and risk control.

That is the appeal of intents: the user states the goal, and the system competes on execution.

 

Common Misunderstandings

First misunderstanding: Intent-based Cross-chain is just a faster bridge.

Not exactly. It may use bridges, solvers, liquidity networks, DEXs, and messaging protocols together. It is not merely a bridge speed boost; it is a higher-level interaction model.

Second misunderstanding: once users sign an intent, there is no risk.

Wrong. An intent expresses the desired outcome. Execution still involves solver risk, settlement risk, price movement, liquidity shortage, contract risk, and failure recovery.

Third misunderstanding: solver competition always gives users the best price.

Not necessarily. Competition can improve pricing, but only if there are enough solvers, fair order distribution, transparent rules, and limited concentration. Otherwise, “competition” may just mean a few large players dominate.

Fourth misunderstanding: the more abstract the intent, the better.

Not always. Too much abstraction makes it unclear what the user authorized. A good intent should be simple, but still clearly define input, output, minimum received amount, deadline, and failure handling. Do not ask users to sign a black-box “do stuff for me” permission.

 

Risks and Limitations

First is solver concentration risk.

If a few solvers control most execution, the experience may be fast, but the market becomes dependent on a small number of actors. If they go offline, quote poorly, or reduce risk appetite, the whole system feels it.

Second is quote and execution mismatch.

The quote may look one way when shown, but market conditions may change before execution. Price, gas, liquidity, and congestion can affect the final result. Deadlines and minimum received amounts matter, or users may get hurt by quotes that looked good.

Third is failure recovery.

What happens if intent execution fails? Which chain gets the refund? Who pays gas? What if the solver fronted funds but source-chain settlement fails? These rules must be designed early, not improvised during the incident.

Fourth is black-box UX.

Users do not need every technical detail, but they should not know nothing. Wallets and apps should at least show what the user spends, what they receive, the minimum guarantee, estimated fees, who executes, and what happens if it fails.

Fifth is standards and compatibility.

If every intent protocol uses its own order format, solver interface, and settlement design, the ecosystem fragments. Standards like ERC-7683 matter because they help different systems share solver networks and infrastructure.

 

Conclusion

The core value of Intent-based Cross-chain is upgrading cross-chain interaction from users specifying steps to users expressing outcomes.

It means users do not manually find bridges, swap tokens, prepare gas, compare routes, or handle failures. They only need to define what they are willing to spend, what they want to receive, the minimum they accept, and the deadline.

But intents are not a cure-all. They move complexity from users to solvers, protocols, and infrastructure. To work well, they need enough solvers, clear standards, reliable settlement, transparent quotes, strong recovery mechanisms, and understandable user authorization.

If Web3 truly moves toward chain abstraction, Intent-based Cross-chain will be a key piece. Users do not want to be routers, bridge experts, or problem-solvers every time they transact. They just want to say: this is the result I want.

Let the system do the hard part.

 

About SuperEx

As the world’s first Web3-powered cryptocurrency exchange, SuperEx has remained committed to building the Web3 ecosystem. Over the years, it has introduced a comprehensive range of products and services, including SuperEx DAO, SuperEx Web3 Wallet, Super Start, SuperEx P2P, SuperEx Stock Markets, SuperEx Copy Trading, SuperEx Earn, and SuperEx DAO Academy, creating a full-spectrum ecosystem that spans every major sector of Web3.

Today, SuperEx serves over 10 million users, with a social media community of more than 600,000 followers across 166 countries and regions worldwide. The platform supports 1,000+ cryptocurrencies for both spot and futures trading. Seamlessly integrated with Super Wallet, SuperEx provides decentralized asset custody while combining the trading efficiency of a centralized exchange (CEX) with the security of a decentralized exchange (DEX).

 

 

1*7X8uHBH_gI7z3NfkogmMzA.jpeg

Posted

SuperEx Guide:Futures Trading-Advanced Trading Journey(VIV)

#SuperEx #CopyTrading #FuturesTrading

In the previous article, we used a detailed visual guide to explain how to become a successful Lead Trader. In today’s lesson, we’ll focus on the other key role in Copy Trading: how to become a Follower.

Follow our step-by-step visual guide to learn exactly how the process works

 

1*cGQ3HwpMPEAslw1C55iRQw.png

How to Use Copy Trading in SuperEx Futures

Step1:Log in to your SuperEx account and click on [Trade] — [Futures Copy Trading].

 

Step2:In the trading plaza, you can filter traders using the following criteria:

  • Time Range: 7/30/90-day performance
  • Trader Performance Metrics: Total follower profit, ROI, total profit, AUM (Assets Under Management), number of followers, maximum drawdown
  • Search: Filter traders by searching their UID or nickname
 

1*K0UdzNetgbqxDGg8i57mZg.png

 

1*F2CoELIQv-l3qitYV8HO2A.png

Step3:After selecting a trader, set your copy trading parameters:

  • Copy Trading Amount
  • Advanced Settings: Position Take Profit / Position Stop Loss / Maximum Margin Per Order
 

1*1WCgfxcXoiOzMzDeHnnWPw.png

Step4:You can view your ongoing and completed copy trades.

 

1*atEKbGRl-tlYSgO4ZJP8LQ.png

Ongoing Copy Trades:

  • [Adjust Balance]: You can add more funds or withdraw part of the copy trading amount. The maximum copy trading amount is 200,000 USDT.

Note: If the portfolio still has open positions, withdrawal is not supported.

  • [Copy Trade Settings]: Adjust position take profit/stop loss and the maximum amount per copied order.
  • [End Copy Trade]: The system will close all copied positions at market price, and the assets will be transferred back to your spot account.
    Please note that due to price fluctuations, the final settled amount may differ slightly. The expected profit share may also change depending on any open positions.
 

1*9FZZzskQhfUi3lJNsrSs5w.png

 

1*s83y5aIodpcFHeV0Th0xYA.png

 

1*f7rQKj2EmK1NgF2f8FjJtg.png

Click [Expand Details] to view:

  • Current Positions / Historical Positions / Order History / Trade History / Transfer Records / My Profit Share / Fund Flow
 

1*Sn3L9NefxHnFMXgysqR5AQ.png

You can also go to [Wallet] — [Copy Trading Account] to view project details.

 

 

1*7X8uHBH_gI7z3NfkogmMzA.jpeg

Posted

SuperEx Educational Series: Understanding Universal Liquidity Layer

#SuperEx #EducationalSeries

The most frustrating thing in a multi-chain world is not that users have no assets. It is that assets are everywhere, just not where they are needed.

You clearly have funds:Some USDC on Ethereum, some ETH on Arbitrum, rewards on Base, and a few tokens on Polygon that you barely remember buying.

Then you try to buy something on another chain, and the wallet says: insufficient balance.

  • User: but I have money across the ecosystem.
  • System: yes, but not on this chain.
  • User: amazing.

The Universal Liquidity Layer tries to solve this “funds exist, but are not usable here” problem. Its goal is not to literally merge all assets into one physical pool, but to make liquidity across chains discoverable, usable, routable, and settleable as if it were much more unified.

In plain English: stop making users move funds manually. Let the system find liquidity.

 

1*ycvc6841kAxzfMHsyPXa6w.png

What Is Universal Liquidity Layer?

Universal Liquidity Layer is an infrastructure concept that organizes liquidity fragmented across different chains, DEXs, bridges, pools, and solvers into an execution layer that wallets and applications can access in a unified way.

It is not one single product, nor a name owned by one protocol. More accurately, it is a capability layer:

  • Users can use assets from any chain to complete actions on a target chain.
  • Apps can accept value from multiple chains.
  • Wallets can show something closer to a unified balance.
  • Systems can automatically handle routing, swapping, gas payment, and settlement.
  • Solvers or liquidity providers can fill orders, front liquidity, and rebalance in the background.

In one sentence: Universal Liquidity Layer does not mean all funds literally sit in one pool. It means available liquidity can be coordinated by the system.

How Does It Work?

Think of it as the inventory system of a large supermarket chain.

A user orders from a store in New York. The system sees that New York has no stock, but Washington, D.C. warehouse has it, Los Angeles store has it, and a nearby supplier can deliver today. The user does not care where the inventory comes from. They care whether it arrives, how fast, and at what cost.

Universal Liquidity Layer does something similar in Web3.

  • The user says: “I want to complete this action on Base.”
  • The system checks: “Your assets are on Ethereum, Arbitrum, and Polygon.”

Then it calculates:

  • Should it bridge?
  • Should it swap?
  • Which solver has destination liquidity?
  • Which route has lower slippage?
  • Who fronts gas?
  • How does settlement happen?
  • What happens if it fails?

The user sees one button.

Behind the scenes, the system handles asset coordination, route optimization, liquidity matching, message verification, Paymaster settlement, and failure recovery. The user should not need to watch the kitchen.

Why It Matters

Universal Liquidity Layer matters because one of the biggest problems in the multi-chain world is liquidity fragmentation.

Assets sit on different chains, pools live inside different protocols, user balances are scattered across networks, and the app is deployed somewhere else. So users often face a very strange situation: globally funded, locally broke.

This hurts user experience badly.

Without a universal liquidity layer, users must do all of this manually:

  • find a bridge;
  • find a DEX;
  • prepare gas on the target chain;
  • compare slippage;
  • judge route security;
  • track failures themselves.

In plain words, that is not product experience. That is making users do infrastructure operations as a side job.

With a Universal Liquidity Layer, users get closer to a “one balance, usable everywhere” experience. Applications can serve multi-chain users more naturally without constantly asking: “Which chain is your money on?”

Technical Approaches

The first approach is liquidity aggregation.

The system connects multiple bridges, DEXs, aggregators, solvers, and liquidity networks, then searches for better quotes and routes. LI.FI is a useful example: its architecture connects bridges, DEXs, and solvers through an aggregation and routing layer for price discovery and execution.

The second approach is unified liquidity pools.

Some protocols try to design liquidity as shared pools across chains instead of isolated pools for every chain pair. Stargate V1’s unified liquidity is a classic example: one asset pool can serve multiple cross-chain routes, improving capital efficiency.

The third approach is solver networks.

Users express intents, and solvers use their inventory, capital, and routing ability to deliver the result. If a user wants assets on a destination chain, a solver can send them first and settle later on the source chain. Smooth UX, but it needs enough solvers, deep liquidity, and transparent rules.

The fourth approach is Universal Account plus Universal Balance.

Particle Network’s Universal Accounts abstract multi-chain assets into a more unified account and balance experience. Under the hood, cross-chain transactions, swaps, Paymasters, and settlement still happen, but the user sees something closer to “one usable balance.”

The fifth approach is rebalancing.

A universal liquidity layer is not a perpetual motion machine. If one chain keeps paying out while another keeps receiving, inventory becomes unbalanced. The system needs fee adjustments, arbitrage, incentives, market makers, credit allocation, or internal accounting to keep liquidity healthy.

Relation to Liquidity Networks and Chain Abstraction

  • A Liquidity Network is more like “who has funds at the destination and can fulfill the user.”
  • A Universal Liquidity Layer coordinates all these liquidity sources.
  • Chain Abstraction is the user-facing result where users do not need to care about chains.

They often appear together.

The user says: “I want to buy this asset on Solana, but my funds are on Base.”

  • The chain abstraction wallet understands the intent.
  • Path optimization finds the route.
  • The Universal Liquidity Layer finds and coordinates liquidity.
  • Solvers or pools execute.
  • Paymasters handle gas.
  • Failure recovery handles problems.

The user sees: bought.

The backend sees: another mission completed.

A Simple Case

Suppose Alice wants to join a SuperEx campaign on Base and needs to pay 100 USDC. But her funds are not on Base. She has 40 USDC on Ethereum, 30 USDC on Arbitrum, and 35 USDT on Polygon.

In the traditional experience, Alice must do many steps herself:

  • bridge Ethereum USDC to Base;
  • bridge Arbitrum USDC to Base;
  • swap Polygon USDT into USDC;
  • bridge it to Base;
  • prepare Base gas;
  • finally pay the campaign fee.

Even writing this flow is tiring, never mind actually doing it.

With a Universal Liquidity Layer, Alice only clicks “Join Campaign.” The system checks her multi-chain balances, calculates how to combine funds, and may let a solver pay 100 USDC on Base first, then settle using Alice’s balances across chains.

  • Alice feels: I have funds, and I can use them.
  • Behind the scenes: multi-chain balance detection, asset swapping, cross-chain routing, solver fulfillment, gas abstraction, settlement, and risk control.

That is what a universal liquidity layer is really trying to bring: not technical flexing, but preventing user funds from becoming visible yet unusable.

Common Misunderstandings

First misunderstanding: Universal Liquidity Layer means one giant pool.Not necessarily. It can be a shared pool, but it can also be a combination of aggregators, solver networks, universal accounts, and liquidity routers. The key is unified access, not one contract holding everything.

Second misunderstanding: unified balance means all funds are literally together.No. Unified balance is usually a UX abstraction. The assets may still sit across many chains. The system coordinates execution for you. The money did not merge; the system learned to move.

Third misunderstanding: universal liquidity is always cheaper.Not always. It can be easier, faster, and smoother, but cross-chain messaging, solver fees, gas, slippage, and rebalancing costs still exist. Users simply do not manage every piece manually.

Fourth misunderstanding: the more unified liquidity is, the lower the risk.Not necessarily. Unified access improves efficiency, but can introduce dependency concentration, black-box routing, solver concentration, contract risk, and systemic failures. Convenient does not mean invincible.

Risks and Limitations

Universal Liquidity Layer is not magic. It solves fragmentation, but it also introduces new engineering and security challenges.

First is liquidity-source risk.

If most liquidity comes from a few solvers or market makers, user experience can degrade quickly if they withdraw, go offline, or raise prices.

Second is black-box routing risk.

The system may say “this is the best route,” but why? What are the fees? Which protocols are involved? What happens if it fails? If users know nothing, chain abstraction becomes an on-chain mystery box.

Third is rebalancing risk.

Multi-chain liquidity will not stay balanced forever. If demand spikes on one chain, inventory may run out, fees may rise, and orders may fail. It is not always that the system refuses to help; sometimes the shelf is empty.

Fourth is settlement risk.

Solvers may pay first and settle later. What if source-chain state fails, message verification is delayed, user authorization is invalid, or prices move violently? Loss rules must be defined in advance.

Fifth is mixed security-model risk.

One action may involve a wallet, router, bridge, DEX, solver, Paymaster, and messaging protocol. Every layer adds assumptions. The smoother the UX, the clearer the security boundaries need to be.

Conclusion

The core value of Universal Liquidity Layer is turning multi-chain assets from isolated balances into usable liquidity that can be coordinated through one layer.

It does not make assets teleport, and it does not erase costs. It uses aggregation, routing, solvers, universal accounts, gas abstraction, and settlement mechanisms to create an experience closer to “one balance, usable across chains.”

If Web3 continues becoming multi-chain, liquidity fragmentation will become more serious. Users cannot manually find bridges, pools, gas, routes, and liquidity providers every day. A mature system should let users express the need: I want to use my assets to complete this action.

Let the Universal Liquidity Layer handle the coordination.

In plain words, users are not always broke.Their funds are just scattered across chains.The Universal Liquidity Layer exists so users do not get blocked just because their money is not on this exact chain.
That is what a normal product should feel like.

About SuperEx

As the world’s first Web3-powered cryptocurrency exchange, SuperEx has remained committed to building the Web3 ecosystem. Over the years, it has introduced a comprehensive range of products and services, including SuperEx DAO, SuperEx Web3 Wallet, Super Start, SuperEx P2P, SuperEx Stock Markets, SuperEx Copy Trading, SuperEx Earn, and SuperEx DAO Academy, creating a full-spectrum ecosystem that spans every major sector of Web3.

Today, SuperEx serves over 10 million users, with a social media community of more than 600,000 followers across 166 countries and regions worldwide. The platform supports 1,000+ cryptocurrencies for both spot and futures trading. Seamlessly integrated with Super Wallet, SuperEx provides decentralized asset custody while combining the trading efficiency of a centralized exchange (CEX) with the security of a decentralized exchange (DEX).

 

 

1*7X8uHBH_gI7z3NfkogmMzA.jpeg

Posted

SuperEx Guide:Futures Trading-Advanced Trading Journey(X)

#SuperEx #Guide #FuturesTrading

Today marks the final installment of our Copy Trading series.

After ten articles, we hope you’ve gained a comprehensive understanding of All-Token Perpetuals and Copy Trading — from the core concepts and underlying logic to their advantages, practical applications, and how both Lead Traders and Followers can benefit.

To wrap up the series, we’re going to cover one of the most important topics of all: the essential rules of Copy Trading and the question everyone wants answered:“How much can we actually earn?”

Without further ado, let’s dive in.

 

1*ut45abqB-PqyC_vE0N2l4g@2x.png

Superex Copy Trading Rules

1. Copy Trading Triggers Immediate Opening

When a follower initiates copy trading:

  • The system checks if the signal provider has open positions.
  • If the signal provider holds positions AND the current price is better than the entry price, the follower copies the position.
  • If the price is unfavorable, no position is opened.

2. Standard Copy Trading Execution

The system monitors the signal provider’s opening actions and replicates them proportionally:

  • Position Ratio: Followers copy the signal provider’s position size ratio.
  • Position Mode: Followers mirror the signal provider’s leverage and margin mode.

Order Execution Logic for Followers

 

1*-D5c4dpjo2wNtamhiLWJAA.png

3. Closing Positions

The system mirrors the signal provider’s closing actions proportionally:Followers close positions in the same percentage as the signal provider.Order Execution Logic for Closin

 

1*S59ZPXwCpTeBYtwPEanndg.png

4. Position Sizing Calculation

Current Support: Proportional Copy Trading (1-click). Future updates will expand functionality.

A. Opening Positions
Formula: Follower’s Position Size = min( floor(0.97 × Signal Provider’s Position Size / Signal Provider’s Max Available × Follower’s Max Available),
System Max Position Size, User Max Position Size — Current Holdings )

Example:

  • Signal Provider: $2,000 margin balance, uses $500 to open positions (25% ratio).
  • Follower: $1,000 allocated → System allocates $250 (25% of $1,000). Actual allocation may be lower due to slippage.

B. Immediate Copy-Opening

Formula: Follower’s Position Size = min( floor(0.97 × Signal Provider’s Initial Margin / Signal Provider’s Current Margin Balance × Follower’s Max Available),System Max Position Size, User Max Position Size — Current Holdings )

Example:

  • Signal Provider: Initial margin = $500, current balance = $2,000 (25% ratio).
  • Follower: $100 allocated → System uses $25 to open positions.

5. Closing Position Calculation

Proportional Closing: If the signal provider closes 20% of their position (e.g., 0.2 BTC out of 1 BTC), followers automatically close 20% of their copied positions.

SuperEx Signal Provider Profit Sharing

Signal providers receive 10% profit sharing from followers’ profitable trades. The platform will later support manual configuration of profit-sharing ratios.

Profit Sharing Types:Futures copy trading profit sharing includes:

Scheduled Profit Sharing

  • Executed every Monday at 00:00 UTC.
  • Only considers realized P&L during the current week, regardless of open positions or historical P&L data.

Order Closure Profit Sharing

  • Triggered when copy trading ends (either due to the signal provider terminating the project or followers ending it manually).
  • Only this week’s realized P&L is considered, independent of historical data.

Profit Transfer Mechanism:

Pending profit-sharing amounts frozen in followers’ copy trading account wallets will be transferred to the signal provider’s Spot Wallet.

Pending Profit Calculation Formula:

Pending Profit = max(This week’s Realized P&L × Profit-sharing ratio, 0)

Note: Pending profits are frozen and cannot be withdrawn, but do not affect margin balances.

About SuperEx

As the world’s first Web3-powered cryptocurrency exchange, SuperEx has remained committed to building the Web3 ecosystem. Over the years, it has introduced a comprehensive range of products and services, including SuperEx DAO, SuperEx Web3 Wallet, Super Start, SuperEx P2P, SuperEx Stock Markets, SuperEx Copy Trading, SuperEx Earn, and SuperEx DAO Academy, creating a full-spectrum ecosystem that spans every major sector of Web3.

Today, SuperEx serves over 10 million users, with a social media community of more than 600,000 followers across 166 countries and regions worldwide. The platform supports 1,000+ cryptocurrencies for both spot and futures trading. Seamlessly integrated with Super Wallet, SuperEx provides decentralized asset custody while combining the trading efficiency of a centralized exchange (CEX) with the security of a decentralized exchange (DEX).

 

 

1*7X8uHBH_gI7z3NfkogmMzA.jpeg

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
x

⤴️ - Paid Ad. Add your banner here.🔥

×
×
  • Create New...