Token Unlock اور Vesting معلومات کیسے تصدیق کریں؟

Token unlock calendar صرف ایک اشارہ ہے، ثبوت نہیں۔ قابلِ اعتماد نتیجہ تب بنتا ہے جب project کی تحریری allocation، deployed contract کے parameters، beneficiary wallets، chain پر release events اور circulating-supply methodology ایک دوسرے سے مل جائیں۔ اگر ان میں سے کوئی کڑی غائب ہو تو صحیح جواب “نامعلوم” ہو سکتا ہے؛ تاریخ یا رقم گھڑ کر خلا پُر کرنا تحقیق نہیں۔

یہ رہنمائی اس قاری کے لیے ہے جو کسی meme coin کا اگلا unlock دیکھ کر یہ جاننا چاہتا ہے کہ تاریخ واقعی کس واقعے کی ہے، کتنی units قابلِ دعویٰ ہوں گی، اور tracker کا عدد کس evidence پر کھڑا ہے۔ مقصد price prediction نہیں بلکہ ایسی verification note بنانا ہے جسے دوسرا شخص انہی sources سے دوبارہ جانچ سکے۔

اس رہنمائی میں کیا ملے گا؟

1. Document، contract اور chain evidence کی درجہ بندی
2. Allocation table کو قابلِ حساب ledger میں بدلنے کا طریقہ
3. Cliff، linear vesting، claim اور transfer کا فرق
4. EVM اور Solana tokens کے لیے الگ verification راستے
5. Timezone، timestamp اور calendar-date کی غلطیاں
6. Circulating supply کے denominator کی جانچ
7. دو sources کے اختلاف کو حل کرنے کا طریقہ
8. Event کے بعد دوبارہ verification اور آخری checklist

مختصر جواب: کسی unlock کو قابلِ اعتماد کیسے مانیں؟

کسی unlock کو قابلِ اعتماد ماننے کے لیے کم از کم چار باتیں ایک ساتھ ثابت کریں: درست asset identity، versioned official schedule، chain پر قابلِ شناخت vesting mechanism یا wallets، اور واضح supply denominator۔ Calendar site ان چاروں کی جگہ نہیں لے سکتی۔ وہ تحقیق شروع کرنے کے لیے مفید ہے، مگر حتمی رقم اور تاریخ primary evidence سے نکالنی چاہیے۔

ایک مضبوط note ہر دعوے کو ان چار labels میں رکھتی ہے:

Label	اس میں کیا آتا ہے؟	confidence
Documented	official paper، tokenomics page، governance proposal	plan کی حد تک
Configured	deployed contract کے start، duration، cliff، owner، beneficiary	mechanism کی حد تک
Observed	release event، transfer، current balance، supply snapshot	مخصوص block یا وقت تک
Inferred	unlock ratio، recipient behavior، possible sell pressure	assumptions کے مطابق

ان labels کو ملانا سب سے عام غلطی ہے۔ Documented allocation کو observed balance نہ کہیں، اور wallet transfer کو sale نہ لکھیں۔

Step 1: پہلے asset identity بند کریں

ایک جیسے ticker والے tokens عام ہیں، اس لیے نام سے تحقیق شروع نہ کریں۔ Chain، contract یا mint address، decimals، token program اور bridge model لکھیں۔ Official website یا repository میں دیا address پہلے source کے طور پر رکھیں، پھر explorer سے match کریں۔

EVM token میں proxy ہو تو proxy اور implementation دونوں addresses نوٹ کریں۔ Solana token میں mint account بنیادی identity ہے۔ Solana کی سرکاری Get a Token Mint رہنمائی بتاتی ہے کہ current supply، authority اور decimals جاننے کے لیے token mint account پڑھا جاتا ہے۔ یہ fields allocation schedule نہیں بتاتے، مگر غلط mint یا غلط decimals کے باعث ہونے والی پوری calculation کو بچاتے ہیں۔

Step 2: Official schedule کا version محفوظ کریں

Whitepaper، tokenomics page، governance proposal اور announcement الگ documents ہیں۔ ہر source کے ساتھ title، URL، publication یا update date، relevant page اور access time محفوظ کریں۔

اس مضمون کا cover official BONK Paper کے printed Page 8 کا حقیقی render ہے۔ اس میں early contributors کے لیے 21% allocation اور 1 January 2023 سے تین سالہ linear vesting لکھی ہے۔ یہ historical documented plan ہے۔ اس تصویر سے آج کا locked balance، beneficiaries کے موجودہ addresses یا actual claims ثابت نہیں ہوتے۔

