DEV Community: SotaTek | AI & Blockchain Innovation Partner

What Actually Happens When You Mint an NFT?

SotaTek | AI & Blockchain Innovation Partner — Mon, 28 Sep 2026 07:51:12 +0000

“Mint an NFT” sounds like a single operation.

From a user's perspective, it often looks like this:

Connect Wallet
↓
Click Mint
↓
Confirm Transaction
↓
NFT Appears in Wallet

Underneath that button, several systems have to agree on the same state.

The image is not necessarily stored on the blockchain. The metadata may live on IPFS or another storage layer. The smart contract owns the token ID and ownership state. The wallet signs the transaction. An indexer eventually makes the new asset visible to the application.

A simplified architecture looks like this:

                NFT Application
                      │
                      ▼
                 Mint UI
                      │
                      ▼
                   Wallet
                      │
                signed tx
                      ▼
              Smart Contract
                /          \
               /            \
              ▼              ▼
         Token State     Metadata URI
              │              │
              ▼              ▼
         Blockchain     IPFS / Storage
              │
              ▼
            Events
              │
              ▼
           Indexer
              │
              ▼
        Marketplace / UI

The interesting part is that the NFT itself is only one piece of the system.

Start With What the NFT Actually Represents

Before writing a contract, you need to define the asset.

An NFT could represent:

A unique collectible
A game character
A ticket
A membership credential
A digital certificate
A real-world asset
A composable digital asset

That decision affects the contract design, metadata structure, token standard, and transfer model.

For example, a collection of unique digital artworks has a different structure from a game inventory containing thousands of identical consumable items.

This is why token standard selection should happen before implementation.

ERC-721 vs ERC-1155

For a simple one-of-a-kind asset, ERC-721 is usually the easier mental model.

Each token has its own ID:

Collection
│
├── Token #1
├── Token #2
├── Token #3
└── Token #4

ERC-1155 takes a different approach.

A single contract can represent multiple token types and quantities:

Contract
│
├── Item #1001 → 5,000 copies
├── Item #1002 → 2,000 copies
└── Item #1003 → 1 copy

This makes ERC-1155 useful for applications such as gaming, where an inventory may contain both unique assets and high-volume items.

The choice is therefore not about which standard is “better”.

It depends on the asset model.

A useful rule is:

Unique asset
↓
ERC-721

Multiple / batch-oriented assets
↓
ERC-1155

NFTs that own other assets
↓
Composable design such as ERC-998

The source article also identifies ERC-721, ERC-1155, ERC-998 and TRC-721 as common options, with the choice depending on asset structure, blockchain and marketplace compatibility.

The Image Is Not the NFT

This is one of the most common misconceptions.

Suppose an NFT displays:

Golden Sword
Attack: 95
Rarity: Legendary
Image: sword.png

Those properties are generally represented through metadata.

A simplified metadata document could look like:

{
"name": "Golden Sword",
"description": "Legendary in-game weapon",
"image": "ipfs://...",
"attributes": [
{
"trait_type": "Rarity",
"value": "Legendary"
},
{
"trait_type": "Attack",
"value": 95
}
]
}

The smart contract does not necessarily store this entire JSON object.

Instead, the token commonly exposes a metadata URI:

NFT #1842
│
▼
tokenURI(1842)
│
▼
ipfs://metadata...

This keeps large assets and metadata outside the blockchain while allowing the token to reference them.

The source architecture similarly separates metadata from the token itself, with metadata commonly stored off-chain using systems such as IPFS or Arweave and referenced from the token.

Why Put Metadata Off-Chain?

Storing an image directly on-chain is possible, but it can be expensive and impractical for many collections.

A common architecture is:

                Blockchain
                    │
                    │ tokenURI
                    ▼
              Metadata URI
                    │
                    ▼
            Decentralized Storage
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       Metadata             Image
          │                   │
          └─────────┬─────────┘
                    ▼
               NFT Interface

The important distinction is:

The blockchain proves token ownership.

It does not automatically guarantee that every external asset referenced by the token will remain available forever.

That is why storage architecture is part of NFT engineering, not just a frontend concern.

The Smart Contract Defines Ownership

A minimal ERC-721 contract might look like:

contract GameAsset is ERC721 {
uint256 private nextTokenId;

function mint(address to)
    external
    returns (uint256)
{
    uint256 tokenId = nextTokenId++;
    _safeMint(to, tokenId);

    return tokenId;
}

}

The important operation here is not the image or metadata.

It is:

_mint(to, tokenId)

The blockchain now records that:

Token #1842
↓
Owner = 0xA91...

That ownership state can then be independently verified.

A marketplace does not need to trust your database to determine who owns the NFT.

It can query the contract or indexed blockchain data.

What Actually Happens During Minting?

Let's follow a mint transaction.

The application prepares the transaction

The frontend knows:

Contract address
Token ID / mint parameters
Recipient
Metadata configuration

It prepares a contract call.

mint(recipient)

The wallet signs it

The user confirms the transaction through their wallet.

The wallet signs the transaction with the user's private key.

The application does not receive the private key.

User
│
▼
Wallet
│
│ signed transaction
▼
Blockchain Network

The transaction reaches the smart contract

The blockchain executes the contract.

The contract checks whatever rules have been implemented:

Can this caller mint?
│
├── No → revert
│
└── Yes
↓
Create token
↓
Assign owner
↓
Emit event

Ownership is written to blockchain state

After successful execution:

Token #1842
│
├── Owner → 0xA91...
└── Metadata → ipfs://...

The transaction receipt and event logs provide evidence of the state transition.

Minting Is Also a Security Boundary

The simple contract above has a major problem:

Who is allowed to call mint()?

If anyone can call it, anyone can create unlimited tokens.

Production contracts therefore need access control.

Conceptually:

function mint(address to)
external
onlyRole(MINTER_ROLE)
{
...
}

Other controls may include:

Maximum supply
Per-wallet limits
Pausing
Signature-based mint authorization
Payment validation
Allow lists
Mint phases
Upgrade permissions

This is why smart contract development is one of the security-sensitive stages of NFT development. The source article specifically identifies smart contract security, access control, and transaction integrity as major risks.

The Event Is Just as Important as the State

Suppose the contract emits:

event NFTMinted(
address indexed owner,
uint256 indexed tokenId
);

The event can then be consumed by off-chain infrastructure:

Smart Contract
│
│ NFTMinted
▼
Blockchain Node
│
▼
Event Listener
│
▼
Indexer
│
▼
Application Database
│
▼
Marketplace / UI

This is how the application can discover that a new NFT has been minted without constantly scanning every transaction manually.

The blockchain remains the source of truth.

The indexer becomes the query layer.

That distinction matters.

Why an Indexer Is Necessary

Imagine a marketplace displaying:

Latest NFTs
Trending Collections
Owner History
Sales History
Floor Price
Trading Volume

Querying raw blockchain state for every page load quickly becomes impractical.

An indexer can transform blockchain events into application-friendly data:

Blockchain Events
│
▼
Indexer
│
├── NFT ownership
├── Transfers
├── Sales
├── Collections
└── Metadata
│
▼
Database
│
▼
Frontend

But indexing introduces its own engineering problems.

You need to handle:

Duplicate events
RPC failures
Delayed confirmations
Chain reorganizations
Reprocessing
Idempotency
Metadata synchronization

So the NFT does not become “visible everywhere” immediately after the user clicks Mint.

There is a state transition between transaction submitted and application synchronized.

The Marketplace Does Not Own the NFT

A marketplace typically facilitates trading.

The underlying NFT remains governed by its smart contract.

A simplified secondary sale looks like:

Seller
│
│ list NFT
▼
Marketplace
│
│ buyer purchases
▼
Smart Contract
│
├── transfer NFT
├── transfer payment
└── emit events
│
▼
Indexer
│
▼
Updated marketplace

This is an important architectural boundary.

The marketplace database should not become the authority for ownership.

The contract should enforce the actual asset transfer.

Royalties Are a Contract Design Problem

NFT projects often want creators to receive a percentage from secondary sales.

That sounds straightforward:

Sale = $1,000
Royalty = 5%
Creator = $50
Seller = $950

But royalty behavior is not uniformly enforced across every marketplace and trading environment.

This means royalty requirements need to be considered at both levels:

Smart Contract
+
Marketplace Integration

A technically correct royalty implementation does not guarantee identical behavior across every external marketplace.

This is one reason marketplace compatibility should be considered early rather than after the contract is deployed.

Immutable vs Upgradeable Contracts

Another architectural decision is whether the contract should be immutable or upgradeable.

An immutable contract provides a strong guarantee:

Deployed
↓
Logic stays fixed

An upgradeable architecture introduces:

Proxy
│
▼
Implementation
│
├── V1
├── V2
└── V3

Upgradeability can be useful when requirements are expected to evolve.

But it also introduces additional trust and security assumptions.

For example:

Who controls upgrades?
Can the administrator change ownership logic?
Can metadata behavior change?
Is the upgrade mechanism secured?
What happens if the upgrade key is compromised?

There is no universal answer.

The important thing is to make the trust model explicit before deployment.

Gas Is an Architecture Constraint

Every on-chain operation has a cost.

The cost can be affected by:

Blockchain network
Contract complexity
Storage operations
Minting model
Batch size
Current network demand

For large collections, this can influence whether you use:

One transaction per NFT

or a batch-oriented approach.

ERC-1155 can be particularly useful when many token types or quantities need to be managed efficiently.

This is why blockchain selection should happen before implementation rather than being treated as an infrastructure detail at the end.

The Architecture I Would Start With

For a typical NFT platform, I would separate responsibilities like this:

                     User
                      │
                      ▼
                Web / Mobile App
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
       Wallet                  Backend
                                  │
                   ┌──────────────┼──────────────┐
                   ▼              ▼              ▼
               Metadata        Indexer       Marketplace
               Service           │
                   │             │
                   ▼             ▼
            IPFS / Storage   Application DB
                                  │
                                  │
                              Blockchain
                                  │
                       ┌──────────┴──────────┐
                       ▼                     ▼
                NFT Contract            Token Contract

The responsibilities stay clear:

Wallet → authorization
Frontend → user interaction
Backend → application logic
Smart contract → ownership + on-chain rules
Storage → metadata + assets
Indexer → blockchain read model
Marketplace → trading experience
Blockchain → settlement + ownership truth

This separation also makes it easier to replace individual components without redesigning the entire system.

The Hard Part Isn't Minting

Writing a basic NFT contract is not particularly difficult.

The difficult questions appear around the contract:

What exactly does the token represent?
Where does the metadata live?
Who can mint?
Can the contract be upgraded?
How is ownership indexed?
How are royalties handled?
What happens when the RPC provider fails?
How does the application reconcile pending transactions?
Which marketplaces support the required behavior?
What happens if metadata becomes unavailable?

In our blockchain work at SotaTek, these are often the questions that require more architectural consideration than the minting logic itself. The contract may only take a few functions to implement, but making the entire system reliable means thinking through storage, indexing, wallet flows, marketplace compatibility, and the boundary between on-chain and off-chain state.

These are architecture questions, not Solidity syntax questions.

That is why a production NFT implementation needs to consider smart contracts, metadata, storage, wallets, indexing, marketplaces, security, and blockchain infrastructure as one system.

Final Takeaway

An NFT is not an image stored on a blockchain.

It is better understood as a combination of:

Token Standard
+
Smart Contract
+
Ownership State
+
Metadata
+
Off-chain Storage
+
Wallet
+
Blockchain
+
Indexing

The blockchain provides verifiable ownership and transaction history.

The smart contract defines the rules.

The metadata describes the asset.

The wallet authorizes transactions.

The indexer makes blockchain state usable by applications.

And the marketplace connects that infrastructure to users.

Once you understand these boundaries, NFT development becomes less about “minting a token” and more about designing a system where on-chain truth and off-chain application state remain consistent.

For a broader overview of NFT token standards, development stages, use cases, and the cost factors involved in taking an NFT project from contract deployment to marketplace integration, this NFT token development guide provides additional context.

What Actually Happens When You Swap Tokens on a DEX?

SotaTek | AI & Blockchain Innovation Partner — Fri, 25 Sep 2026 09:10:29 +0000

A DEX can look deceptively simple from the frontend.

Select two tokens, enter an amount, click Swap, approve the transaction, and wait.

Underneath that button, however, several systems are working together:

User
│
▼
Wallet
│
▼
DEX Frontend
│
▼
Router / Smart Contract
│
├── Liquidity Pool
├── Token Contracts
└── Pricing Logic
│
▼
Blockchain
│
▼
Event Logs
│
▼
Indexer

Understanding this flow is useful because a DEX is not simply a UI connected to a smart contract.

It is a distributed trading system where pricing, liquidity, execution, settlement, and indexing all have different responsibilities.

Start With the Liquidity Pool

Consider a simple ETH/USDC pool.

The pool contains:

ETH → 10
USDC → 30,000

A trader wants to swap ETH for USDC.

In an AMM-based DEX, the trade does not need to find another trader willing to take the opposite side.

The trader interacts with the liquidity pool itself.

Liquidity providers supply the assets, and the AMM determines the exchange rate according to its pricing function.

A simplified constant-product model is:

x × y = k

Where:

x = reserve of token A
y = reserve of token B
k = invariant

Before the trade:

10 ETH × 30,000 USDC
= 300,000

Suppose the trader sends 1 ETH into the pool.

The new ETH reserve becomes:

x' = 11 ETH

The AMM needs to maintain the invariant:

11 × y' = 300,000

Therefore:

y' ≈ 27,272.73 USDC

The difference between the old and new reserves represents the amount of USDC that can be removed from the pool, before fees and other implementation details are applied.

This is the basic idea behind an AMM.

The important part is that the pool itself becomes the counterparty.

Price and Execution Price Are Not the Same

This is where things become more interesting.

The displayed price might look like:

1 ETH = 3,000 USDC

But that does not mean a trader can necessarily swap a large amount of ETH at exactly 3,000 USDC.

Why?

Because the trade changes the pool reserves.

A larger trade moves the pool further along its pricing curve.

This creates price impact.

There is also a difference between:

Market price
Quoted execution price
Price impact
Slippage tolerance

A production DEX needs to expose these clearly before the user signs the transaction.

For example:

Input: 1.0 ETH
Expected output: 2,970 USDC
Price impact: 0.8%
Minimum received: 2,940 USDC
Network fee: 0.002 ETH

These numbers are not just UI decoration.

They are part of the transaction safety model.

The Frontend Does Not Execute the Swap

The frontend calculates or retrieves a quote.

It does not ultimately control the token transfer.

The actual state transition happens through smart contracts.

A simplified flow is:

User
│
│ "Swap 1 ETH for USDC"
▼
Frontend
│
│ request quote
▼
Router
│
│ calculate route
▼
Smart Contract
│
│ execute swap
▼
Liquidity Pool
│
│ update reserves
▼
Blockchain State

The wallet signs the transaction.

The blockchain executes it.

The smart contract determines whether the requested operation is valid.

This distinction is important because the frontend should be treated as an untrusted interface.

Anyone can call the contract directly.

The contract itself must enforce the rules.

Token Approvals Add Another Transaction

For ERC-20 tokens, users typically need to authorize a contract to spend their tokens.

This creates an additional step:

User
│
▼
approve()
│
▼
Token Contract
│
▼
DEX Router
│
▼
swap()

So the first interaction with a token may require two transactions:

approve
swap

A production frontend needs to make this state understandable.

Otherwise users may see:

“Transaction successful”

and still wonder why the swap has not happened.

The frontend should distinguish between:

Approval confirmed
Swap pending
Swap confirmed
Swap failed

This is a small UX detail with a large operational impact.

The Router Is Where Things Get Interesting

A simple DEX might execute:

ETH → USDC

But users may not always get the best execution through a single pool.

A router can split or chain trades:

ETH
│
├── Pool A
│
▼
USDC
│
▼
Pool B
│
▼
DAI

Or:

ETH
│
├── 60% → Pool A
│
└── 40% → Pool B
│
▼
USDC

The router's job is to determine how the requested trade should be executed according to the available liquidity and routing logic.

This creates a trade-off.

More sophisticated routing can improve execution, but it also increases:

Gas consumption
Contract complexity
Failure modes
Simulation requirements
Security surface

The cheapest route computationally is not necessarily the route with the best execution price.

What Happens When the User Clicks "Swap"?

Let's follow the transaction.

Step 1: The frontend creates a transaction

The application prepares something conceptually similar to:

to:
DEX Router

method:
swapExactTokensForTokens()

parameters:
amountIn
amountOutMin
path
recipient
deadline
Step 2: The wallet asks for authorization

The user reviews the transaction and signs it.

The wallet produces a cryptographic signature proving that the account authorized the transaction.

Step 3: The transaction reaches the network

The transaction is broadcast to the blockchain network.

At this point it is not necessarily finalized.

It may be:

Pending
↓
Included in block
↓
Executed
↓
Confirmed / finalized

The frontend therefore needs to handle asynchronous transaction state rather than assuming that submission equals completion.

Step 4: The smart contract executes

The router calls the required contracts.

The transaction may involve:

Router
↓
Token A
↓
Pool
↓
Token B

Each contract call changes blockchain state.

If any required condition fails, the transaction reverts.

What Happens Inside the Pool?

The pool receives the input token.

Then the contract calculates how much output can be released while respecting its pricing rules.

Conceptually:

Before:

Token A reserve = 10
Token B reserve = 30,000

↓

Trader sends Token A

↓

AMM calculation

↓

After:

Token A reserve = 11
Token B reserve = ~27,272

The exact calculation depends on the AMM implementation.

Real protocols may also account for:

Trading fees
Concentrated liquidity
Multiple price ranges
Dynamic fees
Different invariant designs

So the simple x × y = k model is useful for understanding the concept, but it is not a complete representation of every modern AMM.

Where Do Liquidity Providers Fit?

The pool needs liquidity.

Liquidity providers deposit assets into the protocol and receive a claim representing their share of the pool.

Conceptually:

Liquidity Provider
│
├── Token A
└── Token B
│
▼
Liquidity Pool
│
▼
Traders

In return, LPs can receive a portion of trading fees according to the protocol's rules.

But providing liquidity is not risk-free.

LPs can be exposed to:

Impermanent loss
Smart contract risk
Asset volatility
Oracle risk
Protocol-specific risks

From an engineering perspective, liquidity is therefore not simply a feature.

It is part of the protocol's economic design.

The Blockchain Is the Source of Settlement Truth

After the transaction executes, the blockchain contains the resulting state.

For example:

Trader
↓
-1 ETH
+2,970 USDC

Pool
↓
+1 ETH
-2,970 USDC

The DEX frontend should not invent this state.

It should derive it from blockchain data.

That creates an important architecture:

Blockchain
│
├── Transactions
├── Events
└── Contract State
│
▼
Indexer
│
▼
Application DB
│
▼
DEX Frontend
Why You Need an Indexer

Reading raw blockchain data directly from the frontend becomes expensive and inconvenient as the application grows.

Consider a trading page that needs:

Historical trades
Token prices
Volume
Liquidity
User positions
Transaction history
Pool activity

You could query the blockchain repeatedly.

But that is not an efficient application architecture.

An indexer processes blockchain events and transforms them into application-friendly data.

For example:

Swap Event
│
▼
Event Listener
│
▼
Indexer
│
▼
Database
│
├── price history
├── volume
├── transactions
└── pool analytics

The blockchain remains the source of truth.

The indexed database becomes the query layer.

That distinction is important.

Events Are Part of the Integration Contract

Smart contracts can emit events such as:

event Swap(
address indexed sender,
uint256 amountIn,
uint256 amountOut
);

The event allows off-chain systems to observe state transitions without repeatedly reconstructing every operation from scratch.

But event processing needs to be designed carefully.

An indexer should account for:

Duplicate processing
Missed events
RPC failures
Chain reorganizations
Reprocessing
Idempotency

For example, processing the same Swap event twice should not create two trades in the database.

This is a distributed-systems problem hiding inside a DeFi application.

Slippage Is a Safety Mechanism

Suppose the frontend quotes:

1 ETH → 3,000 USDC

But market conditions change before the transaction is executed.

The user might receive:

1 ETH → 2,700 USDC

That may be unacceptable.

The transaction therefore includes a minimum acceptable output:

amountOutMin = 2,950 USDC

If the actual output falls below that threshold, the transaction reverts.

This is why slippage tolerance is more than a UI preference.

It becomes a parameter enforced by the smart contract.

The Mempool Creates Another Problem: MEV

There is a gap between:

User signs transaction

and:

Transaction is executed

During that period, the transaction may be visible to actors that can observe pending transactions.

This creates opportunities for Maximal Extractable Value (MEV).

One common example is a sandwich attack:

User's swap
│
▼
Attacker observes transaction
│
├── Buy before user
│
├── User executes at worse price
│
└── Sell after user

The result can be worse execution for the original trader.

DEX design therefore needs to consider:

Slippage limits
Transaction ordering
Private transaction mechanisms
Routing
Liquidity depth

MEV is not purely a smart-contract bug.

It is a consequence of how transaction ordering and public blockchains interact.

Gas Is Part of the Product

A technically correct swap can still provide a poor user experience if the transaction costs too much.

Gas usage depends on factors such as:

Number of contract calls
Storage operations
Routing complexity
Network conditions
Smart contract implementation

