Pretrend Whitepaper

1. Executive Summary

Pretrend is a trend-based oracle protocol that enables prediction markets to resolve based on directional movement rather than binary yes/no outcomes. Pretrend operates two independent products. The Oracle is data feed infrastructure on the Vitruveo blockchain: customers onboard time-series feeds whose values are written to smart contract storage, where native precompiled contracts perform on-chain trend computation. The Marketplace is a prediction market system that consumes Oracle feeds and operates on external chains such as BSC; Pretrend runs it as a hosted multi-tenant business, and the same software is open source and serves as the reference implementation for independent deployments.

Unlike traditional prediction markets where users bet on whether a specific event will occur, Pretrend markets allow users to predict the magnitude and direction of change in any time-series data. Users purchase units in one of five outcome buckets representing different trend intensities, from significant decline to significant growth.

The protocol prices units on a Timeslope: every bucket climbs from $0.10 at open to $1.00 at the participation close, accelerated by demand, so earlier participants receive more units per dollar and better returns when they pick the winning bucket. Winners split the market bounty in proportion to units held. A notary service fetches external data and writes verified trend calculations on-chain. All payment and betting is denominated in USDT.b, bridged in-app.

2. Problem Statement

2.1 Limitations of Binary Markets

Current prediction markets force complex, continuous phenomena into binary outcomes. A market asking whether Bitcoin will reach $100,000 by a certain date loses all nuance about price movement. If Bitcoin rises from $60,000 to $99,000, participants who bet on growth receive nothing despite being directionally correct.

This binary constraint creates several problems. First, markets cannot capture the magnitude of movement, only whether a threshold was crossed. Second, setting thresholds is arbitrary and can make markets unbalanced from inception. Third, near-miss outcomes feel punitive to participants who correctly predicted direction but not magnitude.

2.2 The Trend Alternative

Real-world data moves continuously. Prices drift, metrics fluctuate, engagement rises and falls. A prediction system that captures directional movement and magnitude provides richer market dynamics and fairer outcomes.

Pretrend resolves this by computing the trend slope over a defined time period using linear regression. The result is a percentage change that maps to one of five outcome buckets, each representing a range of possible movements calibrated to the specific data source.

3. System Architecture

The protocol consists of three primary components: the Vitruveo Oracle, the Notary Service, and the Marketplace Layer. Each component has distinct responsibilities and interfaces. The Oracle and the Marketplace are independent products: the Oracle serves data feeds to any consumer, and the Marketplace is one such consumer.

3.1 Component Overview

3.2 Data Flow

When a market is created, the Notary fetches historical data for the specified data source and calls the trend precompile to compute bucket thresholds based on historical volatility quintiles. These thresholds are written to the Oracle contract along with the baseline trend value.

During the active market period, the Notary fetches data at the resolution interval defined by the data source, computes the current trend via the precompile, and updates the Oracle contract. Multiple markets sharing the same data source receive the same update in a single fetch operation.

When the market duration expires, the final trend value determines the winning bucket. The Oracle uses the HOST protocol to push the resolution to marketplace contracts on external chains, triggering the payout process.

4. Oracle Specification

4.1 Trend Precompile

The Vitruveo blockchain includes a native precompiled contract for trend computation. This precompile accepts time-series data as input and returns statistical measures without requiring expensive on-chain computation via the EVM.

Mode 1: Full Analysis — Given a series of timestamp-value pairs, the precompile computes three values: the slope percentage representing the fitted trend change from start to end of the series, the R-squared value indicating confidence in the linear fit, and the volatility measure computed as sample standard deviation.

Mode 2: Volatility Buckets — Given historical data and a window size, the precompile computes quintile thresholds for bucket boundaries. It calculates the absolute percentage change for every rolling window in the data, sorts these deltas, and returns the 20th, 40th, 60th, and 80th percentile values.

4.2 Data Source Registry

4.3 Feed Onboarding, Storage, and Billing