Schedule پڑھتے وقت ہر allocation کے لیے یہ columns بنائیں:

Field	سوال
Allocation	کتنی units اور total supply کا کتنا فیصد؟
Recipient class	team، investor، treasury، contributor یا community؟
TGE release	launch پر کتنی units دستیاب تھیں؟
Start	vesting کس تاریخ یا timestamp سے شروع ہوئی؟
Cliff	پہلی releasable amount سے پہلے کتنی مدت؟
Curve	linear، monthly tranche، milestone یا discretionary؟
End	مکمل vesting کب ختم ہوتی ہے؟
Control	contract، multisig، custodian یا ordinary wallet؟
Amendment	بعد میں کوئی proposal یا migration ہوئی؟

Percentages کا مجموعہ 100% نہ بنے تو اپنی طرف سے balancing bucket نہ بنائیں۔ Rounding، missing category یا changed supply کو unresolved discrepancy لکھیں۔

Step 3: “Linear vesting” کا اصل contract behavior دیکھیں

Linear کا مطلب صرف یہ ہے کہ vested amount وقت کے ساتھ ایک curve کے مطابق بڑھتی ہے؛ یہ ضروری نہیں کہ ہر دن token transfer ہو۔ Claim کسی بھی وقت ہو سکتا ہے، اور کچھ implementations vested balance مسلسل calculate کرتی ہیں مگر actual release کبھی کبھار ہوتا ہے۔

اوپر حقیقی OpenZeppelin VestingWallet documentation ہے، جسے 2026-08-17T13:20:15+08:00 پر محفوظ کیا گیا۔ Documentation کے مطابق wallet ERC-20 assets کو beneficiary کے لیے schedule کے مطابق release کر سکتا ہے۔ اسی reference میں ایک اہم حد بھی لکھی ہے: wallet پر Ownable لاگو ہے، اس لیے اس کا مالک بدلا جا سکتا ہے۔ لہٰذا “contract میں locked” کو خودکار طور پر “economic exposure فروخت نہیں ہو سکتا” نہ سمجھیں۔ یہ component documentation ہے، کسی مخصوص project deployment کی audit نہیں۔

Deployed contract پر کم از کم یہ functions یا equivalent state دیکھیں:

• start، duration اور end
• beneficiary یا owner
• released اور releasable
• vestedAmount یا release formula
• cliff parameter یا custom curve
• proxy implementation اور upgrade admin
• ownership transfer، pause یا emergency recovery controls

Function کا نام کافی نہیں۔ Verified source، constructor arguments اور current storage values ایک ساتھ دیکھیں۔ Contract clone یا proxy ہو تو explorer میں دکھنے والا source implementation سے match ہونا چاہیے۔ OpenZeppelin Access Control documentation roles، ownership اور privileged operations سمجھنے کے لیے مفید ہے، مگر deployed roles پھر بھی chain سے پڑھنے پڑتے ہیں۔

Step 4: Cliff، accrual، claim اور transfer الگ events ہیں

Cliff ختم ہونا vesting accrual کی شرط ہو سکتی ہے، مگر claim transaction اسی لمحے ضروری نہیں۔ چار timestamps الگ رکھیں:

1. Vesting start: formula کب چلنا شروع ہوا؟
2. Cliff end: پہلی بار amount releasable کب ہو سکتی ہے؟
3. Claim/release: beneficiary نے contract سے token کب نکالے؟
4. Market movement: token exchange، DEX یا دوسرے wallet کی طرف کب گیا؟

اگر tracker “next unlock” لکھتا ہے تو پوچھیں کہ وہ ان چار میں سے کس event کو دکھا رہا ہے۔ Monthly marker صرف reporting convention ہو سکتی ہے جبکہ contract ہر second vested amount calculate کرتا ہو۔ اسی طرح scheduled date گزرنے کے باوجود claim نہ ہو تو tokens technically vested مگر contract میں موجود رہ سکتے ہیں۔

ERC-20 کے لیے EIP-20 totalSupply() اور Transfer event کی بنیادی semantics دیتا ہے۔ Zero address سے transfer نئی mint کی علامت ہو سکتی ہے؛ vesting wallet سے beneficiary transfer existing units کی release ہو سکتی ہے۔ دونوں کو ایک ہی “unlock” label دینا supply analysis خراب کرتا ہے۔

Step 5: Calendar date کو chain timestamp میں کیسے ملائیں؟

