> For the complete documentation index, see [llms.txt](https://docs.callput.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.callput.app/traders/position-lifecycle.md).

# Position lifecycle

Callput positions follow a request-based lifecycle rather than an instant-fill lifecycle.

## Lifecycle overview

1. create an open request
2. wait in pending state
3. end as executed or cancelled
4. if executed, hold an active position
5. before expiry, create a close request if needed
6. wait in close-pending state
7. end as close-executed or close-cancelled
8. reach expiry
9. settle any remaining position

## Open request

When a user creates an open request:

* the request is registered, not filled
* funding assets enter the request flow
* the request is blocked if expiry is already inside the deadline buffer
* the durable lifecycle identifier is the request key, not the transaction hash

### Pending

The request exists but is not yet final.

### Executed

The position is created and the user receives the corresponding ERC-1155 option position token.

### Cancelled

The request ended without execution.

## Active position

Once the request is executed, the user holds an active position. From that point:

* the position can remain open until expiry
* the user can submit a close request before expiry
* settlement becomes relevant after expiry

## Close request

Closing before expiry requires a new close request.

* the relevant option token amount can move into `PositionManager`
* the close request uses the same asynchronous queue model
* the close request is blocked inside the deadline buffer
* the close request creates its own request key and lifecycle state

### Pending

The close request exists but is not yet final.

### Executed

The close completed successfully and the strategy-specific payout path was finalized.

### Cancelled

The close request ended without execution and the option token amount is returned.

## Expiry and settlement

After expiry, the lifecycle moves from close logic to settlement logic.

Settlement through `SettleManager` requires:

* that the option is expired
* that the user holds the relevant `optionTokenId` balance

## How to determine the current state

The most reliable order is:

1. check whether a request key exists
2. read the request status from `PositionManager`
3. read the option token balance
4. check whether expiry has passed

The transaction hash alone is not enough to determine the lifecycle state.

## Key constraints

* `Cancelled` is not documented as a generic user cancel action
* the pre-expiry deadline buffer applies to both open and close requests
* request validity is limited by the current `maxTimeDelay`