Revenue-Sharing Models for AI Prediction Agents

Flat fees are the simplest way to monetize a prediction market agent. But they have a fundamental problem: they misalign incentives between the developer and the buyer. The developer gets paid regardless of whether the agent makes money. The buyer bears all the performance risk. And when the agent underperforms, the buyer churns — often loudly, in a market small enough that one bad review can materially impact future sales.

Revenue-sharing fixes this by tying the developer’s compensation to the buyer’s outcomes. The developer earns more when the agent performs well, earns nothing when it loses money, and has a direct financial incentive to maintain and improve the agent over time. For buyers, it lowers the barrier to entry — no large upfront payment — and provides confidence that the developer has skin in the game.

This alignment explains why revenue-sharing is becoming the dominant model for high-performing prediction market agents. The infrastructure to support it (on-chain profit tracking, transparent logging, smart contract splits) has matured to the point where implementation is practical, not just theoretical.

This guide covers five revenue-sharing models, how to implement them (including smart contract approaches), how to calculate profits fairly, how to build trust into the arrangement, and when revenue-sharing makes more sense than alternatives. For a broader overview of all pricing models, see the pricing guide.

Disclaimer: Nothing in this guide constitutes financial, legal, or tax advice. Revenue-sharing arrangements may create legal obligations and tax liabilities depending on your jurisdiction. Consult a lawyer and tax professional before entering into any profit-sharing agreement.

Why Revenue-Sharing Is Gaining Traction

Three forces are driving the shift toward revenue-sharing in the prediction market agent space.

Buyer skepticism. The prediction market bot market is young, and buyers have been burned by agents that looked good in backtests but failed in production. Revenue-sharing lets buyers evaluate an agent with real money at risk while limiting their downside — if the agent does not generate profits, they owe the developer nothing.

Developer confidence signal. Offering revenue-sharing tells the buyer that you believe in your agent’s performance. A developer who insists on a $5,000 upfront fee with no performance guarantee is making a different statement than one who says “pay me 20% of the profits I generate for you.” The latter signals confidence and alignment.

Infrastructure maturity. Until recently, revenue-sharing for trading bots was impractical because there was no reliable way to track profits transparently. Both parties had to trust the other’s accounting. Now, on-chain profit tracking, Moltbook verification, and smart contract-based automatic splits make trustless revenue-sharing feasible.

How Revenue-Sharing Works for Prediction Market Agents

The basic mechanics are straightforward. The buyer provides capital and platform access (their Polymarket or Kalshi account credentials). The developer provides the agent software. The agent trades using the buyer’s capital. At predefined intervals (weekly, monthly, or quarterly), net profits are calculated and split according to the agreed terms.

The complexity lives in the details: what counts as profit, how losses are handled, what happens when the agent is paused, and how both parties verify the numbers.

The Basic Flow

Buyer provides:           Developer provides:
├── Trading capital       ├── Agent software
├── Platform API keys     ├── Ongoing maintenance
└── Risk parameters       └── Strategy updates

         ↓                         ↓
    ┌─────────────────────────────────┐
    │     Agent trades on buyer's     │
    │     account with buyer's capital│
    └──────────────┬──────────────────┘
                   ↓
    ┌─────────────────────────────────┐
    │  Profit calculated at interval  │
    │  (weekly / monthly / quarterly) │
    └──────────────┬──────────────────┘
                   ↓
    ┌─────────────────────────────────┐
    │  Developer's share distributed  │
    │  (automatic or manual)          │
    └─────────────────────────────────┘

Five Revenue-Sharing Models

Each model below addresses different risk profiles and relationship dynamics. The right model depends on your agent’s performance characteristics, your buyer’s preferences, and how much complexity you are willing to manage.

Model 1: Simple Profit-Split

The most straightforward model. At the end of each period, calculate net profit (revenue minus trading costs and fees). Split the profit at a fixed percentage.

How it works: If the agent generates $10,000 in net profit during a month and the split is 20/80 (developer/buyer), the developer receives $2,000 and the buyer retains $8,000.

Advantages:

• Easy to understand and implement
• Low overhead for calculation and distribution
• Works well for consistent-performing agents

Disadvantages:

• Developer earns in profitable months even after a losing month — no loss recovery requirement
• Can incentivize excessive risk-taking (the developer captures upside but does not share downside)

Model 2: High-Water Mark

The industry standard for performance-based compensation. The developer only earns a profit share when the portfolio value exceeds its previous peak. If the agent loses money, the developer earns nothing until those losses are fully recovered.