Date-only disclosure جیسے “1 January” میں ساعت اور timezone شامل نہیں ہوتے۔ اپنی طرف سے midnight UTC فرض کرنا درست نہیں۔ Source نے timezone نہ دیا ہو تو اسے unresolved لکھیں اور کم از کم 24 گھنٹے کی observation window رکھیں۔

یہ حقیقی Solidity 0.8.31 documentation ہے، جسے 2026-08-17T16:34:41+08:00 پر محفوظ کیا گیا۔ تصویر میں block.timestamp کو Unix epoch کے بعد seconds کے طور پر دکھایا گیا ہے۔ Contract کا numeric timestamp پڑھ کر اسے UTC اور قاری کے مقامی وقت دونوں میں تبدیل کریں، مگر raw value بھی محفوظ رکھیں۔ Screenshot کسی project کی release date ثابت نہیں کرتی؛ یہ صرف EVM time field کی documented meaning دکھاتی ہے۔

Block timestamp کو calendar کے exact execution guarantee کے طور پر بھی نہ لکھیں۔ Contract شرط پوری ہوتے ہی release ممکن کر سکتا ہے، مگر کسی account کو transaction بھیجنی پڑ سکتی ہے۔ Chain congestion، keeper failure یا beneficiary delay actual transaction کو بعد میں لے جا سکتے ہیں۔

Step 6: Wallet mapping میں نام نہیں، evidence لکھیں

Unknown address کو “team wallet” کہنے سے پہلے project disclosure، contract beneficiary، governance execution یا معتبر explorer label تلاش کریں۔ Community spreadsheet useful lead ہو سکتی ہے، identity proof نہیں۔ ہر mapping کو confidence دیں:

• Confirmed: official address disclosure اور chain state دونوں match
• Strongly supported: contract beneficiary یا governance transaction سے تعلق واضح
• Tentative: explorer label یا repeated transaction pattern، مگر primary disclosure نہیں
• Unknown: صرف بڑا balance یا timing similarity

Holder list بھی مکمل story نہیں۔ Exchange omnibus wallet میں ہزاروں users کے balances جمع ہو سکتے ہیں؛ liquidity pool، burn address، bridge vault اور vesting contract کو ordinary whale سے الگ کریں۔ Etherscan کی Token Holder List API documentation address اور balance دیتی ہے، business identity نہیں۔ اسی لیے balance ranking سے affiliation اخذ نہ کریں۔

Step 7: Release transaction کو کیسے پہچانیں؟

Expected window میں contract events اور token transfers دونوں دیکھیں۔ EVM پر transaction hash، block number، log index، from، to، raw amount اور decimals محفوظ کریں۔ Etherscan کی Get Event Logs documentation address، topics اور block range سے logs پڑھنے کا طریقہ دکھاتی ہے۔ Explorer UI آسان ہے، مگر raw event fields note میں رکھنا بعد کی verification کو بہتر بناتا ہے۔

ایک transfer کے کئی ممکنہ معنی ہیں:

• vesting contract سے beneficiary کو claim
• treasury سے operating wallet کو internal move
• bridge vault میں deposit
• liquidity pool میں provision
• centralized exchange deposit
• ordinary wallet rotation

صرف amount schedule کے قریب ہو تو release ثابت نہیں ہوتا۔ From address، function call، emitted event اور beneficiary mapping ملائیں۔ Exchange deposit بھی final sale کا مکمل ثبوت نہیں؛ centralized venue کے اندر order execution public chain پر نظر نہیں آتی۔

Step 8: Circulating supply denominator خود verify کریں

Unlock ratio عموماً اس formula سے نکلتا ہے:

Release-to-circulating ratio = releasable units ÷ pre-event circulating supply × 100

یہ arithmetic آسان ہے، denominator مشکل ہے۔ CoinGecko Supply Methodology locked، vested، team اور بعض treasury wallets کے treatment کی وضاحت کرتی ہے۔ CoinGecko کی الگ Supply Update FAQ میں multiple chains اور bridge accounting کے مختلف cases ملتے ہیں۔ Provider کے displayed number کے ساتھ methodology، retrieval time اور chain scope محفوظ کریں۔

فرضی مثال: ایک tracker کے مطابق اگلی releasable tranche 24 million units ہے۔ Provider A کا pre-event circulating supply 600 million ہے، اس لیے ratio 4% بنتا ہے۔ Provider B اگر 540 million دکھاتا ہے تو ratio تقریباً 4.44% ہوگا۔ Schedule ایک ہی ہے؛ فرق denominator میں ہے۔ دونوں outputs لکھیں اور اختلاف کی وجہ تلاش کریں، کسی ایک کو خاموشی سے “صحیح” نہ چنیں۔