A simple swap may require relatively little computation, while a multi-hop or multi-contract transaction can be considerably more expensive.

This creates an important optimization question:

Is the better price worth the additional execution cost?

A routing algorithm that saves a user 5 USDC but costs an additional 8 USDC in gas is not actually improving execution.

The system needs to optimize for net user outcome, not just quoted token output.

Cross-Chain DEXs Add Another Trust Boundary

Supporting multiple blockchains sounds like a frontend feature.

It is not.

A cross-chain DEX may involve:

Chain A
│
▼
Bridge / Messaging Layer
│
▼
Chain B
│
▼
DEX / Liquidity

Now the system depends on additional components:

Bridges
Messaging protocols
Relayers
Multiple RPC providers
Multiple smart contract environments
Cross-chain liquidity

Every new dependency expands the attack surface.

Supporting ten chains is not simply ten times the configuration.

The security model becomes significantly more complex.

The Architecture I Would Start With

For a production-oriented AMM DEX, a reasonable architecture is:

                User
                  │
                  ▼
            Web / Mobile UI
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
     Wallet              API Layer
                            │
                     ┌──────┴──────┐
                     ▼             ▼
                 Indexer       Analytics
                     │
                     ▼
                Application DB

                  Blockchain
                       │
         ┌─────────────┴─────────────┐
         ▼                           ▼
    Router Contract             Token Contracts
         │
         ▼
    Liquidity Pools

Each layer has a specific responsibility:

Frontend → interaction
Wallet → authorization
Smart contract → execution + settlement
Liquidity pool → available liquidity
Blockchain → state + finality
Indexer → queryable blockchain data
Database → application read model
Analytics → aggregated insights

Keeping these boundaries clear makes the system much easier to test, monitor, and evolve.

The Hard Part Isn't the Swap

Writing a basic swap contract is not the hardest part of building a DEX.

The difficult engineering problems appear around it:

How much liquidity is available?
How do we calculate a safe quote?
What happens when the transaction is delayed?
How do we handle failed transactions?
How do we prevent unauthorized actions?
How do we index millions of events?
How do we protect users against bad execution?
How do we manage MEV?
What happens when an RPC provider fails?
What changes when we add another chain?

The swap is only one state transition inside a much larger distributed system.

Final Takeaway

A DEX is best understood as a combination of:

Trading Logic
+
Liquidity
+
Smart Contracts
+
Wallets
+
Blockchain Infrastructure
+
Indexing
+
User Protection

The frontend makes the system look simple.

Underneath it, the protocol has to coordinate pricing, liquidity, authorization, execution, settlement, and off-chain data.

That is why DEX development is less about building a “swap page” and more about designing a reliable financial system around blockchain constraints.

The most important architectural question is not:

“How do we build a token swap?”

It is:

“Which parts of the trading system need to be trustless, which parts can remain off-chain, and how do we keep the two consistent?”

That decision shapes almost every other engineering choice.

For a broader overview of DEX architecture, trading models, development stages, and the infrastructure involved, see SotaTek's DEX Development guide.

Building an Enterprise AI Chatbot: What the Architecture Actually Looks Like

SotaTek | AI & Blockchain Innovation Partner — Thu, 24 Sep 2026 08:35:12 +0000

An enterprise AI chatbot is easy to demo.

Connect an LLM to a chat interface, add a system prompt, upload a few documents, and you have something that looks impressive in an afternoon.

Production is different.

The moment a chatbot needs to access private company data, respect user permissions, retrieve current information, call internal APIs, and operate reliably at scale, it stops being a simple LLM application.

It becomes a distributed system.

A practical architecture usually looks something like this:

                     User
                       │
                       ▼
                Chat Interface
                       │
                       ▼
                API / Gateway
                       │
                       ▼
             AI Orchestration Layer
                /      |       \
               /       |        \
              ▼        ▼         ▼
           RAG      Tools      Policies
            │         │           │
            ▼         ▼           ▼
      Knowledge DB  CRM/ERP   Access Control
            │         │
            └────┬────┘
                 ▼
                LLM
                 │
                 ▼
          Response / Action

The LLM is only one component.

The LLM Should Not Be Your Application Backend

A common first architecture looks like this:

User → LLM → Response

That works for general questions.

It breaks down as soon as the user asks:

“What is the status of my latest support ticket?”

The model does not inherently know the answer.

The application needs to:

Authenticate the user.
Determine what data the user is allowed to access.
Retrieve the relevant ticket.
Provide that context to the model.
Generate a response.
Return the result without exposing unauthorized data.

The architecture becomes:

User
│
▼
Authentication
│
▼
Authorization
│
▼
Application Backend
│
├── CRM / Ticketing API
├── Knowledge Base
└── AI Orchestrator
│
▼
LLM

This distinction is important:

The LLM generates language. The application owns the business rules.

Do not put authorization logic into a prompt and expect the model to enforce it.

RAG Is a Retrieval System First

Enterprise chatbots frequently use Retrieval-Augmented Generation (RAG) to answer questions from internal knowledge.

A simplified pipeline is:

Documents
│
▼
Ingestion
│
▼
Chunking
│
▼
Embeddings
│
▼
Vector Database

At query time:

User Query
│
▼
Embedding
│
▼
Retriever
│
▼
Relevant Documents
│
▼
Prompt + Context
│
▼
LLM
│
▼
Answer

The important engineering point is that RAG quality depends heavily on the retrieval layer.

If the wrong documents are retrieved, a more capable model does not automatically fix the problem.

That means production RAG needs to consider:

Chunking strategy
Metadata
Embedding model
Retrieval strategy
Top-K selection
Filtering
Document freshness
Source citations
Access permissions

A vector database is therefore not just a storage component. It is part of the answer-quality pipeline.

Authorization Must Happen Before Retrieval

This is one of the easiest mistakes to make in an enterprise RAG system.

Imagine a company has documents belonging to:

Finance
HR
Engineering
Sales

A user from Sales asks:

“Show me the latest compensation policy.”

If the retriever searches the entire vector database first and applies permissions afterward, sensitive HR content may already have entered the model context.

The safer flow is:

User
│
▼
Identity
│
▼
Permissions
│
▼
Filtered Retrieval
│
▼
Authorized Documents
│
▼
LLM

Access control should be part of retrieval itself.

For multi-tenant systems, this becomes even more important:

tenant_id = customer_123
user_role = manager
department = sales

These attributes should influence what the retrieval layer is allowed to return.

The model should never be responsible for deciding whether a user is authorized to see a document.

When RAG Is Not Enough

RAG works well when the chatbot needs to answer questions from relatively stable knowledge.

But consider:

“Create a support ticket for this issue.”

Retrieving documentation does not solve that problem.

The system needs to perform an action.

This is where tool calling or agentic workflows become useful.

User
│
▼
LLM
│
├── Search knowledge
├── Get customer
├── Create ticket
└── Check ticket status

The LLM decides which tool is relevant, but the tools themselves should expose controlled interfaces.

For example:

create_ticket(
customer_id,
category,
description
)

The model should not receive unrestricted database access.

Give it narrowly scoped capabilities.

This creates a useful principle:

Give the model tools, not infrastructure access.

Chatbot vs Agent

There is a meaningful architectural difference between answering and acting.

