Community trading with shared execution

1.1What this is

This document describes a trading platform where a group of people enter and exit a position through one combined transaction instead of a sequence of separate ones. A member proposes a trade, the other members choose how much they want to put in during a short commitment window, and the aggregated order is executed once. Every participant receives a proportional share of that execution.

The components underneath are familiar. Smart accounts hold each member's funds, an order layer collects commitments before anything reaches the public chain, and a routing path decides where the combined order is filled. The product those components support is easier to describe than the components themselves: a group finds a trade, commits to it, and enters it together.

1.2The problem with sharing trades

Social trading today gives the person who acts first a structural advantage over everyone who hears about the trade afterwards. Someone finds a token and buys it. They then share it with friends, with a group chat, with followers, or with the users of a platform. By the time the rest of the group buys, the entries have already drifted.

The first buyer has the best entry. The second gets a slightly worse one. The tenth gets worse again. In a thin market, the hundredth participant can end up providing the liquidity the earlier ones sell into. The effect is most obvious in small, high velocity tokens, where even modest orders move the price.

1.3Why copy trading does not fix it

Copy trading automates the follower's side of the process, but the order of events does not change. The leader executes, the follower's system detects the transaction, and the follower executes afterwards. Even when that happens in a fraction of a second, the follower is still behind the original trade. The faster and thinner the market, the more that gap costs.

1.4The model

Instead of copying a trade after it happens, members participate in the original trade. A member proposes a position. The group is given a short commitment window. Each member chooses an amount. The platform aggregates the commitments and executes the combined order once, then allocates the result proportionally.

1.5A worked example

Five people want the same token and each has 200 dollars to put in. Trading separately, they send five orders into the same pool, and each order moves the price for the next one.

Through the platform, the same five commitments form a single order.

One execution takes place and the tokens are distributed pro rata between the five members. Nobody is positioned ahead of anybody else, and no member's fill is made worse by another member's order arriving first.

1.6What shared execution means

The accurate description is shared execution rather than a single identical spot price. A large order against an automated market maker fills across several price levels because of slippage, and combining orders does not remove that. What changes is that the whole group takes part in the same aggregated transaction and is allocated from the same result.

If the aggregated order settles at an average of 0.0104, every participant is allocated at that group average in proportion to what they committed. Clicking two seconds earlier than someone else confers no advantage.

2.1Group structure and roles

A group is the unit that holds members, proposals and history. Creating one can be gated behind an access tier so that public groups carry some cost to establish. A group carries a name, a profile, a founder, its members and a running record of what it has traded.

A group does not need a single decision maker. A workable set of roles is a founder who owns the group settings, approved traders who may propose positions, analysts who contribute research without proposal rights, and members who decide for themselves whether to join any given trade. The same structure works for five friends and for a community of several thousand.

• Name, profile and founder
• Member list and roles
• Trade history with realised and unrealised results
• Win rate, volume and average holding period
• Markets the group trades most often
• Reputation derived from executed trades

2.2Proposing a trade

A proposal is a small set of parameters that fully describes what the group is being asked to join. It states the side, the asset, how much the proposer is aiming to raise, how long members have to decide, and the conditions under which the trade should be abandoned.

2.3Committing to a proposal

Members are not required to contribute equal amounts. One person commits 100 dollars, another 500, another 2,000. The platform combines the commitments and allocates the resulting position pro rata, which preserves individual position sizing while keeping the execution shared.

Fast trades do not need governance. A proposal stays open for something in the range of 20 to 60 seconds. Anyone who wants in commits, anyone who does not simply lets it pass, and the trade executes on the terms already published. Introducing a vote would add delay to the part of the process that is most sensitive to it.

Members watch the order fill in real time, which is also what makes a proposal feel like a shared event rather than a private decision.

Each proposal can carry its own discussion alongside the chart, liquidity, market capitalisation, the proposer's track record, the amount committed so far and the time remaining. The conversation that already happens in a group chat sits directly next to the decision it relates to.

2.4Coordinated exits

The same mechanism works in reverse. A group can propose selling a quarter of the position or closing it entirely. Participating members' holdings are combined into the sell order and the proceeds are distributed proportionally. The product is not only about entering together, it covers the whole life of a position.

