Base asset legs support in custom strategies

[arshamalh]

Problem

Some Strategies may have a leg of type base asset, currently the package don't support them.
CustomStrategy.positions is a Vector of Positions, and Position.option_style should be either 'call' or 'put'.
How should we have a strategy made up of:

• "buy base asset" (don't exist in this package)
• "sell Call"
• ...

[joaquinbejar]

Hi @arshamalh,

Thanks for raising this! You've identified a real limitation in the current architecture. You're correct that Position currently only supports option contracts (Call/Put), not underlying asset positions.

Current State

The library has placeholder files for strategies that require base asset legs (Covered Call, Protective Put, Collar), but they're not implemented precisely because of this limitation.

Proposed Solution

I see two possible approaches:

Option A: Extend the Position Model

Create a new PositionType enum that can represent both options and underlying assets:

pub enum PositionType {
    Option(Options),
    Underlying {
        symbol: String,
        quantity: Positive,
        price: Positive,
        side: Side,
    },
}

pub struct Position {
    pub position_type: PositionType,
    pub premium: Positive,
    pub date: DateTime<Utc>,
    pub open_fee: Positive,
    pub close_fee: Positive,
    // ...
}

Option B: Separate Leg Types (Recommended)

Create a Leg enum that CustomStrategy uses instead of Vec<Position>. This approach is more extensible and allows for multiple instrument types:

/// Represents different types of legs in a strategy
pub enum Leg {
    /// Standard option position (Call/Put)
    Option(Position),
    /// Spot/underlying asset position (stocks, crypto, forex spot)
    Spot(SpotPosition),
    /// Futures contract position
    Future(FuturePosition),
    /// Contract for Difference position
    Cfd(CfdPosition),
    /// Forward contract position
    Forward(ForwardPosition),
    /// Other derivative types
    Other(GenericPosition),
}

/// Spot/underlying asset position
pub struct SpotPosition {
    pub symbol: String,
    pub quantity: Positive,
    pub cost_basis: Positive,
    pub side: Side,
    pub date: DateTime<Utc>,
    pub fees: Positive,
}

/// Futures contract position
pub struct FuturePosition {
    pub symbol: String,
    pub quantity: Positive,
    pub entry_price: Positive,
    pub side: Side,
    pub expiration_date: ExpirationDate,
    pub contract_size: Positive,
    pub margin: Positive,
    pub date: DateTime<Utc>,
    pub fees: Positive,
}

/// CFD position
pub struct CfdPosition {
    pub symbol: String,
    pub quantity: Positive,
    pub entry_price: Positive,
    pub side: Side,
    pub leverage: Positive,
    pub margin: Positive,
    pub date: DateTime<Utc>,
    pub fees: Positive,
}

Why Option B is Better

1. Extensibility: Easy to add new instrument types (swaps, warrants, perpetuals, etc.)

2. Type safety: Each instrument type has its own struct with relevant fields

3. No breaking changes: Existing Position usage remains intact

4. Proper modeling: Each derivative has different characteristics:

   • Options: strike, expiration, IV, greeks
   • Futures: expiration, contract size, margin
   • CFDs: leverage, margin, no expiration
   • Spot: simplest - just price and quantity

5. Enables complex strategies:

   • Covered Call = Spot + Short Call
   • Futures Spread = Long Future (near) + Short Future (far)
   • Synthetic positions with multiple instrument types

Implementation Roadmap

1. Create base traits for common leg behavior (Profit, Greeks where applicable)
2. Implement SpotPosition first (enables Covered Call, Protective Put, Collar)
3. Add FuturePosition for futures-based strategies
4. Extend as needed for other derivatives

Would you be interested in contributing this feature? If so, I can create a more detailed design spec. Alternatively, I can add this to the roadmap for a future release.

Let me know your thoughts!

Best,
Joaquín