On-chain totalSupply circulating supply نہیں۔ Mint authority، burn، bridge backing، treasury control اور locked wallets الگ layers ہیں۔ Arithmetic منظم کرنے کے لیے token dilution tool استعمال کیا جا سکتا ہے، مگر tool input کی authenticity verify نہیں کرتا۔ Supply definitions کی تفصیل circulating بمقابلہ total supply میں الگ دی گئی ہے۔

Step 9: دو sources مختلف ہوں تو فیصلہ کیسے کریں؟

اختلاف کو error سمجھ کر فوراً ختم نہ کریں۔ پہلے یہ matrix بھریں:

Check	Source A	Source B
Asset address
Document version
Chain scope
Timestamp/timezone
Allocation bucket
Unlock event definition
Circulating methodology
Decimals/rounding

عام وجوہات میں revised schedule، date-only timezone assumption، linear accrual کو monthly batch میں دکھانا، claim کے بجائے vesting date دکھانا، multi-chain double counting اور stale provider cache شامل ہیں۔ Resolution نہ ملے تو range دیں۔ مثال: “Official document 24 million planned units دکھاتا ہے، مگر deployed contract parameters independently verify نہیں ہوئے؛ calendar number provisional ہے۔”

Marketing post نئی تاریخ دے مگر contract immutable ہو تو contract state اہم evidence ہے۔ دوسری طرف upgradeable contract یا governance-controlled migration میں later execution transaction واقعی mechanism بدل سکتی ہے۔ ہمیشہ authority path دیکھیں۔

Step 10: Event کے بعد verification بند نہ کریں

اچھی unlock research دو snapshots رکھتی ہے: event سے پہلے اور بعد۔ Pre-event snapshot میں contract balance، releasable amount، circulating denominator، holder concentration اور relevant liquidity محفوظ کریں۔ Post-event snapshot میں actual release transaction، beneficiary balance، provider supply update اور subsequent movements دیکھیں۔

یہ follow-up windows مفید ہیں:

• event window: raw contract/event evidence
• 24–72 گھنٹے: delayed claim اور provider update
• 7 دن: recipient transfers اور supply reconciliation
• 30 دن: schedule amendment یا repeated batch pattern

یہ intervals universal rule نہیں؛ chain اور mechanism کے مطابق بدلیں۔ انہیں prediction نہ بنائیں۔ مقصد یہ دیکھنا ہے کہ documented plan، configured mechanism اور observed outcome کہاں ملے یا الگ ہوئے۔

ایک مکمل verification note کی مثال

فرضی case میں official PDF 120 million units کی 24 ماہ linear vesting بتاتی ہے۔ Deployed contract کا start اور duration document سے match کرتے ہیں، مگر beneficiary mapping صرف دو addresses کے لیے confirmed ہے۔ Specific observation time پر contract releasable 5 million دکھاتا ہے؛ اسی window میں 4.8 million کی release transaction ملتی ہے۔ Provider A circulating supply 700 million اور Provider B 680 million دکھاتے ہیں۔

اس note کا دفاعی نتیجہ یہ ہوگا:

• Documented: 120 million allocation، 24 ماہ linear schedule
• Configured: start اور duration match؛ owner/admin path الگ درج
• Observed: 4.8 million actual release، block اور transaction hash محفوظ
• Calculated: ratio تقریباً 0.69% تا 0.71%، provider methodology کے لحاظ سے
• Unresolved: باقی beneficiary identities اور 0.2 million difference

غلط نتیجہ یہ ہوگا: “5 million unlock ہوا، اس لیے price ضرور گرے گی۔” Verification supply availability بتاتی ہے، market outcome نہیں۔ Liquidity اور recipient behavior کے لیے unlock اور dilution analysis الگ layer فراہم کرتی ہے۔

Red flags جن پر confidence کم کرنا چاہیے