A traditional enterprise chatbot:

Question
↓
Retrieve
↓
Generate
↓
Answer

An agentic workflow:

Goal
↓
Plan
↓
Tool
↓
Observe
↓
Tool
↓
Observe
↓
Final Result

For example:

“Find the customer's last three orders, identify the delayed one, and open a support ticket.”

The system may need to:

Query CRM
Query order service
Compare delivery status
Generate ticket content
Create ticket
Return confirmation

That is no longer just a chatbot.

It is an orchestration system with an LLM as one of its decision-making components.

Keep the Tool Layer Deterministic

One of the most useful design principles for agentic systems is to keep tool execution deterministic.

For example:

LLM
│
│ create_ticket(...)
▼
Tool Gateway
│
├── Validate parameters
├── Check authorization
├── Apply business rules
├── Execute API call
└── Return structured result

Do not let the model directly execute arbitrary SQL or arbitrary HTTP requests.

Instead, expose explicit capabilities:

get_customer()
get_order()
search_policy()
create_ticket()
update_ticket()

This makes the system easier to secure, test, monitor, and audit.

Enterprise Data Is Usually the Hard Part

The LLM is often the easiest component to replace.

Enterprise data is not.

A real deployment may need to connect:

             AI Application
                   │
   ┌───────────────┼────────────────┐
   ▼               ▼                ▼
  CRM             ERP           Knowledge Base
   │               │                │
   ▼               ▼                ▼

Customer Data Transactions Documents

These systems often have different:

APIs
Authentication models
Data formats
Update frequencies
Failure modes
Rate limits

The AI layer therefore needs an integration boundary rather than a collection of ad-hoc API calls buried inside prompts.

Observability Is Part of the Architecture

A production chatbot should not only log:

user → response

You need to understand how the response was produced.

A useful trace might contain:

Request ID
User ID
Model
Prompt version
Retrieved documents
Tool calls
Latency
Token usage
Errors
Final response

For example:

Request
│
├── Retrieval: 180 ms
├── CRM API: 240 ms
├── LLM: 1.8 s
├── Tokens: 2,431
└── Total: 2.3 s

Without this information, debugging a bad answer becomes guesswork.

Observability also gives you the data needed to optimize cost and latency.

Evaluation Should Test the System, Not Just the Model

A model benchmark is not enough to determine whether an enterprise chatbot works.

You need to evaluate the complete pipeline:

Question
↓
Retrieval
↓
Context
↓
Model
↓
Tool Calls
↓
Response

Useful metrics include:

Retrieval relevance
Answer correctness
Citation accuracy
Hallucination rate
Tool-call accuracy
Task completion rate
Latency
Cost per request
Human escalation rate

A model can produce an excellent answer from the wrong document.

That is still a system failure.

A Production-Oriented Architecture

Putting the pieces together:

                     User
                       │
                       ▼
                ┌─────────────┐
                │ API Gateway │
                └──────┬──────┘
                       │
                Authentication
                       │
                       ▼
              ┌─────────────────┐
              │ AI Orchestrator │
              └───────┬─────────┘
                      /|\
                     / | \
                    /  |  \
                   ▼   ▼   ▼
                 RAG Tools Policy
                  │    │     │
                  ▼    ▼     ▼
               Vector CRM   AuthZ
               Store  ERP
                  │    │
                  └────┬┘
                       ▼
                      LLM
                       │
                       ▼
                Validation Layer
                       │
                       ▼
                    Response

Around the entire system, you also need:

Observability
Evaluation
Audit Logging
Rate Limiting
Secrets Management
Cost Controls

These are not optional production extras.

They are part of the system.

The Real Architecture Decision

The interesting question is not:

“Which LLM should we use?”

Models change quickly.

The more durable engineering decisions are:

Where does enterprise knowledge live?
How is it retrieved?
Where is authorization enforced?
Which actions can the model perform?
How are tool calls validated?
How do we handle failures?
How do we evaluate output quality?
How do we observe the complete request lifecycle?

Once these boundaries are clear, the underlying model becomes a replaceable component rather than the foundation of the entire architecture.

Final Takeaway

An enterprise AI chatbot is not an LLM with a chat UI.

It is an application architecture that combines:

LLM
+
RAG
+
Enterprise APIs
+
Access Control
+
Tool Calling
+
Observability
+
Evaluation

The LLM provides the language interface.

The surrounding system provides data, permissions, actions, and reliability.

That is the difference between a chatbot that looks impressive in a demo and one that can actually operate inside an enterprise environment.

If you're looking at the broader implementation lifecycle, including data preparation, architecture selection, enterprise integration, security, and deployment, this enterprise AI chatbot implementation guide provides additional context.

What Actually Happens When You Put an NFT Into a Game?

SotaTek | AI & Blockchain Innovation Partner — Thu, 24 Sep 2026 08:25:43 +0000

Putting an NFT into a game sounds simple:

Mint an NFT, connect a wallet, and let players trade it.

That is the easy part.

The difficult part is deciding what belongs on-chain, what stays off-chain, and how the two systems communicate without turning every gameplay action into a blockchain transaction.

A production NFT game is not a traditional game with a smart contract attached to it. It is a distributed system with two very different execution environments:

                NFT GAME
                   │
         ┌─────────┴─────────┐
         │                   │
     OFF-CHAIN             ON-CHAIN
         │                   │
    Game Engine         Smart Contracts
    Game Server         NFT Ownership
    Database            Token Balances
    Matchmaking         Asset Transfers
    Gameplay            Marketplace
         │                   │
         └─────────┬─────────┘
                   │
              Wallet / RPC

Once you look at it this way, many of the architecture decisions become much easier to reason about.

The Game Should Not Run on the Blockchain

The first mistake is trying to put gameplay logic on-chain.

Imagine a multiplayer game where every movement generates a blockchain transaction:

Player moves
↓
Transaction
↓
Validator
↓
State update
↓
Game server
↓
Other players

It would be slow, expensive, and completely unnecessary.

The blockchain is good at things that need shared, verifiable state.

A game engine is good at things that need fast, mutable state.

So the architecture should usually look more like this:

                 Game Client
                      │
          ┌───────────┴───────────┐
          │                       │
          ▼                       ▼
    Game Backend              Wallet
          │                       │
          ▼                       ▼
    Game Database            Blockchain
          │                       │
          │                ┌──────┴──────┐
          │                │             │
          │             NFT Contract  Token Contract
          │
          └─────── Asset State ──────────┘

The game server handles gameplay.

The blockchain handles ownership and other state that needs to be independently verifiable.

That boundary is probably the most important architectural decision in an NFT game.

What Actually Goes On-Chain?

A useful rule is:

Put the minimum amount of state on-chain that needs blockchain-level ownership, verification, or settlement.

For an NFT game, that might include:

Token ownership
NFT ID
Token metadata reference
Supply constraints
Transfer rules
Marketplace transactions
Royalty logic
In-game token balances

It usually should not include:

Player coordinates
Animation state
Matchmaking
Real-time combat
Chat
Temporary game state
Every player interaction

For example, a sword might exist as an NFT:

NFT #1842
│
├── Owner: 0xA91...
├── Token URI
├── Rarity
└── Asset ID

But the fact that the player currently has that sword equipped belongs in the game layer.