Each data feed is onboarded for a one-time fee. Feeds support update frequencies from 5 seconds to 1 hour. Every feed value is stored in the Pretrend database, and the feed is written to smart contract storage every 15 minutes; for markets longer than one hour, the write frequency may be reduced to a minimum of once per hour.

Feed customers maintain a USDT.b balance with the Oracle. Each write to smart contract storage draws $0.30 from this balance. On the hosted Marketplace, the feed write frequency must match the market period: a 30-minute market may use 15- or 30-minute writes, but not 45- or 60-minute writes.

5. Pricing Model: Timeslope

Pretrend prices units on a Timeslope: every bucket starts at $0.10 when a market opens and reaches $1.00 at the participation close, which occurs at 80% of the market duration. A dime buys ten units at the open; a dollar buys one unit at the close. Two forces move the price along that path:

Time. The rate r = $0.90 / participation window is identical for every bucket and displayed alongside the market in adaptive units (for a 30-minute market, +0.062¢ per second; for a 24-hour market, +0.078¢ per minute). Time alone carries every bucket to $1.00 by the close, even one nobody has purchased.

Demand. Each purchase adds units to its bucket and pushes the price further along the path, in the manner of an automated market maker: the first units move the price fastest, and large orders fill stepwise at progressively higher prices, paying a volume-weighted average rather than the posted price. The depth parameter is configured per data source and controls how strongly demand accelerates a bucket.

5.1 Participation Close and Reveal

At 80% of the market duration — a systemwide configuration — three things happen at once: every bucket's price reaches $1.00, no further purchases are accepted, and the trend line becomes visible. The final 20% of the market runs with all positions locked. Participants watch the trend complete; nothing can be added or withdrawn. Once made, a position cannot be sold or exited — commitment under uncertainty is part of the design.

5.2 Implications

Earlier is structurally better. A dollar at the open buys ten times the units of a dollar at the close. Since winners split the bounty in proportion to units held, identical stakes earn very different returns depending on when they were committed. This is deliberate: as a market progresses, its data accumulates and its outcome grows easier to estimate, and the rising price is the fee for that accumulating information.

Late certainty is worthless. Near the close, even a participant who has computed the trend precisely pays almost exactly one dollar per unit — the price at which near-certain knowledge earns nearly nothing. This holds in thin markets too, because the time component rises whether or not anyone else has participated; there is never a bucket that is both obvious and cheap.

Size pays for impact. Because the demand component is driven by units rather than dollars, and early dollars buy more units, early conviction moves a bucket's price hardest. A large order placed late moves it least — and fills at a premium to the posted price as it walks up its own curve.

Prices are not probabilities. All buckets converge to $1.00 at the close regardless of demand, so the absolute price level encodes elapsed time. Relative sentiment is read from the spread between buckets mid-market — a bucket ahead of the shared time schedule is one the crowd favors — and from each bucket's displayed unit count.

No order book is required. The price is a deterministic, posted function of the clock and each bucket's units; every purchase fills immediately at a computable price. As in pari-mutuel systems, collective opinion expresses itself in the final division of the bounty rather than in bid-ask negotiation. There are no resting orders, no market makers, and no liquidity requirement for a market to function.

5.3 Parameters

6. Marketplace Specification

6.1 Unit Purchases

Users purchase units by specifying the market, bucket (0-4), and amount. All purchases are made in USDT.b, bridged in-app; users pay no per-trade fee. The current Timeslope price (Section 5) determines units received; the purchase updates the bucket's unit count and bounty and records the user's holdings. Purchases are accepted only until the participation close at 80% of the market duration.

6.2 Peer-to-Peer Transfers

Users may transfer units to other users at the current market price. When Alice sells 100 Bull units to Leo, Leo pays Alice at the current Bull price. The market state remains unchanged: same total units, same bounty, same prices. Only ownership moves.

6.3 Outcome Buckets

6.4 Market Lifecycle

6.5 Resolution and Payout