2.5Private groups, then public

The first version should target private groups. Five friends who already share trades in a chat every day have an obvious use for it. Instead of one person announcing a buy and everyone else pasting a contract address into a separate application, one person proposes and everyone gets the same opportunity to join.

Public groups make the model considerably more interesting. A trader with an audience of a few thousand can propose a trade through the group rather than buying first and posting about it afterwards. Members opt in, the order is aggregated, and everyone enters through the same execution.

2.6Reputation and leaderboards

Because every group trade is an actual execution recorded by the platform, group performance can be calculated from fills rather than from screenshots posted by traders. That is the meaningful difference between this and existing performance claims.

Example group profile. Figures are illustrative.

Individual proposers accumulate their own records alongside the group. One person may be consistently good at finding new tokens, another at larger and slower positions, another at calling exits. Over time the platform builds a social graph of trading skill that is grounded in settled trades. Groups can then be ranked by recent performance, win rate, volume, consistency or risk adjusted return, which adds a competitive layer on top of the execution product.

3.1The internal order layer

Commitments are collected off chain before the final trade is exposed to the public network. Members register intent, the platform combines those intents into one order, and only the resulting transaction is broadcast.

The chain sees one execution rather than four accounts announcing in sequence what they are about to do. That is both better for the fills and a smaller surface for anyone watching the mempool for predictable follow on flow.

3.2Minimum execution thresholds

A proposal can require a minimum before it executes at all. If the target is 20,000 dollars with a minimum of 10,000, and only 4,000 is committed when the window closes, the proposal expires and nobody trades. This protects a proposer who intended to open a meaningful group position from ending up with a token position sized for a fraction of it.

3.3Price bounds and cancellation

A proposal can also carry a price boundary. If the maximum entry is set at 0.0042 and the token trades through that level before the window closes, the trade is cancelled. Members are not committed to whatever the market does in the twenty seconds after they clicked, only to the terms they agreed to.

3.4Routing

Over time the protocol can decide where an order is best filled rather than sending everything to one venue. The group forms an order, the protocol checks available liquidity and routes, and the trade is executed where the terms are best. That is what turns the platform into an execution layer rather than another interface onto a single exchange.

3.5Execution protection

Because the protocol controls the path an order takes, it can apply protections that individual traders rarely apply for themselves.

• Private transaction submission
• Routing that accounts for extractable value
• Slippage limits enforced at the order level
• Price impact caps on aggregated size
• Bundled execution
• Reverting when conditions change before the transaction lands

4.1Non custodial by design

Members should never move their capital into a wallet controlled by whoever runs the group. Each trader keeps ownership of their own account and assets, and the platform coordinates permissions and execution across those accounts. A group founder has the ability to propose and to execute within agreed limits, never unrestricted access to member funds.

4.2Programmable accounts

Account abstraction, in the form of ERC-4337 smart accounts, is what makes that possible. Rather than granting custody, a member authorises a specific and bounded set of actions that the account itself enforces.

Example permission set. These are enforced by the account, not by the interface.

4.3Session permissions

Speed matters for this kind of trading. Nobody wants to open a wallet, confirm, wait, and confirm again every time a token starts moving. A member can create a session permission scoped to a particular group, with its own limits and expiry, so that joining a proposal is a single action. The result feels like a normal consumer trading application while the member keeps self custody.

4.4Risk controls

Risk settings should be a primary feature rather than a page in the settings menu, and because they live in the smart account they are enforced rather than advisory.

• Maximum size for a single trade
• Daily spend ceiling
• Maximum share of portfolio in one position
• Maximum slippage
• Minimum liquidity and market capitalisation for eligible assets
• Stop loss rules and whether automated exits are permitted
• Approved groups and approved proposers

4.5Group identity onchain

If groups eventually become objects on chain, token bound accounts under ERC-6551 give them somewhere to live. A group would be represented by a token with its own account, carrying trade history, reputation, open positions, membership, governance rights and any treasury it holds. A group with a few thousand members becomes a verifiable trading entity rather than a chat room with a name. This belongs in phase two and is not needed to prove the core mechanism.

