Hello. I am Joebert, a development engineer.
This time, I implemented conditional NFT minting logic using LINE Mini Dapp and the Kaia blockchain.
While Web2–blockchain integration is increasing, practical questions only become clear during implementation.
- How should Web2 authentication and wallets be handled
- How should a condition be converted into on chain processing
- How stable can session management realistically be
To explore this, I built a minimal prototype and verified whether the entire flow from login to NFT minting and confirmation could complete inside LINE.
Table of Contents
- Why I decided to build and verify this
- How I designed the system
- Challenges encountered during implementation
- What we confirmed by running it
- What I learned from building it
- Conclusion
Why I decided to build and verify this
The flow from login to minting and on chain confirmation seems straightforward. However, implementing it inside an existing Web2 infrastructure raises specific concerns.
- Where are the LINE login session and wallet connected
- When is a condition converted into a transaction
- How is wallet state handled if the session is lost
Conceptually simple does not mean implementation is simple. Rather than reviewing specifications, I assembled a working prototype on the Kairos testnet and verified the full flow inside LINE Mini Dapp.
The goal was to confirm what works and where adjustments are required.
How I designed the system
The key priority was to treat Web2 authentication and Web3 wallets as a continuous structure.
In LINE Mini Dapp:
- LIFF SDK handles LINE login
- This provides the Web2 identity layer
NFT minting requires a blockchain wallet. The challenge was connecting these layers without breaking ID continuity.
To solve this:
- Initialize DappPortalSDK within the LIFF session
- Retrieve wallet using kaia_requestAccounts
Flow:
- Confirm login via LIFF
- Initialize DappPortalSDK
- Retrieve wallet address
This allows login and wallet acquisition within a single session. Blockchain functionality becomes an extension of the LINE account.

Designing the flow from condition to mint
Game victory is determined on the frontend. When confirmed, sendReward is triggered.
Processing is divided into two stages:
- User executes kaia_sendTransaction
- Server wallet performs mint
The user approves once. Mint logic is controlled on the service side.
This ensures:
- Users do not directly operate smart contracts
- Mint logic remains centrally controlled
NFT retrieval design
Minted NFTs are retrieved directly from the smart contract without external APIs.
Methods used:
- balanceOf
- tokenOfOwnerByIndex
- tokenURI
Metadata is fetched from IPFS. The structure relies purely on on chain state to keep it simple.
Design assumptions
This prototype:
- Runs on Kairos testnet
- Uses a server wallet for minting
- Stores a private key in frontend for verification
It differs from a production security design. The objective was structural validation.
Challenges encountered during implementation
Most implementation time was spent on Web2–Web3 integration rather than blockchain logic.
1. DappPortalSDK domain restrictions
What worked on localhost failed after deployment.
- DappPortalSDK.init succeeded
- kaia_requestAccounts did not respond
The cause was Reown domain whitelisting.
- Localhost is exempt
- Production domains must be registered

This issue was infrastructure related rather than blockchain logic.
2. LIFF Webview session instability
Within LIFF Webview:
- localStorage behavior was unstable
- Wallet address occasionally disappeared
- LINE login remained active
Defensive measures:
- Reinitialize SDK per page
- Reacquire account if empty

Single initialization was insufficient.
3. Mint processing assumptions
Minting is executed by a server wallet.

This reduces multiple gas approvals but introduces security assumptions.
For testing:
- Private key stored in frontend•
In production:
- Must move to backend
Additionally:
- tokenURI reused totalSupply minus one
- Caused metadata duplication

These issues became clear only after implementation.
What we confirmed by running it
The full flow completed inside LINE Mini Dapp.
- LINE login
- Wallet acquisition
- Condition achievement
- Transaction execution
- Server wallet mint
- On chain confirmation
- NFT display
After walletProvider.request:
- Transaction approval UI appears in LIFF
- User confirms
- Processing continues

Minted NFTs were confirmed on Kairos testnet.

NFTs were retrieved on chain and displayed in the app.

The integrated structure functioned end to end.
What I learned from building it
Conditional NFT minting can function within Web2 infrastructure.
However, complexity lies in:
- Domain configuration
- Session management
- SDK initialization timing
- Mint responsibility separation
The key issue is where Web2 and Web3 connect. Server wallet minting simplifies UX but requires secure backend key management in production. The overall structural direction has been validated.
Conclusion
This structure can also apply to certification models such as completion or graduation certificates. By replacing the condition logic with criteria such as credit acquisition or program completion, the same issuance-to-verification flow can be designed. A minimal prototype using a graduation certificate as the primary use case is explained in detail in "How Are NFT Diplomas Implemented? Explaining the System Based on a Prototype Implementation" Rather than remaining conceptual, building the system directly revealed practical assumptions and design considerations that are not immediately visible in theory. We hope this article serves as a useful reference when considering integrated system design.



