A Non-Custodial Locking System That Stays Within Your Own Wallet

This system is a technical explanation of the “Miyako Pad” non-custodial token locking system that is actually adopted in
This is a technical explanation of the non-custodial token locking system actually adopted in Miyako Pad. In Miyako Pad, we have introduced a design that allows users to lock tokens they have purchased for a certain period while keeping them in their own wallets.

🏁 Introduction: Why did we adopt a 'lock without depositing' approach?

The mechanism of token locking is an essential element for operating Web3 projects, such as vesting and investor protection. In particular, locking team tokens and initial investment portions is important to ensure the transparency and reliability of a project.

However, many locking systems are based on the premise of depositing tokens into a dedicated contract. In other words, it is a structure where
locking = moving tokens out of the wallet. This act of 'depositing' inevitably involves
custody risk (the risk of depending on a third party).

Born from this question is the non-custodial locking system.

In this mechanism, while keeping the tokens in your own wallet, we have designed it to issue
non-transferable NFTs (SBTs) as proof of lock and to impose restrictions during transfers.

Currently, this non-custodial lock is actually in operation for
MIYAKO tokens and TBCZ tokens (The Boost Coffee Project). In actual operation, it functions as a mechanism that
combines reliability and security.

🧩 Overview of the mechanism: What does it mean to lock without depositing?

In conventional locking systems, the following flow is common.

1. Send tokens to a dedicated contract (= deposit)

2. Wait until the lock period ends

3. Withdraw from the contract after the period

In this structure, because the lock contract holds the assets completely,
if there is a bug or vulnerability, there is a problem that there is a high risk of being unable to retrieve the tokens.

On the other hand, this mechanism is different. Tokens always remain in the user's wallet. Instead, we issue a “

lock proof NFT (non-transferable)” and refer to this NFT during transfers to impose restrictions.

⚙️ Implementation mechanism: Composed of 3 elements

1. Lock-compatible tokens

Add 'transfer control logic' to standard ERC20 tokens. By checking the lock NFT present in the wallet, we ensure that
only the amount excluding the locked amount can be transferred. (In transfer processing, it is designed so that a token balance exceeding the locked amount is always maintained, and transfers that would fall below the locked amount are not executed.)

2. Lock proof NFT (Soulbound Token)

The following information is recorded in the NFT.

• Locked token amount

• Lock period (deadline)

• Issuer/Holder

This NFT is non-transferable (SBT specification), and no operations other than burning (deletion) are possible.
Unlocking is performed by burning after the deadline has passed.

3. Lock aggregation module

Even if a user has multiple lock NFTs,
it references all NFTs to "total locked amount" dynamically calculated.
Control during token transfers is always kept accurate.

🔄 Actual usage flow

🔒 When locking

1. "Specify 1000 tokens locked for 4 years"

2. Lock proof NFT is automatically issued

3. Tokens remain in the wallet, but 1000 tokens cannot be transferred

🔓 When unlocking

1. After 4 years have passed, burn the NFT

2. All tokens become freely movable again

👀 How it looks on the wallet

• Token balance: 5,000

• Lock proof NFT: 1,000 tokens, locked for 4 years

• Transferable amount: 4,000

🧠 Technical points

✅ Realization of non-custodial

• Token ownership always remains with the user

• Only 'constraint information' is recorded in the contract

• Effective locking is achieved by referencing the lock NFT to apply controls during transfers

✅ Supports multiple locks

• Lock 500 tokens for 1 year (NFT #1)

• Lock 300 tokens for 4 years (NFT #2)
  → Total of 800 tokens treated as locked
  → Each NFT can be burned independently

✅ Easy-to-read NFT metadata

The following information is stored in the NFT metadata.

{
  "lockedAmount": "1000",
  "unlockDate": "2028-12-31",
  "remainingDays": "45",
  "token": "MIYAKO"
}

You can check the remaining days on platforms like OpenSea, allowing you to visually manage the lock status.

🧪 Operation test results

Case 1: Basic lock

• Token balance: 5000

• Lock 1000 tokens for 4 years
  → Lock proof NFT issued
  → Transferable: 4000
  → ✅ Works as intended

Case 2: Multiple locks

• Lock 500 tokens (4 years) + 300 tokens (1 year)
  → Total 800 token limit
  → ✅ Aggregated correctly

Case 3: Burn after expiration

• Cannot be deleted before the period ends

• Can be deleted after the period ends
  → ✅ Expiration management is accurate

💡 Insights from actual operation

🧭 Peace of mind with non-custodial

The structure of "not depositing" but simply "having constraints"
provides more peace of mind to users than one might imagine.
It does not depend on management or contracts,and the ability to always check the balance in your own walletis a distinctive feature.

🎨 The effect of visualization via NFTs

• "What is currently locked" can be seen at a glance

• Can be verified on OpenSea

• Lock duration can be expressed through color or progress depending on the UI

The only challenge is thereduced visibilitywhen the number of NFTs increases.
UX improvements (such as filtering or duration display UI) are the next points for refinement.

🚀 Potential applications and future developments

Assumed use cases

• Token sale purchaser lock
  Locking while retaining ownership → Balancing reliability and transparency

• Transparency for team tokens
  Locking in each management member's own wallet → Peace of mind for the community

• Community benefits and access control
  Utilizing NFTs as proof, such as for "channels limited to people who have locked a certain amount of tokens."
  This mechanism is actuallyMiyako Pad also incorporated into the Discord Bot.
  The Bot verifies the wallet address andrecognizes users who have locked a certain amount (160,000 or more) of TBCZ tokens.For users who meet the criteria, it
  grants a dedicated rolewithin Discord, opening access to the "locked holder exclusive channel."

  
  

Improvement ideas

• Lock extension option

• Gas efficiency (aggregation and NFT management)

• Dynamic NFT conversion (image changes according to remaining days)

🔮 Summary: Balancing functionality and trust

"Non-custodial locking" is a mechanism that balances
"the freedom of self-custody" and "safe constraints", which are the origins of Web3.

This mechanism is already in actual operation with MIYAKO tokens and TBCZ tokens.
Through actual operation, we were able to confirm the following values.

• Peace of mind from not depositing

• Transparency through NFTs

• Flexible scalability

These elements realize a level of reliability and operability not found in existing lock models.

For token sales, DAO governance, community design, etc., I feel that the concept of
sharing constraints without depositing has the potential to play an important role in the future of Web3.

Next time, I plan to introduce some more technical aspects for Zenn/Mirror as well.