5.1Role of the token

Requiring the token to be spent on every trade adds friction and makes the product feel built around the token rather than the other way round. A freemium model with locked tiers is a better fit. The token governs access, limits and advanced functionality, and stays out of the trading path itself.

5.2Access tiers

An indicative structure, with thresholds to be set later once usage data exists.

5.3Creator lock

Group creators can lock tokens behind the groups they run, which adds a second reputation signal alongside performance. A serious public group is likely to lock a meaningful amount. Someone who repeatedly creates low quality groups and abandons them has visibly little at stake. Slashing should not be introduced at the start, since it raises a much harder set of questions about who decides what counts as misconduct.

5.4Access is not custody

5.5Revenue

The platform can earn from a small execution or platform fee rather than depending entirely on token demand, alongside premium functionality, professional tooling for larger groups, advanced execution features and API access.

The fee level needs modelling before launch. The product exists to improve fills, so a fee large enough to consume the improvement removes the reason to use it.

6.1Audience led growth

The product uses public traders as a native part of how it works rather than as a marketing channel bolted on afterwards. The pitch to a trader with an audience is not a request to post about a new platform. It is an invitation to create a group and bring their community into their trades. Their community joins because they are participating in something with that trader, which is a stronger acquisition loop than paid promotion.

6.2Launch venue and liquidity partners

Launching through an established venue with a trading native audience gives the product initial users, credibility, distribution and, where the relationship is close enough, technical support during the launch itself. That is worth considerably more here than launching into an empty ecosystem, because the product needs groups of active traders on day one to demonstrate anything at all.

A market making relationship matters beyond supporting the token. Market makers can contribute directly to the core product on execution quality, liquidity, routing, slippage behaviour, protection around larger aggregated orders and general market structure.

6.3Starting market

The right place to start is high velocity, socially traded tokens, because that is where the problem is most visible. Nobody minds getting an entry on a large and liquid asset two seconds after a friend. People mind a great deal when a token moves fifteen percent while ten members of the same group are trying to buy it.

6.4Position relative to discovery apps

Rather than competing with token discovery applications by building another one, this sits on top of the behaviour those applications created. They made trading a social activity. This adds coordination to the activity they already produced, which is a different job and does not require winning the discovery race.

6.5Messaging app surface

The model fits a messaging app well, because that is where trading groups already talk. A member proposes a trade and the bot posts a card showing the token, the amount committed so far, the number of participants and the time remaining, with a single control to join. The member taps once and their smart account handles the rest.

6.6Automated participation and agents

Once a member trusts a particular group or proposer, they can enable automatic participation within their own limits: join this trader's proposals with 100 dollars, at most five trades a day, stop at 300 dollars of daily loss, only tokens above 500,000 dollars of liquidity. This captures what people want from copy trading while still routing them through the coordinated group execution.

The same interface eventually accepts agents. A group can allow an agent to propose trades, or a member can set a rule to participate whenever three proposers they trust agree on the same asset. That turns groups into coordination networks for both people and software. This should not lead the product story, because the human version is already easy to explain.

7.1Minimum viable product

The first release does not need most of what is described above. It needs to answer one question.

If that runs smoothly and members can see their position afterwards, the rest of the product has something solid to build on. If it does not, no amount of additional features will help.

7.2Phase two

Once shared execution works reliably, the following can be layered on in roughly this order.

• Public groups with profiles and verified track records
• Leaderboards and discovery
• Automated participation within member set limits
• Advanced account permissions and session scopes
• Messaging app integration
• Token tiers
• Better routing and execution protection

7.3Phase three

The coordination layer is not specific to one asset class. The same mechanism applies anywhere several people want exposure to the same position at the same time.

• Spot tokens
• Tokenised equities
• Prediction markets
• Perpetual positions
• Liquidity positions
• Portfolio baskets

7.4Summary

Trading communities already exist on messaging apps, forums and private chats. They communicate together and execute separately, and the gap between those two things is where followers lose money. Closing that gap is the whole product.

Stated in one sentence: the platform lets friends and communities enter trades together through one aggregated execution, giving everyone proportional exposure to the same trade instead of forcing followers to chase whoever bought first.