ٹوکن ڈائلیوشن اور ان لاک کا منظرنامہ

Token unlock headline دیکھ کر price crash یا harmless event کا فیصلہ نہیں کیا جا سکتا۔ یہ worksheet موجودہ circulation، scheduled release، recipient access، contract mechanics اور liquidity کو الگ evidence rows میں رکھ کر dilution scenarios بناتی ہے۔ کوئی live unlock feed یا price API موجود نہیں؛ schedule اور chain observations آپ اپنے ذرائع سے تاریخ سمیت درج کرتے ہیں۔

مختصر جواب: Dilution کس چیز کو کہتے ہیں؟

Dilution کا بنیادی سوال یہ ہے کہ موجودہ holders کے مقابل transferable یا economic supply کتنی بڑھ سکتی ہے۔ Supply growth price کو mechanical طور پر ایک مقرر فیصد نہیں گراتی۔ Demand، liquidity، recipient behavior، staking، burns اور market conditions outcome بدلتے ہیں۔ اس لیے result کو scenario کہیں، prediction نہیں۔

دو useful formulas

Potential circulation growth % = U ÷ C0 × 100

• U = وہ units جو selected period میں transferable ہو سکتی ہیں
• C0 = event سے پہلے circulating supply

Constant-market-cap implied price = M0 ÷ C1

• M0 = current market cap assumption
• C1 = event کے بعد assumed circulation

دوسرا formula demand unchanged یا market cap fixed کی guarantee نہیں۔ یہ صرف sensitivity boundary دکھاتا ہے۔

Input sheet

Schedule PDF میں لکھی allocation اور chain پر current transferable balance ایک چیز نہیں۔ دونوں کو الگ columns میں رکھیں۔

Vesting contract کیا ثابت کرتی ہے؟

یہ OpenZeppelin VestingWallet documentation کا حقیقی page capture ہے جسے اگست 2026 میں archive کیا گیا۔ Documentation reusable contract behavior سمجھاتی ہے؛ کسی project کی actual allocation یا beneficiary نہیں۔ Deployed address، constructor parameters، ownership اور token balance الگ verify کریں۔

VestingWalletCliff cliff extension کا pattern دکھاتی ہے۔ Project صرف “vesting contract” کہے تو start، duration اور cliff values کے بغیر release curve معلوم نہیں ہوتی۔

Schedule document کو version کریں

Official tokenomics page یا paper سے یہ metadata محفوظ کریں:

• exact URL/file hash
• publication/update date
• capture date
• allocation percentages اور absolute units
• supply denominator
• vesting start trigger
• cliff اور frequency
• amendment/governance clause

Percentages کا sum check کریں۔ 100% نہ بنے تو rounding، omitted bucket یا different denominator دیکھیں۔ Historical document کو current schedule نہ کہیں جب project بعد میں migration یا governance change کر چکا ہو۔

Unlock کے تین الگ states

1. Scheduled: document کے مطابق date آنا ہے۔
2. Claimable/releasable: contract calculation beneficiary کو amount لینے دیتی ہے۔
3. Transferred: chain event میں tokens wallet تک پہنچے۔

چوتھی state sold ہے، جو transfer سے خود ثابت نہیں۔ Beneficiary exchange deposit، OTC desk، staking contract، bridge یا نئے vesting wallet کو بھیج سکتا ہے۔ Event labels ملانے سے headline risk زیادہ درست بنتی ہے۔

Chain evidence کیسے جمع کریں؟

EVM token کے لیے EIP-20 Transfer event اور balance interface کا reference دیتا ہے۔ Vesting address balance، release call، recipient balance change اور event block record کریں۔ Proxy ہو تو implementation اور admin state بھی دیکھیں۔

Solana token میں official token mint guide mint supply، decimals اور authority fields پڑھنے کا طریقہ دیتی ہے۔ Program-owned vesting account اور mint authority الگ concepts ہیں۔

Evidence row میں transaction hash، block/slot، timestamp، from/to، units اور decimals لکھیں۔ Screenshot کے ساتھ raw link بھی رکھیں تاکہ بعد میں verify کیا جا سکے۔

فرضی cliff example

یہ numbers صرف worksheet demonstration ہیں:

• current circulating C0 = 20 billion
• scheduled cliff U = 4 billion

Potential growth = 4 ÷ 20 × 100 = 20%

اگر current market cap assumption M0 = 40 million USD اور post-event circulation C1 = 24 billion ہو:

Constant-M implied price = 40,000,000 ÷ 24,000,000,000 = 0.001666… USD

یہ price target نہیں۔ Market cap event کے وقت بڑھ، گھٹ یا unchanged رہ سکتی ہے۔ Tokens claim نہ ہوں یا restricted wallet میں جائیں تو actual circulating treatment مختلف ہو سکتا ہے۔

Linear vesting کو period میں بدلیں

فرض کریں allocation A، cliff کے بعد linear duration D days ہے۔ Selected window d days میں theoretical release:

Uwindow = A × d ÷ D

Start/end boundaries، already released amount اور integer rounding contract-specific ہو سکتے ہیں۔ Solidity block timestamp documentation chain time context دیتی ہے؛ legal calendar timezone اور on-chain timestamp کی interpretation الگ document کریں۔

Daily amount کو فوراً daily sell pressure نہ کہیں۔ Recipient access اور market action الگ ہیں۔

Unlock calendar سے disagreement

Third-party calendar useful discovery ہے، primary proof نہیں۔ Difference آئے تو ترتیب:

1. Official schedule version compare کریں۔
2. Contract start/cliff/duration values پڑھیں۔
3. Beneficiary addresses match کریں۔
4. Already released amount calculate کریں۔
5. Chain timestamp اور timezone دیکھیں۔
6. Migration/governance amendments تلاش کریں۔
7. Calendar methodology note پڑھیں۔

Result calendar estimate، officially documented یا on-chain observed label کے ساتھ لکھیں۔

Circulating supply provider کیا کرے گا؟

CoinGecko Supply Methodology circulating، total اور max labels کی provider rules بیان کرتی ہے۔ Unlock ہونے کے فوراً بعد provider reclassification ضروری نہیں؛ update delay یا wallet evidence review ہو سکتی ہے۔ CoinGecko Supply Update FAQ supply updates اور multi-chain cases کا context دیتی ہے۔

اپنی chain observation اور provider displayed circulation الگ رکھیں۔ دونوں کے gap کو error کہنے سے پہلے methodology پڑھیں۔

Liquidity stress worksheet

Unlock amount کو daily volume سے divide کرنا کافی نہیں؛ reported volume wash trading یا internal transfer ہو سکتا ہے۔ Real pools/order books اور executable quotes دیکھیں۔ Uniswap price impact explanation trade size اور available liquidity کے relation کی وضاحت کرتی ہے۔

Three sell scenarios بنائیں:

• unlocked amount کا 0.5%
• 2%
• 5%

ہر scenario میں route، expected output، price impact، fees اور minimum received record کریں۔ یہ recipient behavior forecast نہیں، market absorption sensitivity ہے۔

Recipient behavior کو probability نہ دیں

Team، investor، treasury یا ecosystem allocation کے incentives مختلف ہو سکتے ہیں، مگر صرف label سے sale probability نکالنا speculative ہے۔ Historical transfers، public treasury policy اور lock/re-stake evidence دیکھ سکتے ہیں، لیکن future action guarantee نہیں۔ “Sell pressure” کے بجائے transferable supply exposure زیادہ درست label ہے جب sale evidence absent ہو۔

Overlapping tranches کو ایک calendar میں لائیں

Projects میں team، private sale، ecosystem rewards اور liquidity incentives کی schedules ایک ہی مہینے overlap کر سکتی ہیں۔ ہر bucket الگ calculate کر کے total window exposure نکالیں:

Utotal(window) = Uteam + Uinvestor + Utreasury + Urewards + …

دو buckets ایک ہی wallet یا downstream contract میں merge ہوں تو duplicate نہ count کریں۔ Allocation document کے percentages کو current absolute supply پر apply کرنے سے پہلے denominator verify کریں؛ launch allocation اور migrated supply کے bases مختلف ہو سکتے ہیں۔

Calendar columns:

Schedule rows کو blindly daily amounts میں smooth نہ کریں۔ Cliff، business-day operations، multisig execution اور contract rounding actual timing بدل سکتے ہیں۔