How it works: The portfolio starts at $100,000. Month 1, it grows to $110,000 — the developer earns 20% of the $10,000 profit ($2,000). Month 2, the portfolio drops to $105,000. No developer payment. Month 3, the portfolio recovers to $112,000. The developer only earns on the $2,000 above the previous high-water mark of $110,000 (after the Month 1 share was paid): 20% of $2,000 = $400.

Advantages:

• Prevents the developer from earning during periods of net loss
• Aligns incentives for consistent performance, not just occasional spikes
• Industry-standard model that sophisticated buyers expect

Disadvantages:

• More complex to track — requires maintaining a persistent high-water mark
• After a significant drawdown, the developer may have to recover substantial losses before earning again, which can reduce motivation

Model 3: Hurdle Rate

The developer only earns a profit share on returns that exceed a predefined benchmark — the hurdle rate. Returns up to the hurdle go entirely to the buyer. This compensates for the fact that some baseline return is achievable without a specialized agent (e.g., through simple diversified positions).

How it works: The hurdle rate is set at 5% per month. If the agent generates 12% returns in a month, the developer earns their percentage only on the 7% above the hurdle. On a $100,000 portfolio: the first $5,000 in profit goes to the buyer, and the developer’s 25% share applies to the remaining $7,000 — yielding $1,750.

Advantages:

• Buyer only pays for alpha (returns above what they could get on their own)
• Encourages the developer to build genuinely differentiated strategies
• Fair model when the buyer has alternative deployment options

Disadvantages:

• Setting the appropriate hurdle rate is subjective and can cause disputes
• In low-return environments, the developer may earn very little even if the agent is performing well relative to conditions

Model 4: Tiered Profit-Split

The developer’s share increases as performance improves. This incentivizes exceptional performance and gives buyers favorable terms during average periods.

How it works: The split scales with returns.

On a $100,000 portfolio that generates 12% ($12,000) in a month:

• First 5% ($5,000): Developer gets 15% = $750
• Next 5% ($5,000): Developer gets 20% = $1,000
• Remaining 2% ($2,000): Developer gets 25% = $500
• Total developer payment: $2,250

Advantages:

• Rewards exceptional performance with higher compensation
• Buyer pays less during average months
• Creates strong incentive for the developer to maximize returns

Disadvantages:

• More complex to calculate and explain
• May incentivize risk-taking to reach higher tiers
• Requires clear documentation of tier boundaries

Model 5: Hybrid (Base Fee + Performance)

Combines a small fixed monthly fee with a revenue share. The base fee covers the developer’s infrastructure and maintenance costs. The performance component provides upside alignment.

How it works: The buyer pays a $200/month base fee plus 15% of net profits above a $500 minimum threshold. In a month where the agent generates $8,000 in profit: the buyer pays $200 (base) + 15% of $8,000 ($1,200) = $1,400 total. In a month with no profit: the buyer pays only $200.

Advantages:

• Developer has stable baseline income for infrastructure costs
• Lower performance share needed (base fee compensates)
• Buyer’s total cost is still performance-linked for the majority of the fee

Disadvantages:

• Buyer pays something even in losing months (the base fee)
• More complex structure than pure profit-split or pure subscription

Model Comparison

Smart Contract Implementation

On-chain profit tracking and automatic splits eliminate the trust problem that plagues manual revenue-sharing arrangements. Neither party needs to trust the other’s accounting — the smart contract is the accounting.

Architecture

The core concept is a profit-tracking contract that sits between the agent’s trading activity and profit distribution. The contract receives trading proceeds, tracks the portfolio’s high-water mark, calculates the developer’s share according to the agreed model, and distributes funds automatically.

# Simplified smart contract logic (Solidity-like pseudocode)
# Actual implementation would use Solidity for EVM chains

