> For the complete documentation index, see [llms.txt](https://nexon-3.gitbook.io/nexon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nexon-3.gitbook.io/nexon-docs/part-iv-products/04-product-stack/payfi.md).

# AI-Native PayFi

AI-Native PayFi is NEXON's Value Router — a controlled route from financial intent to digital and real-world execution, already delivered and running.

*Product stage · Live · Product role · Value Router*

AI-Native PayFi is the clearest product expression of the value-connection thesis. It starts from the outcome a user wants and turns it into a visible sequence:

**Intent → Route → Policy Check → User Approval → Execution → Receipt.**

It can coordinate supported financial and consumption actions while every venue, custodian, issuer and supplier stays responsible for its own leg.

It is "AI-native" because **meaning comes before the menu**. It is PayFi because financial state and payment or use are considered inside one controlled journey.

## Six steps, unpacked

{% tabs %}
{% tab title="1 · Capture the goal" %}
The user states the outcome, budget, deadline, eligible balances, protected reserves, cost limits and approval preference. Natural language is good at getting all of that out in one breath.

The application turns it into a structured intent and surfaces whatever is ambiguous. For an unsupported or ineligible request, it returns an explanation — **not a simulated success**.
{% endtab %}

{% tab title="2 · Preview the route" %}
PayFi proposes one or more eligible routes and **moves nothing**. The preview separates every leg:

* source asset and destination;
* amount, quote, estimated cost and expiry;
* the venue, contract, issuer or supplier responsible;
* identity and jurisdiction requirements;
* permissions to be granted;
* which steps are irreversible and which depend on a refund;
* the settlement and fulfillment receipts to expect;
* behavior if price, balance, inventory or policy changes.

Comparisons follow the user's constraints. Any routing incentive that could affect ordering or recommendation must be disclosed.
{% endtab %}

{% tab title="3 · Apply policy checks" %}
Hard controls sit outside model judgment: account status, identity references, allowlists, blocklists, spend limits, quote freshness, reserve floors and each product's own rules. **A high confidence score does not override a failed rule.**

Where a current Staking Platform order is involved, PayFi can explain and validate the deposit split: 28% buys EXON at 1 USDT each into the fuel wallet, and the rest is swapped into XO and staked. The product interface does not alter these values and does not present the fuel purchase as a fee.
{% endtab %}

{% tab title="4 · Request scoped authority" %}
Approval names the action, maximum amount, asset, destination, executor, expiry and the follow-on legs permitted. Unused authority is revocable before it is consumed. A standing rule needs its own amount and time ceilings and an obvious off switch.

**XO and EXON balances give PayFi no standing authority.** Account permission comes from the user and the responsible execution system.
{% endtab %}

{% tab title="5 · Coordinate execution" %}
PayFi sends only the approved instruction to each executor, and re-checks dependencies before proceeding. A conversion may settle at a venue, an on-chain transfer on a network, a merchant order only on supplier confirmation.

**The application presents one route and never labels "submitted" as "completed."** If a quote expires, it re-prices and asks again. If a balance changes, it recalculates rather than quietly substituting another asset. If the first leg settles and a later one fails, it stops, preserves the partial state, and enters the disclosed refund, offset or dispute path.
{% endtab %}

{% tab title="6 · Produce receipts" %}
A route receipt answers six questions: **what was requested, what was approved, who executed each leg, what settled, what was fulfilled, and what is still open.** Native identifiers and timestamps keep the account auditable.

Receipts are also the feedback edge of the loop: the Wallet can use authorized history to improve future policy and warnings, and the user can choose to share selected outcomes into Social. **Financial and identity data stay private by default.**
{% endtab %}
{% endtabs %}

## Product economics belong to the product

The approved Tokenomics defines the Staking Platform's economics — not the economics of every future PayFi route. PayFi fees, spreads, payment assets, issuer charges, merchant costs and refund terms, where they exist, are stated in the relevant product terms before execution.

AI does not generate staking yield either. The per-settlement yield, term bonuses, settlement cycle, exit window, referral and leadership rewards and withdrawal burns are mechanism parameters applied by the Staking Platform. **A PayFi simulation reproduces those parameters and names the assumptions it used.**

## Safety and accountability

The product needs, at minimum: least-privilege permissions, simulation, quote expiry, deterministic policy checks, revocation, transaction limits, provider allowlists, anomaly detection, duplicate-execution protection, auditable receipts and an incident escalation path. **Prompts and hidden reasoning are not a substitute for any of these.**

The responsible party stays visible for every leg: PayFi coordinates; the venue settles; the custodian controls assets under its own terms; the issuer authorizes a card transaction; the merchant or travel supplier fulfills. **A route whose responsible party cannot be named should not be presented as ready to walk.**

*Previous:* [*Decentralized Social App*](/nexon-docs/part-iv-products/04-product-stack/social.md) *· Next:* [*Wallet*](/nexon-docs/part-iv-products/04-product-stack/wallet.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://nexon-3.gitbook.io/nexon-docs/part-iv-products/04-product-stack/payfi.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.