This gives you two states:

Blockchain:
"Wallet X owns Sword #1842"

Game server:
"Player 928 has Sword #1842 equipped"

The second state can change thousands of times without touching the blockchain.

The Smart Contract Is the Ownership Layer

The smart contract should be treated as the authoritative source for blockchain ownership.

A simplified NFT contract might look like:

contract GameItem is ERC721 {
uint256 private nextTokenId;

function mint(address player)
    external
    returns (uint256)
{
    uint256 tokenId = nextTokenId++;
    _safeMint(player, tokenId);
    return tokenId;
}

}

The important part is not the exact implementation.

It is the responsibility boundary.

The contract answers:

Who owns this asset?
Can it be transferred?
Can it be minted?
How many can exist?
What rules apply to the transfer?

The game server should not maintain a second independent truth about ownership.

If the database says:

Player A → Sword #1842

but the blockchain says:

Player B → Sword #1842

the system has a consistency problem.

For ownership, the blockchain should win.

What Happens When a Player Buys an NFT?

This is where the distributed architecture becomes interesting.

Suppose Player A buys an NFT from Player B.

A simplified flow is:

Player A
│
│ purchase
▼
Marketplace
│
│ transaction
▼
Blockchain
│
├── transfer NFT
├── transfer payment
└── emit event
│
▼
Indexer
│
▼
Game Backend
│
▼
Game Client

The blockchain transaction changes ownership.

The game backend then observes that change and updates its local representation.

This introduces an important concept:

Blockchain state and application state are eventually synchronized, not necessarily updated at exactly the same time.

That means the backend must handle:

Pending transactions
Failed transactions
Reorganizations
Duplicate events
Delayed confirmations
RPC failures

A production integration cannot simply assume:

sendTransaction()
↓
success = true
↓
updateDatabase()

The transaction lifecycle is asynchronous.

Events Are the Bridge

Smart contract events are useful for synchronizing blockchain activity with the game backend.

For example:

event ItemTransferred(
address indexed from,
address indexed to,
uint256 indexed tokenId
);

The backend can subscribe to blockchain events and update its internal state.

Conceptually:

Smart Contract
│
│ ItemTransferred
▼
Blockchain Node / RPC
│
▼
Event Listener
│
▼
Game Database
│
▼
Game API

This is much more scalable than having the game client repeatedly query the blockchain for every piece of state.

Wallets Are Not Just Login Buttons

Wallet integration is another place where traditional game architecture changes.

A wallet provides an address and, more importantly, control over the private key associated with that address.

The game might therefore use:

Game Account
│
├── player profile
├── progression
├── preferences
└── wallet address

The wallet address identifies the blockchain account, but it should not automatically become the entire identity system of the game.

For example:

Player ID: 92814
Wallet: 0xA91...

The backend can associate the two after a secure wallet-signature authentication flow.

This allows the game to maintain normal application functionality while using the wallet for blockchain ownership.

NFT Metadata Is Another Distributed-System Problem

The NFT itself may only contain a reference to metadata rather than storing every attribute directly on-chain.

Conceptually:

NFT
│
└── tokenURI
│
▼
Metadata
│
├── name
├── image
├── attributes
└── game asset reference

That creates another architectural question:

What happens if the metadata disappears or changes?

If the game depends on a centralized URL, the NFT may technically exist on-chain while the actual asset becomes unavailable.

For long-lived assets, the storage strategy therefore matters almost as much as the smart contract itself.

The blockchain can prove ownership.

It does not automatically guarantee that every piece of off-chain data associated with that ownership will remain available forever.

The Game Engine Is Still the Game Engine

Unity or Unreal Engine remains responsible for what it has always been good at:

Input
↓
Gameplay Logic
↓
Rendering
↓
Physics
↓
Audio
↓
Networking

Blockchain integration becomes another service boundary.

For example:

Unity / Unreal
│
▼
Blockchain SDK / Backend API
│
├── Wallet
├── NFT data
├── Marketplace
└── Smart contract calls

This separation is important.

You do not want blockchain-specific logic spread across hundreds of gameplay components.

Keep wallet operations, contract interactions, transaction state, and blockchain synchronization behind well-defined interfaces.

The Real Challenge Is Consistency

Once you have two state machines, consistency becomes the hard problem.

Consider this sequence:

Player buys NFT
Transaction submitted
Transaction pending
Game server receives request
Player closes the game
Transaction confirms
Backend misses the event
Player logs in again

What does the game show?

This is no longer simply a smart-contract problem.

It is a distributed-systems problem.

You need mechanisms for:

Event replay
Idempotent processing
Transaction status tracking
Confirmation handling
Reconciliation
Retry logic
RPC failover

A useful backend design is:

Blockchain
│
▼
Event Listener
│
▼
Message Queue
│
▼
Indexer
│
▼
Game Database
│
▼
Game API

The indexer becomes the bridge between blockchain state and application state.

Where the Economy Lives

NFT games often add another layer: fungible tokens.

You may have:

NFT
├── Characters
├── Weapons
├── Skins
└── Land

Token
├── Rewards
├── Purchases
└── Marketplace payments

This is where tokenomics becomes an engineering concern.

A reward mechanism that continuously creates tokens without corresponding demand can create an economic problem even if the smart contract is perfectly secure.

The technical architecture therefore has to support the economic model rather than treating tokenomics as a separate document.

Security Changes Everything

Traditional game security focuses heavily on the client and server.

Blockchain games add another security boundary:

Client
↓
Backend
↓
Smart Contract
↓
Blockchain

A vulnerability in a deployed contract can be fundamentally different from a server-side bug.

You cannot simply deploy a patch and assume the old state disappears.

Smart contracts handling NFTs, tokens, marketplace transactions, and royalties should therefore be treated as security-critical infrastructure.

At minimum, review:

Access control
Mint authorization
Transfer restrictions
Reentrancy
Integer handling
Signature validation
Replay protection
Upgradeability assumptions
Economic attack vectors

The blockchain layer should be audited independently from the game client.

The Architecture I Would Start With

For a typical NFT game, a reasonable starting architecture is:

                 ┌───────────────┐
                 │ Game Client   │
                 │ Unity/Unreal  │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │ Game Backend  │
                 └───────┬───────┘
                         │
           ┌─────────────┼─────────────┐
           ▼             ▼             ▼
      Game DB       Blockchain API   Marketplace
                         │
                         ▼
                     RPC Node
                         │
                         ▼
                 ┌───────────────┐
                 │ Smart Contract│
                 ├───────────────┤
                 │ NFT           │
                 │ Token         │
                 │ Marketplace   │
                 └───────────────┘

The important thing is not the number of components.

It is the ownership of responsibilities.

Game server → gameplay state
Database → application state
Blockchain → verifiable ownership and settlement
Smart contract → enforceable on-chain rules
Wallet → player-controlled blockchain identity
Indexer → synchronization

Once those boundaries are explicit, the system becomes much easier to scale and debug.

The Main Takeaway

An NFT game is not a game that happens to use NFTs.

It is a system where gameplay, blockchain state, wallets, smart contracts, and off-chain infrastructure have to agree on what is true.

The most important architectural decision is therefore not which blockchain to choose.

It is deciding:

What needs to be trustless, and what doesn't?