class ProfitSplitContract:
    """On-chain profit tracking and automatic revenue splits."""

    def __init__(
        self,
        developer_address: str,
        buyer_address: str,
        developer_share_pct: int,  # basis points (2000 = 20%)
        high_water_mark: int,      # initial deposit in wei
        settlement_period_days: int,
    ):
        self.developer = developer_address
        self.buyer = buyer_address
        self.share_bps = developer_share_pct
        self.hwm = high_water_mark
        self.period = settlement_period_days
        self.last_settlement = block.timestamp
        self.total_deposited = high_water_mark

    def settle(self):
        """Calculate and distribute profits at period end."""
        assert block.timestamp >= self.last_settlement + (self.period * 86400)

        current_value = self.get_portfolio_value()

        if current_value <= self.hwm:
            # No profit above high-water mark — no developer payment
            self.last_settlement = block.timestamp
            return

        profit = current_value - self.hwm
        developer_payment = (profit * self.share_bps) // 10000

        # Transfer developer's share
        self.transfer(self.developer, developer_payment)

        # Update high-water mark
        self.hwm = current_value - developer_payment

        self.last_settlement = block.timestamp

    def deposit(self, amount):
        """Buyer adds capital — adjusts high-water mark proportionally."""
        self.hwm += amount
        self.total_deposited += amount

    def withdraw(self, amount):
        """Buyer withdraws — triggers settlement first."""
        self.settle()
        self.transfer(self.buyer, amount)
        self.hwm -= amount

Practical Considerations

Smart contract-based profit splits work best when the agent trades on-chain platforms (Polymarket runs on Polygon, which makes on-chain accounting natural). For off-chain platforms like Kalshi, you need an oracle or attestation mechanism to bring trading results on-chain — or you fall back to manual settlement with Moltbook-verified performance logs.

The gas costs of settlement transactions are negligible on L2 chains (Polygon, Base, Arbitrum) where most prediction market activity occurs. A monthly settlement transaction costs fractions of a cent.

Calculating Profits Fairly

The most common source of disputes in revenue-sharing arrangements is disagreement over what counts as “profit.” Define this precisely before the first trade.

What Counts as Profit

Net profit should be calculated as:

Net Profit = Gross Trading Gains
           - Trading Losses
           - Platform Fees (trading fees, withdrawal fees)
           - Gas Costs (on-chain transaction fees)
           - Slippage Costs (difference between expected and actual execution)

What Does NOT Count as Profit

• Unrealized gains (only count profit on closed positions)
• Capital appreciation of deposited tokens unrelated to trading (e.g., USDC/USDT price fluctuations)
• Interest earned on idle capital (unless explicitly included in the agreement)

Handling Losses

The most buyer-friendly approach is the high-water mark: the developer earns nothing until all previous losses are recovered. This should be the default for any revenue-sharing agreement.

Define a maximum drawdown clause: if the portfolio drops more than a specified percentage (e.g., 25%) from its peak, the agreement is automatically paused or terminated. This protects both parties — the buyer from further losses, and the developer from an unrecoverable high-water mark.

Time Periods and Settlement

Monthly settlement is the most common and generally the best balance between administrative overhead and fair compensation timing.

Trust and Verification

Revenue-sharing requires a higher level of trust than flat-fee arrangements because both parties need confidence in the profit calculations. Three mechanisms build this trust.

Moltbook Verification

Moltbook provides third-party verification of agent performance. When your agent’s trading history is recorded on Moltbook, both parties can reference an independent source of truth for profit calculations. This is especially valuable when the agent trades on centralized platforms (Kalshi) where on-chain verification is not available.

On-Chain Transparency

For on-chain platforms like Polymarket, every trade is recorded on the blockchain. This creates an immutable, publicly verifiable record of the agent’s activity. Smart contract-based settlement uses this on-chain data directly, eliminating any possibility of accounting disputes.

Third-Party Audits

For high-value arrangements (managing $50,000+ in capital), consider engaging a third-party auditor to verify profit calculations. This adds cost but provides the highest level of trust. Some developers offer buyer-funded audits as an optional add-on.

Minimum Verification Stack

At minimum, every revenue-sharing arrangement should include:

1. Timestamped trade logs accessible to both parties
2. Daily portfolio snapshots with net asset value calculations
3. Monthly performance reports auto-generated from trade data
4. Agreed calculation methodology documented before the first trade
5. Dispute resolution process defined in the agreement

Legal and Tax Considerations

Revenue-sharing arrangements for trading agents occupy a regulatory gray area in most jurisdictions. This section highlights issues to discuss with a lawyer — it is not legal advice.

Agreement Structure

The revenue-sharing agreement should clearly define:

• Relationship type: Is the developer a service provider, a partner, or an independent contractor? This has significant tax and liability implications.
• Performance obligations: What is the developer required to do beyond providing the software? Maintenance? Updates? Uptime guarantees?
• Termination conditions: Under what circumstances can either party end the arrangement? What happens to unrealized positions?
• Liability limitations: The developer is not guaranteeing returns. The agreement should explicitly state that the buyer accepts the risk of financial loss.
• Intellectual property: The developer retains ownership of the agent software. The buyer is licensing it, not purchasing it.

