> ## Documentation Index
> Fetch the complete documentation index at: https://api-docs.nexbridge.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Operational Rules

# Operational Rules

This section describes the operational behavior and lifecycle assumptions partners should consider when integrating with the Nexbridge Partner API.

***

# Approved Addresses Only

Only approved addresses may participate in settlement flows.

Requests referencing:

* pending addresses
* inactive addresses
* unsupported addresses

are rejected operationally.

***

# Single Active USDT Address

Only one active USDT payout address is supported at a time.

This restriction applies to automated payout operations.

Partners should avoid deleting active addresses before replacement approval is completed.

***

# Quote Expiration

Quotes are time-limited.

Expired quotes:

* cannot create requests
* cannot be reactivated
* cannot be reused

Partners should create requests immediately after obtaining a quote.

***

# Single Quote Usage

Quotes may only be consumed once.

A consumed quote cannot be reused for additional requests.

***

# Partial Funding

Requests support partial funding.

As a result:

* multiple funding events may fund one request
* one funding event may contribute to multiple requests

***

# Funding Validation

Funding must:

* match the expected asset
* originate from approved sources
* satisfy operational validation rules

Funding failing validation transitions to:

```text theme={null}
DIRTY
```

Dirty funding cannot participate in settlement flows.

***

# Asynchronous Settlement

Request processing and settlement are asynchronous.

Request fulfillment timing may vary depending on:

* funding timing
* operational validation
* settlement lifecycle

Partners should monitor request status continuously.

***

# Request Cancellation

Requests may only be cancelled while still operationally pending.

Completed or fulfilled requests cannot be cancelled.

***

# Balance Lifecycle

Balances evolve dynamically depending on:

* funding reception
* allocation
* settlement completion
* request lifecycle

Balances may transition between:

* available
* allocated
* dirty
* consumed

***

# Precision Rules

## USTBL

Supports up to 6 decimals.

***

## USDT

Supports up to 2 decimals.

***

# Operational Traceability

All operational lifecycle transitions are internally traced for:

* requests
* funding activity
* balance movements
* settlement operations

***

# Idempotency Recommendation

Partners should implement idempotent request handling on their side.

This helps prevent duplicated operational requests caused by:

* retries
* network failures
* timeout scenarios

***

# Unsupported Operations

The following operations are not available in V1:

* manual balance adjustments
* partner treasury operations
* manual funding reassignment
* partner-triggered settlements
* webhook notifications
* self-service onboarding

***

# Best Practices

Partners are encouraged to:

* monitor request statuses continuously
* avoid reusing expired quotes
* validate operational addresses before usage
* rotate payout addresses carefully
* implement retry and reconciliation logic