Put ownership and settlement where independent verification matters.

Keep high-frequency gameplay where low latency matters.

Use the backend and indexer to connect the two worlds.

That separation keeps the blockchain useful without forcing the entire game to behave like a blockchain.

And once you understand that boundary, NFT game development starts looking less like “adding Web3 to a game” and more like what it really is:

designing a distributed system with a game engine on one side and a blockchain on the other.

If you want to explore the broader NFT game development lifecycle, including asset design, tokenomics, smart contracts, wallet integration, and marketplace architecture, this NFT Game Development guide provides the wider context.

Zero-Knowledge Proofs Without the Magic: What the Prover and Verifier Actually Do

SotaTek | AI & Blockchain Innovation Partner — Mon, 14 Sep 2026 11:18:27 +0000

Zero-Knowledge Proofs Without the Magic: What the Prover and Verifier Actually Do

Zero-knowledge proofs are often described with a sentence that sounds almost impossible:

Prove that you know something without revealing what you know.

That description is correct, but it hides the part developers actually need to understand.

A zero-knowledge proof is not encryption. The prover does not simply hide some data and send it to the verifier.

Instead, the prover constructs a proof that a computation is valid, while revealing only the information that the protocol allows the verifier to see.

This distinction becomes important when ZK proofs are used in blockchain systems, where computation can be performed privately off-chain and verified cheaply on-chain.

Start With a Simple Problem

Suppose Alice knows a secret value x.

There is a public value derived from it:

y = hash(x)

Alice wants to prove:

“I know a value x such that hash(x) = y.”

But she does not want to reveal x.

A traditional solution would require Alice to reveal the secret:

Alice
  |
  | x
  v
Verifier
  |
  | hash(x) == y ?
  v
Valid

A zero-knowledge protocol changes the interaction:

             secret x
                |
                v
Alice       Prover
                |
                | proof
                v
           Verifier
                |
                v
        "The statement is valid"

The verifier learns that Alice knows a valid x, but does not learn x itself.

The interesting part is how the proof is constructed.

The Three Things You Need to Separate

When working with ZK systems, three concepts are easy to mix together:

1. The witness

The witness is the private information known by the prover.

In our example:

witness = x

The witness never needs to be exposed to the verifier.

2. The public inputs

These are values that the verifier is allowed to know.

public input = y

3. The statement

The statement defines what must be proven.

For example:

hash(x) == y

So the prover is effectively proving:

I know x
such that
hash(x) == y

without sending x.

That separation between witness, public inputs, and computation is one of the most useful mental models for understanding ZK systems.

A ZK Proof Is Really a Proof of Computation

This is where ZK becomes more interesting for blockchain developers.

Instead of thinking:

“I want to hide a value.”

Think:

“I want someone to verify that a computation was executed correctly without giving them all of the computation's private inputs.”

For example:

Private inputs
     |
     v
+-----------+
| Computation|
+-----------+
     |
     v
   Result
     |
     v
   Proof
     |
     v
+-----------+
| Verifier  |
+-----------+

The verifier does not need to reproduce the entire computation.

It only needs to verify the proof.

This is why ZK proofs are useful for blockchain scaling and privacy.

Where the Blockchain Fits

Blockchains are good at verification, but expensive as general-purpose computation environments.

Imagine a computation that requires millions of operations.

Executing all of them directly on-chain can be expensive.

A ZK-based architecture can move the expensive computation off-chain:

                 Off-chain
              ┌──────────────┐
              │   Prover     │
              │              │
Input ────────>│ Computation  │
              │              │
              │ Generate ZK  │
              │    Proof     │
              └──────┬───────┘
                     │
                     │ proof
                     v
              ┌──────────────┐
              │ Blockchain   │
              │              │
              │   Verifier   │
              └──────────────┘

The blockchain does not need to trust the prover.

It only needs to verify the proof.

This creates an important engineering trade-off:

Move computation off-chain, but preserve verifiability on-chain.

Why This Is Different From Encryption

A common misunderstanding is that ZK proofs are simply another form of encryption.

They solve different problems.

Encryption:

“Only authorized parties should be able to read this data.”

Zero-knowledge proof:

“You should be able to verify that this statement is true without learning my private information.”

You can also combine both techniques in the same system.

For example, sensitive application data can remain encrypted while a ZK proof demonstrates that the data satisfies a particular condition.

From Simple Examples to Real ZK Circuits

Real ZK systems don't usually express the computation as:

hash(x) == y

and stop there.

The computation is represented as a set of constraints.

Conceptually:

x ──> Constraint 1
 │
 ├──> Constraint 2
 │
 └──> Constraint 3
          |
          v
      Valid / Invalid

The proving system then transforms those constraints into a proof that can be verified without exposing the private witness.

Depending on the system, this can involve polynomial commitments, elliptic-curve operations, finite fields, and sophisticated proving algorithms.

You do not need to understand every mathematical detail to build a ZK application.

But you do need to understand the engineering boundary:

The circuit defines what is provable.

If the required business logic cannot be represented correctly in the circuit, the rest of the architecture does not matter.

The Cost Is Not Gone. It Has Moved.

This is one of the most important practical considerations.

ZK systems can reduce the amount of computation that needs to happen on-chain, but generating the proof can itself be computationally expensive.

A simplified cost model looks like:

                ZK Application
                      |
          +-----------+-----------+
          |                       |
          v                       v
   Proof Generation          Proof Verification
       expensive                 cheaper
      off-chain                  on-chain

This creates a trade-off between:

Prover compute
Proof generation time
Proof size
Verification cost
On-chain gas
Hardware requirements

The optimal design depends on the application.

A system that minimizes gas consumption may require significantly more off-chain computation.

A system optimized for proof-generation speed may have different hardware or circuit constraints.

There is no universal “ZK is cheaper” rule.

Where ZK Proofs Become Useful

The same architecture can support several classes of applications.

Private identity

A user could prove:

I satisfy eligibility condition X

without revealing every piece of information used to determine eligibility.

Private transactions

A system can prove that a transaction satisfies the required rules without exposing all transaction details publicly.

Scaling

A prover can execute a large amount of computation off-chain and submit a compact proof that the computation was performed correctly.

Verifiable computation

A service can perform computation for a user while providing cryptographic evidence that the result was generated according to a defined computation.

The common pattern is not simply privacy.

It is:

Compute privately or off-chain → generate proof → verify independently.

The Engineering Problems Are Different From Traditional Applications

ZK systems introduce constraints that are easy to underestimate.

Circuit complexity

The way you express an algorithm can have a major impact on proving cost.

An algorithm that is efficient in normal software may be expensive to represent as a ZK circuit.

Prover performance

Proof generation can require significant CPU, memory, or specialized hardware depending on the proving system and workload.

Data availability

In blockchain applications, proving that something is correct is not the same as making the underlying data available.

You still need to design how relevant data is stored, retrieved, and verified.

Smart contract integration

If proofs are verified on-chain, the verifier contract becomes part of the security-critical path.

Its interface, gas consumption, and failure handling need to be treated like any other production smart contract.

Key management

Some proving systems involve trusted setup assumptions or proving/verifying keys.

The security model of those components needs to be understood before deployment.

The Mental Model I Use

When evaluating a ZK architecture, I find it useful to reduce it to four questions:

1. What is private?
        ↓
2. What must be proven?
        ↓
3. Where is the computation executed?
        ↓
4. Where is the proof verified?

For example:

Private:
Customer eligibility data

        ↓

Prove:
Customer satisfies eligibility rules

        ↓

Compute:
Off-chain prover

        ↓

Verify:
Smart contract

If those four answers are clear, the rest of the architecture becomes much easier to reason about.

ZK Is Not a Magic Privacy Layer

Zero-knowledge proofs can provide powerful privacy and verification guarantees, but they do not automatically make an application private or secure.

The application still needs to handle:

Access control
Key management
Smart contract security
Data availability
Circuit correctness
Prover infrastructure
Client-side security
Protocol assumptions

A perfectly verified proof can still be part of a badly designed system.

The strongest ZK architectures are therefore not the ones with the most complicated cryptography.

They are the ones where the trust boundary is explicit.

Final Takeaway

The easiest way to understand zero-knowledge proofs is to stop thinking about them as a mechanism for “hiding data.”

Think of them as a way to establish:

“This computation was performed correctly, and I can prove it without revealing everything involved in that computation.”

That model explains why ZK proofs are useful for privacy, blockchain scaling, identity, and verifiable computation.

And it also explains the engineering trade-off: you are not eliminating computation—you are moving it to a place where it can be performed privately and then verified efficiently.

For a broader introduction to Zero-Knowledge Proofs, their privacy applications, and practical challenges, see SotaTek's Zero-Knowledge Proof in Blockchain guide.

AI Readiness Assessment for Developers: What to Check Before Building an AI System

SotaTek | AI & Blockchain Innovation Partner — Wed, 09 Sep 2026 10:52:58 +0000

Having access to an LLM API doesn't mean your application is ready for AI.

A team can have access to GPT, Claude, Gemini, or an open-source model and still fail to move beyond a proof of concept because of poor data quality, missing integrations, security gaps, unpredictable costs, or an architecture that cannot survive production workloads.

Before choosing a model, engineering teams should answer a more important question:

Is the system actually ready to support an AI workload?

An AI readiness assessment provides a structured way to evaluate that question before committing significant engineering resources.

Start With the Use Case, Not the Model

One of the most common mistakes is starting with model selection:

“Should we use GPT, Claude, or an open-source LLM?”

The better question is:

“What decision or workflow are we trying to improve?”

A well-defined AI use case should have:

A clear input and expected output
A measurable success criterion
A defined tolerance for errors
A known human fallback when necessary
A reason to use AI instead of deterministic logic

For example, “use AI for customer support” is too broad.

A more actionable definition is:

Generate a response draft using the customer's ticket history and product documentation, then require human approval before sending.

The second definition gives engineers something they can actually architect, test, and measure.

Evaluate Data Readiness

For most AI systems, data is a bigger constraint than model availability.

Before development, check:

Availability: Does the required data exist?
Quality: Is it accurate, consistent, and complete?
Accessibility: Can the application retrieve it reliably?
Freshness: How frequently does it change?
Structure: Is the data usable without extensive transformation?
Security: Can it legally and safely be exposed to the AI workflow?

For RAG-based systems, for example, simply having thousands of documents is not enough.

You also need a reliable ingestion pipeline, appropriate chunking, metadata, retrieval strategy, and access control.

A technically impressive RAG architecture built on unreliable source data will still produce unreliable answers.

Check Integration Readiness

AI rarely operates as an isolated component.

A production AI feature usually needs to interact with existing systems such as:

CRM or ERP platforms
Internal APIs
Databases
Authentication services
Document storage
Event queues
Third-party SaaS platforms

Evaluate whether these systems provide stable interfaces and sufficient access to the required data.

Pay particular attention to:

API rate limits
Authentication and authorization
Latency
Failure handling
Data synchronization
Legacy system constraints

If critical data is trapped inside an unreliable legacy system, the problem is not your LLM. The integration layer is the actual bottleneck.

Assess Infrastructure and Architecture

The infrastructure requirements depend heavily on the AI workload.

A simple API-based LLM feature may only require an application backend, while a more complex system could involve:

Client
↓
Application API
↓
AI Orchestrator
├── LLM
├── Vector Database
├── Business APIs
└── Tool / Function Calls
↓
Response + Observability

Before implementation, determine:

Where models will run
Where data will be stored
Whether GPUs are required
Expected request volume
Latency requirements
Scaling strategy
Availability requirements
Provider dependency and fallback options

Avoid over-engineering the first version.

A managed LLM API may be the right choice for an early production workload. Self-hosting becomes more attractive when requirements around cost, latency, data residency, model customization, or scale justify the additional operational complexity.

Treat Security as an Architecture Concern

AI introduces attack surfaces that traditional applications may not have.

An AI readiness assessment should consider:

PII and sensitive data handling
Model and API access control
Prompt injection
Data leakage
Secrets management
Tenant isolation
Audit logging
Output validation

Do not assume that an LLM understands your application's authorization model.

For example, if a user can only access documents belonging to their organization, the retrieval layer must enforce that constraint. It should not rely on the model to “remember” the rule.

Authorization belongs in the application architecture, not in the prompt.

Define Evaluation Before Development

A traditional application can often be tested against deterministic expected outputs.

AI systems are different.

The same input can produce multiple valid responses, and “looks good in a demo” is not a measurable quality standard.

Before building, define:

Evaluation datasets
Accuracy or relevance metrics
Hallucination criteria
Safety requirements
Latency targets
Acceptable failure rates
Human evaluation criteria

A simple evaluation pipeline might look like:

Input
↓
AI System
↓
Generated Output
↓
Automated Evaluation
↓
Human Evaluation (if required)
↓
Release / Reject

This becomes especially important when changing models, prompts, retrieval strategies, or system instructions.

Without a regression evaluation set, every AI change is partly a production experiment.

Plan for Production Operations

A successful proof of concept answers:

“Can we make it work?”

A production system needs to answer:

“Can we operate it reliably?”

At minimum, monitor:

Latency
Error rates
Token usage
Cost per request
Model failures
Retrieval quality
Output quality
User feedback

Version prompts, system instructions, model configurations, and evaluation datasets just as you would version application code.

Also design explicit fallback paths.

For example:

Primary LLM
↓
Failure / Timeout
↓
Fallback Model
↓
Human Escalation

The goal is not to eliminate every AI failure. The goal is to contain failures so they do not become system failures.

A Practical AI Readiness Checklist

Before starting implementation, engineering teams should be able to answer “yes” to most of these questions:

If several answers are “no,” building the AI feature immediately may create more technical debt than business value.

The engineering layer is only part of the equation; this AI Readiness Assessment looks at the organizational, data, and business factors that also determine whether an AI initiative is ready to move forward.

From Readiness Assessment to Production

AI readiness is not about achieving a perfect score.

It is about identifying the constraints that could prevent an AI system from delivering reliable value.

A practical path is:

Assess
↓
Identify Gaps
↓
Prioritize Use Case
↓
Design Architecture
↓
Build PoC
↓
Evaluate
↓
Harden
↓
Deploy
↓
Monitor & Iterate

The most important decision is often not which AI model to use, but whether the surrounding system is ready to use one effectively.

Good AI engineering starts before the first API call.