Market-cap sensitivity کے تین neutral scenarios

Post-unlock circulation C1 معلوم ہو تو price sensitivity کو neutral labels دیں:

• Scenario A: market cap 0.75 × M0
• Scenario B: market cap 1.00 × M0
• Scenario C: market cap 1.25 × M0

ہر row میں P1 = selected M ÷ C1 لگائیں۔ 0.75/1.25 historical probability نہیں، صرف input variation ہے۔ اگر user different assumptions چاہے تو source/reason لکھے۔ “Bear/base/bull forecast” جیسے labels prediction کا غیر ضروری تاثر دیتے ہیں۔

اسی table کے ساتھ intended exit-size quotes رکھیں۔ Implied mid price مل بھی جائے تو low liquidity میں position اس rate پر sell نہیں ہو سکتی۔

Event کے بعد update protocol

Scheduled date گزرنے پر old row delete نہ کریں۔ scheduled → claimable → transferred → classified status history رکھیں۔ Chain event نہ ملے تو not observed as of [time] لکھیں، “cancelled” نہیں۔ Provider circulating number unchanged ہو تو update lag، wallet classification یا non-claiming possibilities note کریں۔

اگر project schedule بدل دے تو previous document archive، new version URL اور change summary محفوظ کریں۔ Amendment transparent ہو تو اسے deception نہ کہیں؛ مگر unannounced conflict critical evidence gap ہے۔

Multi-chain اور bridge trap

Unlocked units source chain پر bridge vault میں جائیں اور destination chain پر representation mint ہو تو دونوں balances جمع کرنا double counting ہو سکتا ہے۔ Bridge architecture، canonical token، vault balance اور wrapped supply document کریں۔ Ethereum ERC-20 overview standard token concepts دیتی ہے، bridge accounting نہیں؛ bridge-specific docs ضروری ہیں۔

Risk bands بغیر fake score

Numeric “safe score” نہ دیں۔ Evidence-based bands استعمال کریں:

• Documented: schedule اور denominator واضح
• Contract-supported: parameters deployed code سے match
• Observed: release/transfer chain پر نظر آیا
• Unresolved: identity، recipient یا scope میں gap
• Contradicted: official اور chain evidence براہ راست مختلف

ایک critical contradiction پورے result کو pause کر سکتا ہے۔ چھوٹے green checks اسے cancel نہیں کرتے۔

عام غلطیاں

• unlock date کو guaranteed sale date کہنا
• allocation percentage کا denominator نہ لکھنا
• cliff اور linear schedule ملانا
• document screenshot کو current wallet state کہنا
• already released units دوبارہ count کرنا
• timezone/date boundary غلط لینا
• provider circulation update کو instant فرض کرنا
• bridge supply double count کرنا
• price کو fixed prediction سمجھنا
• volume کو liquidity کہنا

Result statement

“Schedule version ___ کے مطابق ___ units وقت ___ پر releasable ہیں۔ Contract/address evidence ___ status دیتی ہے۔ Current circulation ___ ہے، اس لیے potential exposure ___% ہے۔ Chain transfer ابھی observed/absent ہے۔ Liquidity tests اور provider reclassification کے یہ points unresolved ہیں: ___۔”

آخری checklist

• contract/mint identity صحیح
• schedule version محفوظ
• absolute units اور denominator دونوں
• start، cliff، duration اور timezone
• beneficiary/vesting address verify
• releasable اور transferred الگ
• decimals conversion check
• provider methodology پڑھی
• bridge accounting حل
• liquidity scenarios record
• result prediction نہیں

مزید تشریح کے لیے unlock اور dilution مضمون اور unlock verification guide استعمال کریں۔

یہ worksheet educational ہے، financial advice نہیں۔ Unlocks، centralized permissions اور low liquidity مکمل loss کا خطرہ بڑھا سکتے ہیں۔ اہل صارف Binance دعوتی کوڈ BN8812 اپنی صوابدید پر درج کر سکتا ہے۔ سائٹ آپریٹر کے مطابق spot trading fee پر زیادہ سے زیادہ 20% رعایت ممکن ہے؛ اصل rate، eligibility، regional availability اور current terms Binance پر خود verify کریں۔