• Calendar amount کے ساتھ primary source link نہ ہو
• Whitepaper کا version یا publication date معلوم نہ ہو
• Contract یا mint address official source سے match نہ ہو
• “Locked” wallet ordinary externally owned account ہو اور control نامعلوم ہو
• Proxy implementation یا upgrade admin چھپا ہو
• Cliff اور vesting start کو ایک ہی event لکھا گیا ہو
• Date دکھائی جائے مگر timezone یا event definition نہ دی جائے
• Holder identity صرف balance size سے اخذ کی گئی ہو
• Multi-chain supply کو bridge backing دیکھے بغیر جمع کیا گیا ہو
• Released کو sold یا exchange deposit کو final sale کہا گیا ہو
• Tracker methodology یا last update time دستیاب نہ ہو
• Project amendment کا دعویٰ کرے مگر governance یا chain execution نہ دکھائے

ایک red flag fraud کا قطعی ثبوت نہیں۔ یہ صرف بتاتا ہے کہ claim کے لیے زیادہ evidence درکار ہے۔ کئی unresolved red flags ہوں تو exact رقم کے بجائے uncertainty range دیں یا فیصلہ مؤخر کریں۔

آخری checklist

• Chain، contract یا mint address official source سے match ہیں
• Decimals اور token program verify ہیں
• Schedule کا version، page، URL اور access time محفوظ ہے
• Allocation percentage اور token amount دونوں reconcile ہوتے ہیں
• Start، cliff، curve، end اور timezone الگ لکھے گئے ہیں
• Contract source، parameters، proxy اور admin path دیکھا گیا ہے
• Beneficiary mappings کے ساتھ confidence labels ہیں
• Vesting، claim، transfer، mint اور sale الگ events ہیں
• Raw timestamp، block number اور transaction hash محفوظ ہیں
• Circulating denominator کی methodology اور retrieval time درج ہیں
• Bridge یا multi-chain double counting check ہوئی ہے
• Conflicting sources کو range یا unresolved note کے ساتھ دکھایا گیا ہے
• Event کے بعد follow-up snapshot مقرر ہے
• نتیجہ price guarantee یا deterministic forecast نہیں بناتا

عام سوالات

کیا unlock calendar کافی ہے؟

نہیں۔ Calendar research lead ہے۔ Primary document، deployed mechanism، chain event اور supply methodology کے بغیر رقم یا تاریخ provisional رہتی ہے۔

کیا cliff ختم ہوتے ہی پوری allocation نکلتی ہے؟

ضروری نہیں۔ کچھ schedules accrued amount ایک ساتھ releasable کرتی ہیں، کچھ cliff کے بعد vesting شروع کرتی ہیں، اور کچھ milestone-based ہیں۔ Contract formula یا binding document فیصلہ کرتا ہے۔

کیا vesting مکمل ہوتے ہی tracker کا circulating عدد بڑھ جاتا ہے؟

ضروری نہیں۔ Vested، releasable، claimed اور public float ایک ہی حالت نہیں، جبکہ data services مختلف wallet exclusions استعمال کر سکتی ہیں۔ متعلقہ provider کی policy دیکھیں۔

کیا transfer event sale ثابت کرتا ہے؟

نہیں۔ Claim، custody move، bridge deposit یا liquidity provision بھی transfer پیدا کر سکتے ہیں۔ Sale کے لیے transaction route اور venue evidence الگ چاہیے۔

اگر contract source verified نہ ہو تو کیا کریں؟

Confidence کم کریں۔ Bytecode analysis specialist کام ہے؛ عام قاری کو exact schedule کے بجائے “contract mechanics independently unverified” لکھنا چاہیے۔

آخری احتیاط

Token unlock verification کا اچھا نتیجہ کوئی دلکش countdown نہیں بلکہ timestamped evidence ledger ہے۔ Documented plan، configured mechanism، observed chain state اور inferred market effect کو الگ رکھنے سے غلط certainty کم ہوتی ہے۔ جو بات verify نہ ہو اسے واضح طور پر نامعلوم لکھیں؛ assumptions کو live data کے طور پر پیش نہ کریں۔ Meme coins میں قیمت بہت تیزی سے بدل سکتی ہے، liquidity محدود اور control چند addresses میں مرتکز ہو سکتا ہے؛ لگایا ہوا پورا سرمایہ بھی ختم ہو سکتا ہے۔

یہ مواد تعلیمی ہے، مالی مشورہ نہیں۔ اہل صارف اپنی صوابدید پر بائنانس دعوتی کوڈ BN8812 استعمال کر سکتا ہے۔ سائٹ آپریٹر کے مطابق اسپاٹ ٹریڈنگ فیس پر زیادہ سے زیادہ 20% رعایت ممکن ہے؛ اصل شرح، اہلیت، علاقائی دستیابی اور موجودہ شرائط بائنانس پر خود تصدیق کریں۔