When the market period ends, the market enters the Completed state. The winning bucket is determined by comparing the final trend value to the bucket thresholds; once the result is certified and logged on-chain, the market becomes Resolved. The 2.75% protocol fee is deducted from the bounty in-contract, then the remaining bounty is distributed proportionally:

Unclaimed bounty and carryover. If the winning bucket holds no units, the market still resolves normally, but its bounty is not distributed: it carries over, in full and without any fee, into the next market on the same data source. Carryovers accumulate across consecutive unclaimed markets and are displayed on the following market from the moment it opens. At the first market that produces winners, the distributable pool is the combined amount:

The protocol fee is charged once, against the combined pool, and the carryover resets to zero. The carryover is otherwise inert—a single accumulating balance per source that no other part of the protocol reads. If a data source is retired with an outstanding carryover, the balance passes to the protocol treasury and the transfer is disclosed in the source's final settlement record.

6.6 Trend Visibility

The trend line becomes visible at the participation close — 80% of the market period — at the same moment purchases stop and prices reach $1.00. While participation is open, users analyze the underlying data source themselves rather than reacting to a displayed trajectory, which keeps positions meaningful; once the trend appears, no one can act on it. The final 20% of the market is a locked run-out in which the visible trend completes and the outcome settles.

The displayed chart includes a lead-in of pre-market feed data equal to 50% of the market duration, rounded to the feed write cadence (minimum one write interval). The lead-in is rendered visually distinct and exists for context only: the scored OLS window is strictly the market period, so no pre-market movement affects resolution.

7. Fee Structure

7.1 Oracle Fees

Oracle customers pay a one-time onboarding fee per data feed. Ongoing costs are usage-based: each write to smart contract storage draws $0.30 from the customer's USDT.b balance.

The minimum Oracle cost per customer is $216 per month.

7.2 Marketplace Fees

Users pay no per-trade fee. The only protocol fee is 2.75% of the distributed bounty—including any accumulated carryover (Section 6.5)—deducted at resolution and split as follows. Markets whose bounty carries over pay no fee:

Market creator revenue share comes out of the customer's 0.50% share. It is configurable by the customer and split on-contract according to the configured value.

Onboarding to the hosted multi-tenant marketplace requires a small one-time fee, which deters spam. All fees are denominated in USDT.b.

8. Cross-Chain Resolution

The Oracle lives on Vitruveo while marketplaces operate on external chains. Resolution data flows via the HOST (HTTP Outbound Service Trigger) protocol.

When a market resolves, the Oracle contract triggers a HOST call that pushes the resolution data to marketplace contracts on supported chains. The HOST payload includes market ID, final trend value, winning bucket index, and a cryptographic signature. The receiving marketplace contract verifies the signature before processing payouts.

At launch, BSC is the primary marketplace chain. Additional EVM-compatible chains can be added by deploying marketplace contracts and registering them with the Oracle.

9. Data Sources

9.1 Provider Architecture

A provider is a self-contained code module responsible for fetching data from an external source and returning normalized time-series data. Each provider exposes a standard interface: given a time range, return an array of timestamp-value pairs.

9.2 Source Categories

Feeds update at frequencies from 5 seconds to 1 hour; slower-moving sources use the maximum 1-hour interval.

10. Marketplace Variants

10.1 Hosted Multi-Tenant Marketplace

The Pretrend marketplace is a Pretrend business. It is multi-tenant and available to anyone for a small onboarding fee, which deters spam. Tenants (customers) get custom branding and domain, optional source filtering (crypto-only, sports-only, etc.), and access to the shared Oracle and resolution infrastructure. Customers receive 0.50% of every bounty resolved on their marketplace and may configure a market creator revenue share out of that portion.

10.2 Open-Source Reference Implementation

The marketplace is open source and serves as the reference implementation of the protocol. It can be forked or run independently. Self-hosted deployments do not use Pretrend's contracts: operators deploy and manage their own contracts and subscribe to the Oracle for feed data. The repository includes React components for market display, contract ABIs, integration examples, and documentation for Oracle queries.

11. Security Considerations

