# p0n Strategy Specification

Version: `0.1-draft`

Status: `PAPER / ROBINHOOD MCP SETUP REQUIRED`

This document defines the initial public mandate, decision loop, portfolio constraints, risk policy, execution requirements, and launch conditions for p0n.

## 1. Objective

Increase risk-adjusted PONS inventory over complete trading cycles while:

- preserving sufficient ETH for gas and future accumulation;
- protecting a permanent strategic PONS reserve;
- limiting drawdown and execution risk;
- maintaining a complete public audit trail;
- comparing results against a passive PONS hold benchmark.

The strategy does not optimize exclusively for USD P&L. It evaluates both portfolio value and PONS inventory growth.

## 2. Allowed universe

### Speculative asset

- Name: Pons
- Symbol: `PONS`
- Contract: `0x39dBED3a2bd333467115dE45665cC57F813C4571`
- Network: Robinhood Chain

### Quote and reserve asset

- `ETH` or canonical wrapped ETH used by the approved venue
- ETH exists only as reserve, gas, and consideration for PONS trades

### Forbidden assets and actions

- no other speculative tokens;
- no leverage or margin;
- no lending or borrowing;
- no perpetual futures or options;
- no bridges without an explicit mandate update;
- no approvals to unreviewed contracts;
- no transfers to unpublished wallets;
- no order that cannot be reconciled from the execution venue.

## 3. Portfolio structure

### Strategic core

Default: `70%` of total PONS inventory.

The strategic core cannot be sold by ordinary tactical decisions. It may only change through a versioned mandate update or emergency response approved outside the model.

### Active sleeve

Default: `30%` of total PONS inventory.

The active sleeve may be trimmed into excessive strength and re-accumulated at lower prices. Every sale is capped by both the active-sleeve balance and the maximum-action rule.

### ETH reserve

Default minimum: `0.05 ETH`.

The agent must preserve enough ETH to pay gas and retain optionality. The reserve floor may be increased during high volatility, poor liquidity, or network congestion.

### Maximum action size

Default: `5–10%` of current marked portfolio equity per decision cycle, scaled by confidence.

The risk engine may reduce this amount based on liquidity, slippage, volatility, account restrictions, or recent losses. The model cannot increase it.

## 4. Available decisions

The reasoning layer must return exactly one structured action:

### `BUY_THE_DIP`

An increased but bounded accumulation tranche used during a material drawdown when liquidity and reserve conditions remain acceptable.

### `ACCUMULATE`

A standard PONS purchase when price reaches the configured accumulation zone.

### `DCA`

A scheduled or reserve-balancing purchase that does not depend on a severe market dislocation.

### `TRIM`

A partial sale from the active sleeve during excessive momentum or a defined profit condition. `TRIM` may never consume the strategic core.

### `HOLD`

No order. Used when the expected advantage does not justify fees, slippage, inventory change, or risk.

## 5. Initial signal policy

These are default parameters for the first paper-trading version. They are not permanent truths and are not promises of performance.

| Condition | Candidate action | Default sizing |
| --- | --- | --- |
| 24h change at or below `-15%` | `BUY_THE_DIP` | up to 1.5x standard tranche |
| 24h change at or below `-8%` | `ACCUMULATE` | standard tranche |
| ETH reserve exceeds target and PONS is not overheated | `DCA` | half standard tranche |
| 24h change at or above `+22%` and price is profitable versus basis | `TRIM` | small active-sleeve trim |
| 24h change at or above `+38%` and price is profitable versus basis | `TRIM` | larger active-sleeve trim |
| no asymmetric setup | `HOLD` | zero |

Additional production signals may include:

- multi-window momentum;
- realized and implied volatility;
- liquidity depth;
- recent buy/sell flow;
- price deviation from volume-weighted averages;
- drawdown from local highs;
- cost-basis distance;
- execution slippage estimates;
- PONS-specific news and ecosystem events;
- account-level loss and cooldown state.

No additional signal may expand the allowed asset universe.

## 6. Decision cycle

Each cycle follows this order:

1. Read execution mode and emergency-stop state.
2. Read the dedicated account, balances, positions, open orders, and recent fills.
3. Reconcile local state against the authoritative venue.
4. Read PONS price, volume, liquidity, volatility, and flow.
5. Read approved PONS-specific public information.
6. Produce one structured decision with thesis, confidence, intended size, and invalidation condition.
7. Pass the proposal through deterministic policy.
8. Calculate expected price impact, fees, and post-trade allocation.
9. Preview the order through the execution adapter.
10. Execute only if every policy check passes.
11. Reconcile the resulting order and fill.
12. Publish the decision, rejection or execution, and evidence.

The language model never signs or submits an arbitrary transaction directly.

## 7. Deterministic risk checks

Every proposed order must pass all applicable checks:

- exact PONS contract match;
- approved Robinhood account or Robinhood Chain venue;
- approved quote asset;
- maximum-action limit;
- strategic-core protection;
- minimum ETH reserve;
- minimum and maximum order size;
- liquidity floor;
- maximum estimated price impact;
- maximum slippage;
- trade cooldown;
- daily loss limit;
- drawdown circuit breaker;
- duplicate-order protection;
- stale-data rejection;
- venue response validation;
- emergency stop.

If one check fails, the action is rejected and the reason is added to the public activity log.

## 8. Robinhood Agentic Trading integration

Official Trading MCP endpoint:

`https://agent.robinhood.com/mcp/trading`

Target production architecture:

1. Connect p0n to the official Robinhood Trading MCP.
2. Authenticate through the supported Robinhood authorization flow.
3. Open or select a dedicated Robinhood Agentic Account.
4. Confirm isolated capital and account permissions.
5. Search the available instrument universe for PONS.
6. Validate supported order types and minimum size.
7. Preview a minimum-size PONS order.
8. Execute a controlled test order.
9. Reconcile the order, fill, balances, and activity feed.
10. Enable live status only after verification.

The product may display `ROBINHOOD MCP · INTEGRATED` only when authentication is active and the execution path has been tested successfully.

If the official Trading MCP does not expose PONS, the system must not imply that onchain PONS swaps are brokerage MCP orders.

## 9. Robinhood Chain execution fallback

If required, a separately reviewed onchain adapter may execute PONS/WETH swaps on Robinhood Chain.

Current reference market:

- Pair: `PONS / WETH`
- Pool: `0x10CC6BD38112cAc182db90B6a71d8Bb5939526bA`
- Fee tier observed: `1%`

Before live use, the adapter must verify:

- correct chain ID;
- canonical token addresses;
- approved router and pool;
- allowance boundaries;
- quote freshness;
- minimum received amount;
- deadline;
- slippage protection;
- gas reserve;
- receipt status;
- post-trade balances.

Private keys must be stored in a proper secret manager or secure signer. They must never be committed, placed in dashboard state, logged, or returned through an API.

## 10. Data and research policy

Market decisions must identify the timestamp and source of every critical input.

Data may include:

- Robinhood account data through the official MCP;
- Robinhood Chain RPC and explorer data;
- approved pool quotes and OHLCV data;
- PONS liquidity and transaction flow;
- approved news and public ecosystem information.

Stale or unavailable critical data forces `HOLD`.

Social sentiment may inform a thesis but cannot independently authorize a trade.

## 11. Public activity schema

Each decision record should include:

- timestamp;
- cycle identifier;
- execution mode;
- action;
- confidence;
- thesis;
- market snapshot;
- requested size;
- policy result;
- rejection reason if applicable;
- order preview;
- order identifier;
- transaction hash when onchain;
- executed quantity;
- average fill price;
- fees and slippage;
- post-trade balances;
- post-trade core and active allocation.

Historical records are append-only from the dashboard's perspective.

## 12. Performance accounting

The dashboard should report:

- PONS held;
- ETH reserve;
- PONS value in ETH and USD;
- total portfolio equity;
- average PONS entry;
- realized P&L;
- unrealized P&L;
- contributed and withdrawn capital;
- fees;
- slippage;
- PONS inventory growth;
- completed trading cycles;
- win rate where meaningful;
- maximum drawdown;
- comparison with passive PONS hold.

Deposits are not profit. Withdrawals are not trading losses. Accounting must separate capital flows from strategy performance.

## 13. Emergency controls

The system requires an emergency stop outside the reasoning model.

Activating it must:

- block all new orders;
- preserve read-only monitoring;
- cancel cancellable open orders where authorized;
- publish the stopped state;
- require explicit human action to resume.

Automatic circuit breakers should stop execution after repeated venue errors, stale balances, abnormal slippage, daily loss limit breach, or reconciliation failure.

## 14. Strategy versioning

Every material policy change receives a new version and timestamp.

Material changes include:

- core/active allocation;
- thresholds;
- maximum action size;
- reserve floor;
- model or prompt mandate;
- execution venue;
- risk limits;
- data sources;
- accounting methodology.

Past versions remain available. Historical results must be associated with the policy version that produced them.

## 15. Launch checklist

- [ ] Official Robinhood Trading MCP connected
- [ ] Authentication completed
- [ ] Dedicated Agentic Account identified
- [ ] PONS instrument support confirmed
- [ ] Account capital limit configured
- [ ] Read-only reconciliation tested
- [ ] Order preview tested
- [ ] Minimum-size execution tested
- [ ] Strategic-core protection tested
- [ ] Maximum-action limit tested
- [ ] ETH reserve rule tested
- [ ] Slippage and stale-quote rejection tested
- [ ] Duplicate-order protection tested
- [ ] Emergency stop tested
- [ ] Public audit record verified
- [ ] Capital-flow-adjusted P&L verified
- [ ] Live status enabled

Until every required launch item is complete, p0n remains in `PAPER` or `SETUP REQUIRED` mode.