Hey there myself Aki and I am founder and Lead Architect of Luxvoid-Project Monolith. I have already mapped out the whole project, it’s branches it’s technically ends etc, since my project includes a lot of physical asset involvement and attention and originally I do not have web3 development knowledge. Project is mammoth if we deep dive and I am more than happy to share more technical information and in depth walkthrough. I am looking for profesionnal expertise to handle the backend technical job on already laid out map with rock solid foundation. Project is not limited to just one chain, the project will commence on high scale EVM chain parallel but choosing and building core on Nervos because it aligns with nervos ideology and my business niche perfectly. I am not looking for help or handout, I want who understand CKB inside out because I deal in precious metals and can’t afford no crack from get go. I am open to discuss more and about @ckb-support@doitian@quake official team support, and I am open for all the options, if any individual native reputed original CKB developer wanna jump in sure we can talk, set and work terms etc. I am definitely not looking for a handout or some money to work myself I would rather lean entirely towards technical support, for which we can discuss terms moving forwards.TIA
Thanks for the questions. Here is the technical breakdown:
What specific components run on CKB L1: The core ownership record, the cryptographic serial number tied to the physical NFC chip, and the asset’s current state (e.g., primary owner vs. secondary market).
RGB++ / Cell model vs. base UTXO: We are utilizing the Cell model for state tracking, and RGB++ for isomorphic binding. A top EVM chain is already waiting to handle our liquidity and tokenomics; we need RGB++ to bridge our physical CKB anchors to that EVM liquidity without standard bridge vulnerabilities.We will also be using Spore NFT for NFT digital twin feature and online certificate.
Custom contract logic vs. off-chain infrastructure: Off-chain (Supabase/React) handles the UI and the 4K video CDN. We need custom L1 contract logic to enforce our “Re-Mint” protocol—locking the digital utility when the physical asset changes hands until a secondary market fee is paid on-chain.
Current architectural stage: Frontend, off-chain architecture, domains, and patents are secured. Physical Masterpiece Cryptographic Piece prototypes are in-hand and ready for the PDAC convention next week. We just need the right CKB dev to wire the L1 backend.
I tried including youtube video link but was denied error
That video shall help align the vision.
Let me know if you want to look under the hood or any more insights.
Thanks for the thoughtful questions. Just got back from PDAC—long days, but good momentum. Let me address each point:
NFC binding
Prototype uses static ID for demonstration purposes only. Production units will use true cryptographic circuitry with challenge–response. We’re currently sourcing custom chips that support this. No static IDs in final product—every tap generates a unique signature tied to that specific asset. ( Working on sourcing and will get it, it’s matter of time)
Re-Mint enforcement
Enforced at CKB script level. The asset’s digital utility lives in a cell that remains locked until the Re-Mint fee is paid. Transaction either includes the fee or fails. No bypass, no oracle, no trust.
Re-Mint enforcement is at the script level. The cell’s lock script requires a payment to the royalty address before ownership can transfer. No payment, no transfer. Rewards are epoch-based—only assets that tap during an epoch get that epoch’s rewards. Missed epochs are gone forever. This handles inheritance automatically: heir pays Re-Mint, gets current rewards only. No exceptions, no support nightmare."
RGB++ / EVM sync
We’re following the standard RGB++ locking mechanism. When bridged to EVM, the CKB cell is locked and cannot be used. When bridged back, the EVM representation is burned. No double representation possible. ( I could be wrong I ain’t sure for EVM part)