Tax Implications

Revenue-sharing income is generally taxable. Depending on your jurisdiction and the structure of the arrangement:

• The developer may owe income tax on their share of profits
• If structured as a partnership, both parties may have reporting obligations
• International arrangements may trigger withholding tax requirements
• Crypto-denominated payments have additional reporting complexity

Consult a tax professional before your first settlement. The IRS (and equivalent agencies in other jurisdictions) treats income from trading software arrangements as ordinary income in most cases.

For a broader overview of legal considerations when selling AI agents, including licensing, liability, and regulatory compliance, see the legal guide.

When Revenue-Sharing Makes Sense vs. Flat Fees

Revenue-sharing is not always the right model. Here is a decision framework.

Choose Revenue-Sharing When:

• Your agent has a strong, verified track record (90+ days live)
• You are confident in sustained performance
• Your target buyers are risk-averse and hesitant to pay upfront
• You want to capture upside from high-performing periods
• You are willing to earn nothing during drawdowns

Choose Flat Fees When:

• Your agent is new and lacks a long track record
• Performance is consistent but moderate (steady 5-8% monthly)
• You need predictable income for infrastructure costs
• Your buyer pool is technical and prefers simple pricing
• You do not want the overhead of profit tracking and settlement

Choose Hybrid When:

• You want baseline income stability plus upside exposure
• Your agent has moderate performance with occasional strong months
• Your buyers are price-sensitive but open to performance alignment
• You need to cover infrastructure costs regardless of trading performance

For detailed guidance on pricing across all models, see the pricing guide.

Setting Up Your First Revenue-Sharing Agreement

Here is a practical template for structuring your first revenue-sharing arrangement.

Step 1: Define the Terms

# revenue-sharing-terms.yaml
agreement:
  model: "high_water_mark"
  developer_share_pct: 20
  settlement_period: "monthly"
  high_water_mark_reset: "never"  # or "annually"
  minimum_profit_threshold_usd: 500
  maximum_drawdown_pct: 25  # auto-pause trigger

capital:
  initial_deposit_usd: 10000
  additional_deposits: "allowed with HWM adjustment"
  withdrawals: "trigger settlement before withdrawal"

costs_deducted_before_split:
  - "platform trading fees"
  - "gas costs"
  - "slippage above 1%"

costs_not_deducted:
  - "developer infrastructure costs"
  - "buyer's internet or hardware costs"

termination:
  notice_period_days: 30
  upon_termination: "settle all open positions, final settlement"
  non_compete: "none"

Step 2: Set Up Profit Tracking

Deploy one of:

• A smart contract for on-chain platforms (Polymarket)
• Moltbook-verified performance logging for off-chain platforms (Kalshi)
• Both, if the agent trades across platforms

Step 3: Run a Trial Period

Before committing to a long-term arrangement, run a 30-day trial with reduced capital. This lets both parties verify that the tracking, calculation, and settlement processes work correctly before scaling up.

Step 4: Document Everything

Create a shared document (or on-chain record) that includes:

• The complete terms (from Step 1)
• Both parties’ wallet addresses or payment details
• The tracking methodology and data sources
• Contact information and dispute resolution process

Conclusion

Revenue-sharing is not just a pricing model — it is a trust mechanism. By tying your compensation to buyer outcomes, you signal confidence in your agent, lower the buyer’s barrier to entry, and create a relationship where both parties profit from the agent’s success.

The infrastructure to support fair, transparent revenue-sharing is now available. Smart contracts handle automatic splits. Moltbook provides third-party verification. On-chain trading records create immutable audit trails. The technical barriers that made revenue-sharing impractical two years ago are largely solved.

Start with the high-water mark model. It is the industry standard, it is the most buyer-friendly, and it is the simplest to explain. Graduate to more complex models (tiered, hybrid) as you gain experience and your buyer relationships mature.

Further Reading

• 5 Prediction Market Bot Pricing Models — comprehensive comparison of all pricing approaches
• How to Sell Your Prediction Market Bot — the complete guide to monetizing your agent
• The AgentBets Marketplace — where to list and sell revenue-sharing agents
• Legal Guide to Selling AI Agents — licensing, liability, and regulatory considerations
• Moltbook Identity Guide — portable agent identity and verification for trust infrastructure