feat(polymarket): add maker_side and taker_side to market_trades

[los-xyz]

Summary

Adds maker_side and taker_side ('BUY' / 'SELL', always opposite) to polymarket_polygon.market_trades. Requested by BAM (CUR2-2551) to reconstruct wallet positions over time. The Polymarket /trades API exposes a per-wallet side; this surfaces the same semantic at the spell layer so consumers don't have to scrape or maintain their own derivation.

Derivation

• V1 (CTFExchange_evt_OrderFilled + NegRiskCtfExchange_evt_OrderFilled): makerAssetId = 0 means the maker paid USDC for outcome tokens, so maker_side = 'BUY' (otherwise 'SELL').
• V2 (polymarket_v2_polygon.CTFExchange_evt_OrderFilled): the event carries an explicit side enum, 0 = BUY, 1 = SELL.
• taker_side is the inverse of maker_side by construction.

Usage

select asset_id, shares,
  case when maker = :wallet then maker_side
       when taker = :wallet then taker_side end as side_for_wallet
from polymarket_polygon.market_trades
where (maker = :wallet or taker = :wallet);

BUY => +shares, SELL => -shares. No inversion CASE required.

Verification

• Tier 1: uv run dbt --warn-error compile --select polymarket_polygon_market_trades polymarket_polygon_market_trades_raw clean.

• Tier 2 invariants on 194M production rows (last 30 days):

  Contract Version	Rows	NULL maker	NULL taker	Invalid value	Non-opposite
  V1	2,818,476	0	0	0	0
  V2	191,326,847	0	0	0	0

• Both branches fire on every source (24h window):

  Source	maker BUY	maker SELL
  V1 CTFExchange	5,898,513	929,211
  V1 NegRiskCtfExchange	1,010,306	512,634
  V2 CTFExchange	5,410,796	940,707

• Cross-platform check against the Polymarket /trades API: 8 distinct tx_hashes / 10 OrderFilled events for a sample wallet, 10/10 match between our derived (maker_side, taker_side) and the API's side. Two trades emit both legs and the derivation produces the correct side for the wallet on each leg.

Note on observed distribution: maker_side skews ~85% BUY on production data. This is genuine Polymarket microstructure (LP rewards favor bid posting; position opens often go via PositionSplit minting rather than the orderbook; sells tend to sweep multiple resting bids). Not a derivation artifact; verified by independently filtering each is_taker_side leg.

Tests

not_null + accepted_values(['BUY','SELL']) on both columns. Existing is_taker_side unchanged.

Test plan

• dbt compile
• Dune MCP invariant + distribution check
• Row-for-row validation against Polymarket /trades API
• CI: dbt slim ci
• After merge: full refresh of market_trades_raw + market_trades, then notify BAM in the existing email thread to validate against their Snowflake share

Linear

CUR2-2551

[cursor]

PR Summary

Low Risk
Additive spell columns with documented derivation and dbt value tests; no changes to keys, volume logic, or is_taker_side.

Overview
Adds maker_side and taker_side (BUY / SELL, always opposite) to the Polymarket Polygon market_trades spell so consumers can attribute buy/sell per wallet without re-deriving from on-chain fields.

Derivation is implemented in polymarket_polygon_market_trades_raw for all three CLOB sources: V1 CTF and NegRisk use makerAssetId = 0 as maker buying outcome tokens; V2 uses the event side enum (0 = BUY). polymarket_polygon_market_trades passes the columns through on incremental and full builds. _schema.yml documents the semantics and adds not_null plus accepted_values tests on both columns; is_taker_side is unchanged.

^{Reviewed by Cursor Bugbot for commit 1d1bebd. Configure here.}

[los-xyz]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 1d1bebd. Configure here.}