Skip to main content

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:
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