Oracle Trust Model: The Notary is operated by Pretrend. Trust is mitigated by deterministic precompile computation (anyone can verify), signed on-chain submissions creating auditable history, and public APIs that can be independently queried.

Data Source Manipulation: OLS regression dampens outlier effects. Resolution intervals prevent flash manipulation. Multiple data points over market duration provide redundancy.

Smart Contract Risks: Mitigated via comprehensive testing, third-party audits, upgradeable proxy contracts, and timelocks on administrative functions.

Cross-Chain Risks: HOST failures are handled via retry with exponential backoff and fallback manual submission with signature verification.

12. Void Conditions

Automatic Void Triggers: Market receives fewer than 80% of expected updates, data source becomes unavailable during market period, or Notary fails to submit resolution within 24 hours of market end.

Manual Void: Evidence of data source manipulation, critical bug affecting fairness, or force majeure events.

Refund Process: Infrastructure costs already incurred are deducted first. The remaining bounty is distributed proportionally based on total unit purchases across all buckets. Onboarding fees are not refunded.

13. Glossary

14. AI Notary Service

The Notary service is powered by AI, providing intelligent assistance throughout the market lifecycle.

14.1 Market Insights

During active markets, the AI generates natural language summaries of trend movements, helping participants understand what's happening without interpreting raw numbers. As money flows into different buckets, it explains probability shifts and what they signal about crowd sentiment. After resolution, it provides analysis of what drove the outcome, connecting trend movements to real-world events.

14.2 Market Creation Assistant

When creating a market, the AI recommends optimal duration based on the data source's characteristics and historical volatility patterns. It suggests an appropriate depth parameter based on expected volume. It warns creators about potential issues such as low-liquidity data sources or unusual volatility periods. Before a market goes live, creators can preview the computed bucket thresholds and adjust parameters if needed.

Appendix A: Example Market

A 24-hour BTC price trend market illustrates the complete lifecycle.

A.1 Market Creation

Creator specifies BTC-USD data source, start time at midnight UTC, duration of 86,400 seconds. Notary fetches 30 days historical data, computes bucket thresholds via Mode 2: -8.2% (Crash/Bear), -2.1% (Bear/Flat), +2.3% (Flat/Bull), +9.1% (Bull/Moon). Baseline trend: +0.4%.

A.2 Active Period

All purchases are made in USDT.b. Every bucket opens at $0.10 and climbs toward $1.00 at the participation close, 19:12 into the market (80%); the trend line stays hidden until that moment. Prices below are volume-weighted fill averages under the Timeslope (depth 2,000).

A.3 Resolution

Final trend: +5.8% (Bull bucket wins). Bounty: $925. The 2.75% fee ($25.44) is split in-contract: $18.50 to Pretrend (2.00%), $4.63 to the customer (0.50%), $2.31 to stakers (0.25%). Distributable bounty: $899.56.

The Timeslope makes timing legible in the returns: Alice's 30th-minute conviction earns 4.78x, Carol's third-hour entry 2.32x, Frank's midday entry 1.13x, and Henry—paying the full $1.00 near the close—roughly breaks even at 1.02x despite picking the winner. Bob, Dan, Eve, and Grace receive nothing; their $550 forms the winners' bounty.

Appendix B: Live Market Example (BTC, 30 Minutes)

This example replays real Binance BTCUSDT data, not hypothetical numbers. The market runs 30 minutes, from 17:00 to 17:30 UTC on July 12, 2026, with a 15-minute lead-in and 1-minute feed closes. Bucket thresholds were computed the way the Oracle computes them: signed quintiles of rolling 30-minute OLS trends over the prior 30 days of 5-minute data. Alongside the chart, the AI market insight commentary (Section 14.1) updates as the market progresses.

Note how narrow the bands are at this duration: the Flat bucket spans just -0.055% to +0.051%. Each bucket is calibrated to win roughly 20% of the time, and this market resolved Flat because the final fitted trend sat inside the middle band. Short crypto markets are decided by fractions of a percent, which is why feed granularity (Section 4) and a single canonical data source per market matter.