# Offerings and subscriptions (/docs/tokenization/offerings)



## What an offering adds [#what-an-offering-adds]

An offering organizes the process of acquiring tokens from an issuer. It connects an allocation to an investor, the required agreement, payment instructions, and delivery. It is separate from creating the token suite.

Offerings support fixed-price issuance and fund subscriptions priced at [net asset value (NAV)](/docs/resources/glossary#nav). Fixed-price offerings use a subscription window and soft/hard caps. NAV subscriptions are open-ended, without a subscription window or soft-cap close test; an optional hard cap can limit reservations. The issuer publishes the NAV used to strike units at acceptance. Fund redemption is outside this subscription flow.

## The subscription journey [#the-subscription-journey]

1. The investor requests an allocation or subscription amount.
2. The required agreement and supporting documents are collected.
3. The issuer reviews and accepts or rejects the subscription.
4. The investor follows the selected payment instructions.
5. Payment is confirmed through the applicable rail.
6. Where a signed agreement is required, the issuer supplies the countersigned agreement before settlement.
7. Tokens are delivered to the investor's admitted, eligible wallet.

Platform eligibility can allow a subscription to begin, but suite admission is required by delivery. An allocation, payment, and delivered balance are separate states.

## Offering progression [#offering-progression]

<div className="flow-diagram" role="group" aria-label="Offering and subscription progression">
  1. **Draft → open:** the issuer sets terms, payment mode, and capacity before opening.
  2. **Open ⇄ filled:** subscriptions reserve capacity; eligible releases can reopen room. Each subscription still needs acceptance and any required agreement.
  3. **Close decision:** a fixed-price offering succeeds or fails its soft-cap test. Cancellation or suspension can interrupt progress; open-ended NAV offerings follow their own mode.
  4. **Payment and delivery:** accepted subscriptions complete payment, required countersigning, and delivery. Failed or cancelled paid subscriptions follow the applicable refund path.
</div>

## Payment modes [#payment-modes]

Fixed-price reservations are first come, first served. Released reservations can reopen capacity while the subscription window remains open. The implementation's default payment window is **seven days**; use the offering's actual terms for the deadline. Each crypto offering selects **one** supported stablecoin. These are application rules, separate from gas fees.

The configured NAV staleness threshold was **one day** on testnet on 17 September 2026; the source default is **30 days**. A stale NAV requires explicit issuer confirmation in the supported acceptance flow. Read `navStalenessDays` from [configuration discovery](/docs/tokenization/integration#discover-testnet-configuration), rather than assuming the default applies.

| Mode          | How payment is recorded                                                                               |
| ------------- | ----------------------------------------------------------------------------------------------------- |
| Bank transfer | The investor pays the issuer outside the chain; the issuer matches the reference and confirms receipt |
| Stablecoin    | The investor makes an authorized deposit into the offering's escrow contract, where enabled           |
| Mixed         | Both rails are offered while allocations share the offering's capacity                                |

Uploading bank-payment evidence does not verify receipt. The issuer performs that confirmation. A direct stablecoin transfer to an arbitrary address is not a substitute for the authorized escrow deposit: payment must be associated with the accepted subscription.

The escrow holds the payment asset. The security token is delivered directly to the investor's asset wallet, rather than being held by the escrow as an intermediate token holder.

## Completion, cancellation, and refunds [#completion-cancellation-and-refunds]

Subscription windows, payment deadlines, funding targets, and issuer decisions affect whether an offering completes. A failed or cancelled allocation can enter a refund process if payment has already occurred. Bank refunds remain outside the chain; escrow refunds follow the contract's permitted states and conditions.

A recorded refund requirement is not the same as a completed refund. The applicable payment record and transaction result establish which stage has been reached.

An escrow's refund escape depends on its configured settlement window and offering mode: windowed offerings use their effective close, while rolling offerings use the individual deposit time. Read the deployed escrow terms; “14 days after payment” is not a universal rule.

## Example: subscribe for 100 bond tokens [#example-subscribe-for-100-bond-tokens]

Assume a fixed price of **$100 per token**, an open offering with sufficient capacity, a required agreement, a seven-day payment window, and bank-transfer settlement. These are example terms, not an available investment.

1. An investor requests **100 tokens*&#x2A;, reserving an allocation priced at **$10,000**.
2. The investor supplies the signed agreement; the issuer accepts the subscription. The investor follows its actual payment deadline and reference instructions.
3. The investor pays $10,000 by bank transfer. An uploaded receipt is supporting evidence; the issuer must confirm receipt.
4. The issuer supplies the countersigned agreement and completes suite admission before delivery. Any required offering-close condition must also be satisfied.
5. The authorized delivery transaction puts 100 tokens in the investor's eligible wallet. The platform then waits for confirmation and indexed display.

If the offering fails or the accepted subscription is cancelled after payment, the subscription enters the refund process. A refund status alone does not prove money has returned to the investor. Platform fees, if applicable, follow the offering terms; wallet-signed transactions additionally need ASSET gas.

## Fee terms [#fee-terms]

The launch design specifies zero primary and secondary platform fees, but current fee configuration was not independently read for this edition. Review the offering's fee terms and the signed secondary-market quote. The platform can change its runtime secondary fee policy; a historical launch value is not a permanent fee commitment. Gas is paid separately in ASSET.

## Testnet availability [#testnet-availability]

Public configuration reported stablecoin settlement enabled on 17 September 2026. Read the current [feature flags](/docs/tokenization/integration#discover-testnet-configuration) and the offering terms before using a payment rail. [Security and audits](/docs/resources/security-and-audits) records the separate audit-evidence limits.