Portfolio Strategies

Portfolio Strategies lets platforms offer multi-asset baskets to end users without building the orchestration, credit-check, or execution layer in-house. A platform defines a Strategy (a basket scoped to a quoted_currency), enrolls participants with a fiat amount, and zerohash creates a Trader per participant, prices each leg, and settles every Execution atomically.

Common use cases include curated multi-asset portfolios (e.g., 50% BTC / 30% ETH / 20% SOL), thematic baskets and index products, copy-trading style portfolios that mirror a strategist's allocation, and batch onboarding or liquidation of large user cohorts in a single call.

Key Endpoints

  • POST /strategies — Create a Strategy scoped to a quoted_currency. Store the returned id; every subsequent call references it.
  • POST /strategies/{strategy_id}/enroll — Create Traders and place initial buys. Supply allocations (weights summing to 1.00) and participants (participant_code, amount, auto_rebalance).
  • POST /strategies/{strategy_id}/top-up — Add fiat to existing Traders. Same shape as enroll.
  • POST /strategies/{strategy_id}/partial-sell — Return a fiat amount to participants, sized proportionally to the supplied allocations.
  • POST /strategies/{strategy_id}/rebalance — Re-align Traders to new weights. Omit participants to target every Trader with auto_rebalance = true; provide it to override.
  • POST /strategies/{strategy_id}/liquidate — Fully exit the listed Traders. No buy leg, ignores auto_rebalance.
  • PATCH /strategies/traders/{trader_id} — Update a Trader's auto_rebalance flag.

Best Practices

  • Idempotency: Every mutation requires an X-REQUEST-ID header (UUID v4). Reuse only when retrying the same call; zerohash returns the existing Operation rather than creating a duplicate.
  • Treasury management: For platforms on the novated funding model, keep the platform float account funded before enrollment and top-up calls.
  • Atomic execution: zerohash validates every Trader across every leg before any trade fires. One Trader's rejection does not cascade to the others.
  • Uniform pricing: Within an Operation, each asset locks one customer price for all in-scope Traders.
  • Audit trails: Log every request_id, Operation id, Execution id, and trade_ids[] for reconciliation against your internal participant ledgers.
  • No reversals: Once an Operation reaches settled, the resulting trades are final.