AI Link Technical Deep Dive

This page is a technical deep dive into AI Link, written for partners doing architecture and security due diligence (e.g., exchanges, L2s, infrastructure teams). It explains design choices, trust boundaries, execution semantics, and how the system behaves under failure.

Note: This page describes the current production-intent design and v1 behavior. Some parameters (timeouts, fee constants, chain support) may evolve as AI Link iterates.

---

Deep questions and direct answers

1) What are the trust boundaries?

AI Link has three primary trust boundaries:

1. Origin chain (partner ecosystem) Where users and applications live, sign requests, and expect chain-native activity.

2. AI Link service (cross-chain gateway) Watches/accepts requests, validates authentication, orchestrates execution, and coordinates settlement. This layer should be treated as a system component that is observable and auditable, not a “black box API.”

3. Nesa execution and accounting layer Runs inference and produces measurable costs for settlement.

Design intent: AI Link should not require partners to trust a single “AI provider” with plaintext inputs or opaque accounting. Instead, partners should be able to reason about request states, settlement rules, and failure outcomes deterministically.

---

2) Why is AI Link asynchronous?

AI inference latency is not comparable to blockchain transaction latency. AI Link is therefore asynchronous-by-design:

• requests are accepted and acknowledged quickly

• execution proceeds independently

• applications poll for status and retrieve results when ready

This avoids failure modes common in synchronous cross-chain designs:

• origin chain congestion and blocked user flows

• large capital lockups while waiting for long-running inference

• difficult rollback semantics when any step fails mid-flight

Asynchrony is also what makes AI Link practical for exchanges: it avoids coupling inference timing to the transaction confirmation timing of any single chain.

The following pseudocode is illustrative. It omits implementation details and focuses on execution semantics, trust boundaries, and ordering guarantees.

function submitRequest(request):
    assert verifySignature(request)
    assert depositBalance(request.user) >= MIN_DEPOSIT

    recordOnChain(request.id, request.metadata)

    enqueueExecution(request.id)
    return ACKNOWLEDGED
    
worker executeRequest(requestId):
    updateState(requestId, PROCESSING)

    result, cost = runInference(requestId)

    if result.success:
        updateState(requestId, COMPLETED)
        settleCost(requestId, cost)
    else:
        updateState(requestId, FAILED)

From an implementation perspective, asynchrony is enforced at the system boundary rather than treated as a retry mechanism. Once a request is accepted and authenticated, downstream execution proceeds independently of origin-chain confirmation or client availability.

This allows AI Link to decouple:

• user interaction latency

• blockchain confirmation latency

• AI inference execution time

In practice, this means the system never holds open synchronous execution contexts while waiting for inference, reducing tail latency and eliminating backpressure on the origin chain.

---

3) What does “request recording” mean, and why is it useful?

AI Link records requests on-chain to create a verifiable anchor for:

• execution intent

• settlement eligibility

• auditing and tracing

This is intentionally separated from execution. Recording does not mean “the request is finished,” and it does not mean “funds are locked.” It means the request has a durable identity and can be reasoned about across components.

---

4) How does the settlement model work (and why post-execution)?

AI Link uses a deposit + post-execution settlement model:

• Users maintain a deposit balance (minimum threshold enforced) to initiate requests.

• AI Link settles after execution based on actual measured costs.

This provides two practical advantages for partners:

• No per-request approvals (lower UX friction, fewer wallet prompts)

• Accurate billing (cost reflects actual gas and inference usage, not estimates)

In v1 behavior, the system checks for a minimum deposit threshold before processing a request (e.g., 1 USDC equivalent). Settlement is triggered after inference completes and after required confirmations are satisfied.

Implementation detail: AI Link can include a timeout unlock mechanism in the contract layer, but the current flow does not rely on per-request deposit locking as a primary mechanism. The goal is to avoid capital lockup while still preserving clear accounting semantics.

The deposit check performed prior to execution is intentionally minimal. Its purpose is not to lock funds, but to establish execution eligibility and prevent unbounded resource consumption.

Actual settlement is driven by post-execution accounting, which couples:

• measured Nesa execution gas

• measured AI inference cost

• chain-specific configuration parameters

This design avoids speculative pricing, reduces over-collateralization, and ensures that billing reflects real resource usage rather than worst-case assumptions.

---

5) How are fees accounted for?

AI Link’s fee accounting is designed to be decomposable and auditable. In general, total cost can include:

• Nesa execution gas (from Nesa execution)

• AI inference fee (from the inference service)

• optional origin-chain overhead (chain-specific configuration)

• 

The key property is that settlement is tied to post-execution measurement rather than pre-execution estimation, which is important for variable-cost AI workloads.

---

6) How is confidentiality handled without forcing partners to operate cryptography?

AI Link is designed so that partners do not need to manage low-level key material.

At a systems level:

• sensitive user inputs are protected before leaving the user environment

• uploaded artifacts remain protected in storage

• results are returned in a protected form to the client/application

This preserves a clean separation:

• partner applications integrate AI Link as a service

• privacy handling remains part of the AI Link execution pipeline, not an integration burden

---

7) What are the request states, and what are the failure semantics?

AI Link is designed to have explicit request states with terminal outcomes.

Typical states:

• accepted (validated and acknowledged)

• processing (execution in progress)

• completed (results produced and available)

• failed (execution aborted or could not complete)

Failure semantics are intentionally conservative:

• failed requests should not produce partial or ambiguous outputs

• settlement should only occur for completed requests, under clearly defined rules

• applications should be able to poll status at any time

For exchanges and infrastructure partners, explicit failure semantics are more important than “best-effort” behavior. Deterministic outcomes reduce operational risk.

State transitions in AI Link are monotonic and terminal. Once a request enters a terminal state (completed or failed), it cannot be reactivated or partially settled.

This prevents ambiguous edge cases such as:

• partial execution with partial billing

• retries that alter economic outcomes

• silent failure with inconsistent accounting

For infrastructure partners, this property simplifies reconciliation and incident response, as every request has a single, well-defined outcome.

---

8) How does AI Link scale operationally?

AI Link separates components that need to scale differently:

• Upload plane: protected payloads can be uploaded via short-lived presigned URLs to object storage, reducing backend bottlenecks.

• Execution plane: inference runs concurrently across multiple requests.

• Wallet pool / execution accounts (v1): execution can be driven by a pool of funded accounts to support concurrency and avoid head-of-line blocking.

This separation makes it feasible to support high-throughput use cases without turning the backend into the bottleneck.

Operational scalability is achieved by separating control-plane logic from data-plane execution.

Upload, execution, and settlement are handled by distinct subsystems with independent scaling characteristics. This avoids scenarios where increased inference load degrades authentication, accounting, or client responsiveness.

In v1, execution concurrency is further supported by pooled execution accounts, which prevent head-of-line blocking and allow multiple inference requests to progress in parallel.