FDV کیا ہے اور میم کوائن کی مکمل قدر کیسے سمجھیں؟

آخری نظرثانی: 2026-08-17T12:17:09+08:00
مطالعے کا مقصد: یہ صفحہ میم کوائن کی Fully Diluted Valuation کو سمجھنے، دوبارہ حساب کرنے اور اس کے پیچھے موجود supply مفروضوں کی جانچ کے لیے ہے۔ یہاں کوئی live price feed نہیں؛ ہر مثال فرضی ہے اور سرمایہ کاری کا مشورہ نہیں۔

FDV ایک مفید مگر نامکمل سوال کا جواب دیتی ہے: اگر کسی ٹوکن کی مکمل سمجھی جانے والی supply کو آج کی فی ٹوکن قیمت سے ضرب دیں تو نظریاتی قدر کتنی بنتی ہے؟ مشکل یہ ہے کہ “مکمل supply” ہر پروجیکٹ اور ہر data provider کے ہاں ایک ہی چیز نہیں۔ کسی contract میں سخت cap ہو سکتی ہے، کسی میں minting جاری رہ سکتی ہے، کسی کے tokens کئی chains پر ہوں گے، اور کسی کی بڑی allocation برسوں تک locked رہے گی۔ اس لیے FDV کو ایک فیصلہ نہیں بلکہ تحقیق کا دروازہ سمجھنا چاہیے۔

فہرست

• FDV کی مختصر تعریف
• Market cap اور FDV کا بنیادی فرق
• کون سی supply استعمال کرنی چاہیے
• FDV کو خود کیسے دوبارہ حساب کریں
• Market cap/FDV ratio کیا بتاتا ہے
• Unlock، vesting اور emissions کیوں اہم ہیں
• Minting، cap، burn اور admin اختیار
• Liquidity کے بغیر FDV کیوں گمراہ کر سکتی ہے
• Multi-chain supply میں double counting
• تین عملی scenario
• مکمل تحقیق کی worksheet
• عام غلطیاں
• سوالات و جوابات

FDV کی مختصر تعریف

FDV موجودہ قیمت کو مکمل سمجھی جانے والی token supply سے ضرب دینے والا نظریاتی valuation metric ہے۔ عام فارمولا یوں لکھا جاتا ہے:

FDV = موجودہ فی ٹوکن قیمت × total supply یا max supply

CoinGecko کی FDV وضاحت اسے اس مفروضے کی قدر کہتی ہے کہ تمام متعلقہ tokens circulation میں ہوں۔ اسی ادارے کی مختصر glossary تعریف ایک اہم احتیاط بھی دیتی ہے: یہ نظریاتی عدد ہے، کیونکہ supply بڑھنے پر قیمت وہی رہنا ضروری نہیں۔ یہی احتیاط پوری تحقیق کی بنیاد ہے۔

فرض کریں ایک میم کوائن کی موجودہ قیمت 0.002 ڈالر ہے اور provider نے total supply 100,000,000,000 دکھائی۔ سادہ ضرب سے FDV 200,000,000 ڈالر بنتی ہے۔ اس کا مطلب یہ نہیں کہ دو سو ملین ڈالر واقعی project میں داخل ہو چکے ہیں، نہ یہ کہ تمام tokens آج اسی قیمت پر فروخت ہو سکتے ہیں۔ یہ صرف موجودہ marginal price کو ایک بہت بڑی supply پر پھیلایا گیا حساب ہے۔

یہ فرق خاص طور پر میم کوائن میں اہم ہے، کیونکہ price اکثر ایک محدود liquid pool یا چند exchanges کی تازہ trades سے اخذ ہوتی ہے۔ آخری trade کا چھوٹا سا نرخ پورے token base کی نقد قابلِ وصول قدر نہیں بن جاتا۔ FDV کو “اگر denominator درست ہو اور price برقرار رہے” والا arithmetic snapshot کہیں؛ مستقبل کی پیش گوئی، treasury کی cash value یا guaranteed exit value نہ کہیں۔

FDV کن سوالات کا ابتدائی جواب دیتی ہے؟

FDV تین مفید اشارے دیتی ہے۔ پہلا، موجودہ market cap کے مقابلے میں ابھی کتنی supply ممکنہ طور پر باہر ہے۔ دوسرا، اگر قیمت نہ بدلے تو مکمل supply کس valuation تک پہنچتی ہے۔ تیسرا، اسی sector یا narrative میں دو tokens کی headline valuation کا تقابل کس حد تک مختلف ہے۔ مگر یہ اشارے تبھی معنی رکھتے ہیں جب دونوں assets میں supply کی تعریف، chain coverage، price source اور timestamp قابلِ موازنہ ہوں۔

FDV یہ نہیں بتاتی کہ unlock ہوتے ہی کون بیچے گا، demand کتنی بڑھے گی، liquidity کتنی ہے، contract دوبارہ mint کر سکتا ہے یا bridge نے supply کو duplicate دکھایا ہے۔ ان سوالات کے لیے الگ evidence چاہیے۔ اسی لیے اس صفحے میں فارمولا کے بعد contract، unlock schedule، holders، liquidity اور provider methodology کو ایک ہی chain of evidence میں جوڑا گیا ہے۔

Market cap اور FDV کا بنیادی فرق

Market cap موجودہ circulating supply کو استعمال کرتی ہے، جبکہ FDV total یا maximum supply کا مفروضہ لیتی ہے۔ دونوں فارمولے ساتھ لکھنے سے فرق فوراً صاف ہو جاتا ہے:

Market cap = قیمت × circulating supply

FDV = قیمت × total یا max supply

CoinGecko کی market cap تشریح بھی واضح کرتی ہے کہ market cap سرمایہ کی حقیقی آمد نہیں؛ یہ circulating units پر موجودہ price کا ضرب ہے۔ یہی منطق FDV پر مزید شدت سے لاگو ہوتی ہے، کیونکہ اس میں وہ units بھی شامل ہو سکتی ہیں جو ابھی market میں آزاد نہیں۔

ایک فرضی مثال لیں۔ قیمت 0.01 ڈالر، circulating supply 10 ارب اور max supply 100 ارب ہو۔ Market cap 100 ملین ڈالر اور FDV 1 ارب ڈالر ہوگی۔ اعداد کے درمیان دس گنا فرق صرف “مہنگا یا سستا” ثابت نہیں کرتا۔ یہ تحقیق کا سوال پیدا کرتا ہے: باقی نوّے ارب tokens کہاں ہیں، کب آئیں گے، کس کے پاس جائیں گے، اور کیا max supply واقعی contract سے enforce ہوتی ہے؟

Metric	استعمال شدہ supply	اصل سوال	بڑی کمزوری
Market cap	circulating	آج بازار میں شمار کی گئی supply کی headline قدر کیا ہے؟	circulation label غلط یا نامکمل ہو سکتا ہے
FDV	total یا max	مکمل supply کو آج کی قیمت دیں تو نظریاتی قدر کیا ہے؟	قیمت کو مستقبل تک مستقل فرض کرتی ہے
FDV minus market cap	دونوں کا فرق	موجودہ اور مکمل مفروضے کے درمیان valuation gap کیا ہے؟	gap یہ نہیں بتاتا کہ unlock کب یا کس رفتار سے ہوگا
Market cap / FDV	ratio	مکمل supply کے مقابلے میں کتنا حصہ گردش میں سمجھا جا رہا ہے؟	provider definitions بدلیں تو ratio بھی بدل جاتا ہے

Market cap اور FDV دونوں price-dependent ہیں۔ اگر price آدھی ہو جائے اور supply نہ بدلے تو دونوں آدھے ہو جاتے ہیں۔ اگر circulating supply بڑھے مگر demand اسی رفتار سے نہ بڑھے تو price گر سکتی ہے؛ ایسی صورت میں مستقبل کی market cap آج کی FDV کے برابر ہونا لازم نہیں۔ اسی وجہ سے “FDV آخرکار market cap بن جائے گی” کہنا غیر محتاط ہے۔ درست جملہ یہ ہے کہ آج کا FDV ایک constant-price scenario دکھاتا ہے۔

مزید بنیادی فرق کے لیے market cap اور price کی تفصیلی تحقیق ساتھ پڑھیں۔ وہاں یہ واضح ہے کہ token price کم ہونے سے asset لازماً سستا نہیں اور زیادہ unit price سے asset لازماً بڑا نہیں بنتا۔ FDV اسی denominator مسئلے کو مستقبل یا مکمل supply تک پھیلاتی ہے۔

کون سی supply استعمال کرنی چاہیے

FDV کا سب سے حساس حصہ price نہیں بلکہ denominator ہے: total supply، maximum supply اور circulating supply کو ایک دوسرے کا بدل نہ سمجھیں۔ CoinGecko Supply Methodology کے مطابق max supply نظریاتی coded maximum ہو سکتی ہے، total supply عام طور پر minted tokens میں سے permanently burned units نکالتی ہے، اور circulating supply میں identified uncirculated wallets خارج کیے جا سکتے ہیں۔ دوسرے providers اپنی methodology استعمال کر سکتے ہیں، اس لیے ایک ہی token کے اعداد مختلف آنا خود بخود fraud ثابت نہیں کرتا۔

Circulating supply

Circulating supply وہ مقدار ہونی چاہیے جو بازار میں public طور پر available اور trade کے قابل سمجھی جا رہی ہو۔ لیکن “available” ایک سادہ on-chain flag نہیں۔ Team wallet technically transfer کر سکتا ہے مگر contractual vesting سے بندھا ہو سکتا ہے؛ treasury wallet unlocked ہو مگر عملی طور پر market میں نہ آیا ہو؛ bridge escrow میں locked tokens دوسری chain پر wrapped نمائندگی رکھتے ہوں۔ Provider labels اور disclosed addresses سے circulation estimate بنتی ہے۔

تحقیق کرتے وقت circulating figure کے ساتھ methodology، last updated time اور excluded wallets دیکھیں۔ صرف dashboard کا بڑا عدد copy نہ کریں۔ اگر provider نے self-reported supply لکھی ہے تو project کی اپنی documentation، explorer اور third-party methodology سے cross-check کریں۔ اختلاف ملے تو range لکھیں، وجہ نوٹ کریں، اور اپنے فیصلے کو ایک exact عدد پر نہ ٹکائیں۔

Total supply

Total supply عام طور پر موجود minted units minus provably burned units کو ظاہر کرتی ہے۔ ERC-20 میں standard totalSupply() function contract کی موجودہ supply بتا سکتا ہے، مگر یہ maximum cap نہیں بتاتا۔ EIP-20 specification میں totalSupply() standard interface کا حصہ ہے؛ اس کے باوجود token کے economic rules جاننے کے لیے source code، mint functions، proxy اور roles الگ دیکھنا پڑتے ہیں۔

کسی burn address پر tokens بھیج دینا اور protocol-level burn ایک جیسے دکھ سکتے ہیں مگر accounting context مختلف ہو سکتا ہے۔ اگر provider burn address خارج کر رہا ہے تو دیکھیں وہ address واقعی inaccessible سمجھا جاتا ہے یا project نے صرف marketing label لگایا ہے۔ Contract event history اور token holder list اس دعوے کو مضبوط یا کمزور کر سکتے ہیں۔

Maximum supply

Maximum supply وہ upper limit ہے جس سے زیادہ units کبھی نہیں بننے چاہئیں۔ “Should” اور “can” میں فرق ہے۔ Whitepaper میں لکھی cap تب مضبوط evidence بنتی ہے جب contract code اسے enforce کرے یا governance کے پاس cap بڑھانے کا راستہ واضح طور پر نہ ہو۔ اگر proxy upgrade، owner-only mint، role-based minter یا migration contract موجود ہے تو nominal cap کے ساتھ administrative scope بھی لکھیں۔

OpenZeppelin Contracts 5.x کی حقیقی دستاویز کا اسکرین شاٹ، 2026-08 میں لیا گیا۔ تصویر واضح کرتی ہے کہ ERC20Capped عام ERC-20 میں supply cap شامل کرنے والا الگ extension ہے؛ ہر ERC-20 میں cap خود بخود موجود نہیں ہوتی۔

OpenZeppelin ERC-20 API میں ERC20Capped کو supply cap شامل کرنے والی extension کے طور پر دکھایا گیا ہے۔ یہ evidence کسی خاص میم کوائن کی cap ثابت نہیں کرتا؛ یہ صرف code review کا اصول سمجھاتا ہے۔ ہر token کے اپنے verified source، deployed bytecode اور proxy implementation کو الگ جانچنا ضروری ہے۔

Total اور max میں کس کو FDV denominator بنائیں؟

جو provider FDV دکھا رہا ہو پہلے اس کا label اور methodology پڑھیں۔ اگر fixed hard cap واضح اور قابلِ تصدیق ہو تو max supply long-horizon ceiling scenario کے لیے مناسب ہو سکتی ہے۔ اگر max supply undefined ہو مگر موجود minted total معلوم ہو تو total supply current fully-minted snapshot دے سکتی ہے، لیکن future minting کا risk الگ شامل کریں۔ اگر emission theoretically unlimited ہو تو ایک واحد “ultimate FDV” ممکن نہیں؛ مختلف future supply scenarios بنانا زیادہ دیانت دار ہے۔

اپنی spreadsheet میں denominator کے تین خانے رکھیں: provider-reported total، provider-reported max، اور contract-verified current total. ہر خانے کے ساتھ source URL، chain، block/time اور note لکھیں۔ اسی سے معلوم ہوگا کہ دو FDV figures صرف arithmetic فرق ہیں یا بنیادی supply definitions مختلف ہیں۔

FDV کو خود کیسے دوبارہ حساب کریں

صحیح طریقہ یہ ہے کہ price اور supply کو ایک ہی وقت، ایک ہی asset identity اور لکھی ہوئی definition کے ساتھ محفوظ کر کے ضرب دوبارہ نکالی جائے۔ محض dashboard value دیکھنا کافی نہیں، کیونکہ price update اور supply update مختلف timestamps سے آ سکتے ہیں۔

قدم 1: درست contract اور chain طے کریں

Ticker پر بھروسا نہ کریں۔ ایک ہی symbol کئی غیر متعلق tokens استعمال کر سکتے ہیں۔ Project کی official documentation سے contract address لیں، explorer پر نام، decimals، verified source اور creation details دیکھیں۔ Multi-chain token ہو تو ہر chain کی canonical یا wrapped حیثیت لکھیں۔ Contract identity غلط ہوئی تو باقی تمام حساب درست ہونے کے باوجود تحقیق غلط asset پر ہوگی۔

قدم 2: price source اور market scope لکھیں

Price aggregator کئی exchanges کی weighted value دے سکتا ہے، جبکہ DEX pool کی spot quote کسی ایک route کی قیمت ہے۔ اپنی worksheet میں source، currency، timestamp اور اگر دستیاب ہو تو market list نوٹ کریں۔ Low-liquidity pair کی ایک چھوٹی trade کو پوری supply پر ضرب دینا headline FDV کو بہت غیر مستحکم بنا سکتا ہے۔

قدم 3: supply label جوں کا توں محفوظ کریں

عدد کے ساتھ لفظ بھی محفوظ کریں: circulating، total یا max۔ اگر API response میں total_supply ہے تو اسے “max” نہ لکھیں۔ Blockscout token information endpoint explorer data میں total supply، holders اور exchange rate جیسے fields دکھا سکتا ہے؛ مگر field کا مطلب explorer کی implementation اور chain context کے مطابق پڑھنا چاہیے۔ Explorer figure کو project allocation schedule کا substitute نہ بنائیں۔

قدم 4: decimals درست کریں

Smart contract raw integer return کر سکتا ہے۔ ERC-20 decimals display conversion کے لیے ہوتے ہیں۔ اگر raw total 1000000000000000000000 ہو اور decimals 18 ہوں تو human-readable total 1000 بنتا ہے۔ Raw integer کو price سے ضرب دینا بہت بڑا غلط عدد پیدا کرے گا۔ Decimals contract call، explorer اور verified source سے cross-check کریں۔

قدم 5: arithmetic الگ دکھائیں

مثال:

• price: $0.004
• circulating supply: 25,000,000,000
• total supply: 80,000,000,000
• stated max supply: 100,000,000,000

نتیجہ:

• market cap = 0.004 × 25,000,000,000 = $100,000,000
• total-supply FDV = 0.004 × 80,000,000,000 = $320,000,000
• max-supply ceiling scenario = 0.004 × 100,000,000,000 = $400,000,000

یہ تینوں اعداد ایک دوسرے کو غلط ثابت نہیں کرتے؛ یہ مختلف denominator استعمال کر رہے ہیں۔ غلطی تب ہوگی جب کسی table میں 400m کو “current market cap” لکھ دیا جائے، یا 320m کو guaranteed future valuation سمجھ لیا جائے۔

قدم 6: provider value سے فرق ناپیں

اپنا نتیجہ provider FDV سے compare کریں۔ معمولی فرق price timing یا rounding سے آ سکتا ہے۔ بڑا فرق ملے تو supply definition، burn treatment، multi-chain aggregation، token migration، decimals یا stale data چیک کریں۔ فرق کو زبردستی ختم نہ کریں؛ explanation کے ساتھ دونوں observations محفوظ کریں۔ یہی audit trail بعد میں update کرتے وقت کام آتا ہے۔

قدم 7: sensitivity table بنائیں

ایک price پر رکنے کے بجائے کم، base اور زیادہ price scenarios بنائیں۔ مثال میں max supply 100 ارب رکھیں:

فرضی قیمت	max-supply FDV	اس عدد کا مطلب
$0.001	$100m	base price کے چوتھائی پر نظریاتی قدر
$0.004	$400m	موجودہ فرضی snapshot
$0.008	$800m	price دوگنی مگر liquidity اور demand نامعلوم
$0.020	$2bn	بلند scenario؛ اسے target یا forecast نہ سمجھیں

اس table کا مقصد price prediction نہیں۔ یہ دکھاتا ہے کہ FDV price کے ساتھ linear طور پر بدلتی ہے، جبکہ اصل market behavior linear نہیں۔ Price بڑھانے کے لیے required demand، sell pressure اور liquidity الگ systems ہیں۔

اپنا حساب تیزی سے دہرانے کے لیے FDV research tool استعمال کیا جا سکتا ہے۔ یہ user-entered values پر arithmetic کرتا ہے، live market feed یا investment signal نہیں دیتا۔ Dilution assumptions بدلنے کے لیے token dilution simulator الگ مفید ہے۔

Market cap/FDV ratio کیا بتاتا ہے

Market cap/FDV ratio مکمل valuation کے مقابلے میں موجودہ circulating valuation کا تناسب دکھاتا ہے، مگر اسے unlock percentage سمجھنا ہمیشہ درست نہیں۔ اگر دونوں metrics ایک ہی price اور consistent supply definitions استعمال کریں تو ratio تقریباً circulating supply ÷ full supply کے برابر ہوگا۔

فرضی market cap 100m اور FDV 400m ہو تو ratio 0.25 یا 25% ہے۔ اس سے اشارہ ملتا ہے کہ denominator کے مقابلے میں circulation نسبتاً کم ہے۔ مگر باقی 75% کا مطلب یہ نہیں کہ اگلے مہینے اتنے tokens لازماً market میں آ جائیں گے۔ کچھ burned، reserved، unminted، bridge-locked یا governance-controlled ہو سکتے ہیں۔

Ratio کو چار سوالوں کے ساتھ پڑھیں:

1. denominator total ہے یا maximum؟
2. باقی supply پہلے mint ہو چکی ہے یا future mint پر منحصر ہے؟
3. unlock dates اور beneficiaries کون ہیں؟
4. circulating methodology کن wallets کو خارج کرتی ہے؟

ایک بلند ratio، مثلاً 0.9، عام طور پر market cap اور FDV کے قریب ہونے کی علامت ہے، لیکن contract میں unlimited mint اختیار ہو تو false comfort دے سکتا ہے۔ ایک کم ratio، مثلاً 0.1، dilution research کی ضرورت بڑھاتا ہے، مگر transparent ten-year emission schedule اور growing utility ہو تو فوری خطرے کا فیصلہ نہیں۔ Ratio triage tool ہے، verdict نہیں۔

Unlock، vesting اور emissions کیوں اہم ہیں

FDV supply کی مقدار دکھاتی ہے؛ unlock schedule supply کے وقت اور ممکنہ recipients کو دکھاتا ہے۔ یہی وجہ ہے کہ دو یکساں FDV والے tokens کا risk profile بہت مختلف ہو سکتا ہے۔ ایک میں باقی tokens دس سال میں validator rewards کے ذریعے آ سکتے ہیں، دوسرے میں چند مہینوں کے اندر team اور early investors کی بڑی cliff ہو سکتی ہے۔

Unlock اور mint ایک چیز نہیں

Unlock کا مطلب اکثر یہ ہے کہ موجود token پر transfer restriction یا vesting ختم ہوئی۔ Mint کا مطلب نئی units create ہونا ہے۔ کچھ projects tokens پہلے mint کر کے vesting contract میں رکھتے ہیں؛ unlock پر total supply نہیں بڑھتی مگر circulating supply بڑھ سکتی ہے۔ دوسرے models میں emission کے وقت نئے tokens mint ہوتے ہیں، اس لیے total اور circulating دونوں بدل سکتے ہیں۔ Analysis میں event type لکھنا ضروری ہے۔

Cliff اور linear vesting

Cliff وہ تاریخ ہے جس سے پہلے allocation release نہیں ہوتی، پھر ایک block میں یا مقررہ tranche میں حصہ unlock ہو سکتا ہے۔ Linear vesting وقت کے ساتھ چھوٹے حصے جاری کرتی ہے۔ Headline “چار سال vesting” کافی نہیں؛ initial unlock، cliff length، monthly rate، end date، beneficiary wallets اور transfer rules دیکھیں۔ ایک بڑا initial unlock باقی schedule کو نرم دکھا سکتا ہے۔

Emissions

Mining، staking، liquidity incentives یا ecosystem rewards کے ذریعے مسلسل issuance emissions کہلاتی ہے۔ Emission کو صرف سالانہ percentage سے نہ دیکھیں۔ Absolute token amount، current liquid supply، recipients کی costs اور sell incentives بھی اہم ہیں۔ Reward recipient operating expenses ادا کرنے کے لیے tokens فروخت کر سکتا ہے؛ community incentives demand پیدا بھی کر سکتے ہیں۔ دونوں طرف کے mechanisms کو لکھیں، قطعی نتیجہ نہ گھڑیں۔

اگلے 30، 90 اور 365 دن

عملی worksheet میں تین horizons رکھیں۔ اگلے 30 دن فوری cliff یا treasury release پکڑتے ہیں۔ 90 دن repeated monthly unlocks کا cumulative اثر دکھاتے ہیں۔ 365 دن annual dilution اور major schedule milestones کو سامنے لاتا ہے۔ ہر horizon میں newly liquid units کو موجود circulating supply سے divide کریں، پھر price-constant valuation effect الگ calculate کریں۔

مثال میں current circulating supply 20 ارب اور اگلے 90 دن میں scheduled unlock 4 ارب ہو تو gross float increase 20% ہے، کیونکہ 4 ÷ 20 = 0.20۔ یہ price loss forecast نہیں۔ کچھ recipients hold کر سکتے ہیں، project liquidity programs چلا سکتا ہے، demand بڑھ سکتی ہے یا schedule بدل سکتا ہے۔ درست label “potential gross increase in available supply” ہے، “20% price crash” نہیں۔

Unlock evidence کے لیے project documentation، vesting contract، governance proposals اور explorer transactions ساتھ دیکھیں۔ صرف third-party calendar پر انحصار نہ کریں۔ تفصیلی طریقہ token unlock اور vesting verify کرنے کی عملی رہنمائی میں موجود ہے، جبکہ unlock dilution risk کی بنیادی وضاحت economic interpretation پر مرکوز ہے۔

Minting، cap، burn اور admin اختیار

FDV کی supply ceiling تبھی قابلِ اعتماد ہے جب deployed contract اور اس کے administrative paths اس ceiling سے مطابقت رکھتے ہوں۔ Token page پر “max supply” لکھا ہونا کافی نہیں۔ Source code میں mint function، cap enforcement، owner یا role permissions، proxy upgrade path اور related contracts دیکھنے چاہییں۔

OpenZeppelin Contracts 5.x کی حقیقی Access Control دستاویز کا اسکرین شاٹ، 2026-08 میں لیا گیا۔ اس میں واضح ہے کہ contract permissions یہ طے کر سکتی ہیں کہ کون mint، vote یا transfers freeze کر سکتا ہے۔ یہ کسی خاص token کی permission report نہیں، review کے معیار کی مثال ہے۔

OpenZeppelin Access Control guide کے مطابق smart contract access یہ govern کر سکتی ہے کہ کون tokens mint، transfers freeze یا administrative action انجام دے سکتا ہے۔ لہٰذا verified source میں mint کا لفظ مل جانا بذاتِ خود خطرہ یا بے ضرری ثابت نہیں کرتا۔ دیکھیں function public ہے یا restricted، restriction کس role پر ہے، role admin کون ہے، multisig ہے یا single wallet، timelock ہے یا فوراً عمل ہو سکتا ہے۔

Hard cap کو کیسے verify کریں

Contract code میں cap variable، constructor argument یا immutable constant تلاش کریں۔ پھر mint path دیکھیں کہ ہر mint سے پہلے نئی total supply cap سے compare ہوتی ہے یا نہیں۔ Proxy contract ہو تو proxy source کے ساتھ implementation address اور upgrade admin دیکھیں؛ implementation بدلی جا سکتی ہو تو آج کا cap future governance risk ختم نہیں کرتا۔ Unverified source ہو تو strong conclusion نہ دیں، صرف “code-level cap independently verified نہیں ہو سکی” لکھیں۔

Owner renounced ہونے کا مطلب

Ownership renounced دکھنے سے صرف وہ functions بند ہوتے ہیں جو اسی owner mechanism پر منحصر ہوں۔ الگ AccessControl roles، proxy admin، external minter، treasury contract یا migration authority باقی ہو سکتی ہے۔ Holder کو explorer کی ایک green label سے آگے جانا چاہیے۔ Roles کے grant/revoke events، implementation، linked contracts اور privileged calls دیکھیں۔

Burn FDV کو کب بدلتا ہے

اگر tokens واقعی total supply سے burn ہوں اور provider انہیں denominator سے نکالے تو total-supply FDV کم ہو سکتی ہے۔ اگر tokens صرف inaccessible سمجھے جانے والے address میں منتقل ہوئے مگر contract totalSupply() وہی رکھتا ہے تو providers مختلف treatment کر سکتے ہیں۔ Max supply کبھی تاریخی hard ceiling رہ سکتی ہے، چاہے current total burns سے کم ہو۔ اس لیے “burn ہوا، FDV کم ہوئی” ہر dashboard میں خودکار سچ نہیں۔

Rebase اور elastic supply

Rebase token balances کو protocol rule کے مطابق بدل سکتا ہے۔ ایسے asset پر fixed unit count اور static FDV interpretation کمزور ہو جاتی ہے۔ Positive rebase سے units بڑھ سکتے ہیں، negative rebase سے گھٹ سکتے ہیں؛ user کا proportional share الگ رہ سکتا ہے۔ Meme token اگر rebase یا reflection mechanics رکھتا ہو تو standard supply table کافی نہیں۔ Contract documentation اور balance accounting پہلے سمجھیں۔

Migration اور token swap

Old اور new contracts بیک وقت explorer پر supply دکھا سکتے ہیں۔ Migration میں old tokens locked یا burned ہو سکتے ہیں اور new tokens mint ہوتے ہیں۔ Aggregator اگر دونوں contracts کو الگ assets سمجھے یا chain mapping دیر سے update کرے تو apparent combined supply غلط پڑھ لی جاتی ہے۔ Official migration ratio، cutoff، old contract status اور canonical address محفوظ کریں۔

Contract permissions کی الگ checklist token contract permissions verify کرنے کی رہنمائی میں ہے۔ FDV تحقیق میں اس کا خلاصہ ایک sentence میں لکھیں: “موجودہ total supply یہ ہے، cap کا code evidence یہ ہے، اور supply بدلنے کا privileged path یہ ہے۔” اگر آخری حصہ نامعلوم ہو تو risk note واضح رکھیں۔

Liquidity کے بغیر FDV کیوں گمراہ کر سکتی ہے

بڑی FDV کا مطلب یہ نہیں کہ اسی قدر کے tokens موجودہ price پر فروخت کیے جا سکتے ہیں؛ exit capacity liquidity، depth اور slippage پر منحصر ہے۔ ایک DEX pool کی spot price reserves کے تناسب سے بنتی ہے۔ بڑی sale pool کو curve کے ساتھ move کرتی ہے، اس لیے average execution price quoted price سے کم ہو سکتی ہے۔

Uniswap کی price impact وضاحت price impact کو trade کی وجہ سے market price میں تبدیلی کے طور پر بیان کرتی ہے۔ یہی وجہ ہے کہ low-liquidity token میں چند trades headline price اور FDV کو تیزی سے اوپر یا نیچے لے جا سکتی ہیں۔ FDV calculation mathematically درست ہو سکتی ہے مگر economically executable نہ ہو۔

تحقیق میں کم از کم یہ liquidity evidence دیکھیں:

• سب سے بڑے pools اور ان کی دونوں جانب reserves؛
• centralized اور decentralized markets میں volume کی تقسیم؛
• top pairs میں price divergence؛
• چھوٹی، درمیانی اور بڑی hypothetical trade پر quoted price impact؛
• liquidity provider concentration اور LP token lock/burn evidence؛
• market maker یا treasury wallets کی disclosed role؛
• wash trading یا بہت کم unique traders کے ممکنہ signals۔

فرض کریں price $0.01 اور max supply 100 ارب سے FDV $1bn بنتی ہے، لیکن main pool میں quote-side liquidity صرف چند لاکھ ڈالر کے قریب ہے۔ یہ numbers ایک دوسرے سے متضاد نہیں؛ پہلا پورے denominator پر marginal price کا ضرب ہے، دوسرا market depth کا snapshot۔ Investor کے لیے اصل سوال یہ ہے کہ اس کے position size پر expected execution کیا ہوگا۔

Liquidity کو FDV سے ratio بنا کر universal threshold نہ بنائیں۔ مختلف market structures، CEX order books، concentrated liquidity ranges اور cross-chain pools compare کرنا مشکل ہے۔ بہتر طریقہ یہ ہے کہ asset-specific trade sizes پر live quote دیکھیں، مگر quote execute نہ کریں، timestamp لکھیں اور اسے تیزی سے بدلنے والا observation کہیں۔ ہمارے site کے static tools live order book نہیں پڑھتے؛ user-entered assumptions صرف scenario سمجھانے کے لیے ہیں۔

مزید پس منظر liquidity اور market cap کے فرق اور slippage، spread اور price impact میں ملتا ہے۔ FDV کے ساتھ ان metrics کو رکھنا headline valuation کو actual trading conditions سے جوڑتا ہے۔

Multi-chain supply میں double counting

Multi-chain token کی FDV نکالتے وقت canonical supply اور wrapped representations کو دو بار شمار نہ کریں۔ Bridge اکثر origin chain پر tokens lock کر کے destination chain پر equivalent wrapped units mint کرتا ہے۔ اگر origin locked units اور destination wrapped units دونوں کو آزاد economic supply سمجھ لیا جائے تو aggregate total بڑھا چڑھا کر دکھائی جا سکتی ہے۔

Canonical، bridged اور native deployments

Canonical token اصل contract یا issuer-designated representation ہو سکتا ہے۔ Bridged token origin asset کا claim ہے۔ کچھ projects ہر chain پر native supply mint کرتے اور central burn/mint bridge سے aggregate cap maintain کرتے ہیں۔ کچھ independent contracts چلاتے ہیں جن کی supplies الگ ہیں۔ Project docs سے model طے کیے بغیر chain totals جمع نہ کریں۔

Bridge escrow کو کیسے پڑھیں

Origin chain پر bridge escrow holder list میں بڑا wallet دکھا سکتا ہے۔ یہ لازماً whale-controlled circulating balance نہیں؛ destination chain پر wrapped supply کی backing ہو سکتی ہے۔ Address label، bridge documentation، deposit/withdraw events اور destination token contract check کریں۔ Holder concentration اور supply دونوں analyses میں escrow کو الگ category دیں۔

Cross-chain worksheet

ہر chain کے لیے یہ columns رکھیں: chain name، contract address، token type، current total، bridge-locked backing، independently minted amount، burn/mint controller، source time۔ Aggregate economic supply کے لیے independently circulating native units جمع کریں، مگر fully backed wrapped representation اور اس کی locked backing کو ایک ساتھ نہ جمع کریں۔ Ambiguity ہو تو low/high range دیں۔

مثال کے طور پر Chain A پر 100 ارب tokens ہیں، جن میں 20 ارب bridge escrow میں locked ہیں؛ Chain B پر اسی bridge کے 20 ارب wrapped tokens ہیں۔ Economic representation 100 ارب ہو سکتی ہے، 120 ارب نہیں، بشرطیکہ backing one-to-one اور escrow verifiable ہو۔ اگر Chain B contract independently mint کر سکتا ہے تو additional risk الگ شامل ہوگا۔

Price بھی chain-specific ہو سکتی ہے

ایک chain کے pool میں price دوسری chain سے عارضی طور پر مختلف ہو سکتی ہے۔ Low bridge liquidity یا halted bridge arbitrage کو روک سکتی ہے۔ Aggregate supply کو ایک chain کی distorted price سے ضرب دینا کمزور FDV دے گا۔ Primary liquid venue، cross-market consistency اور bridge status لکھیں۔

تین عملی scenario

Scenario analysis ایک FDV number کو کئی واضح مفروضوں میں بدل دیتا ہے اور غیر یقینی کو چھپانے کے بجائے دکھاتا ہے۔ نیچے تمام اعداد فرضی ہیں؛ کسی حقیقی token کی prediction نہیں۔

Scenario A: fixed cap اور تقریباً مکمل circulation

ایک token کی price $0.005، circulating supply 90 ارب، total 100 ارب اور code-enforced cap 100 ارب ہے۔ Market cap $450m، FDV $500m اور ratio 90% ہے۔ باقی 10 ارب transparent community rewards کے ذریعے چار سال میں آتے ہیں۔

اس صورت میں headline FDV gap نسبتاً چھوٹا ہے، مگر تحقیق ختم نہیں۔ Reward emissions کس کو ملتی ہیں، annual issuance current float کے مقابلے میں کتنی ہے، liquidity کتنی ہے، اور demand mechanism کیا ہے؟ Fixed cap future supply uncertainty کم کرتی ہے، price risk نہیں۔ اگر liquidity پتلی ہو تو 90% ratio کے باوجود exit مشکل ہو سکتی ہے۔

Scenario B: low float اور بڑی cliff

Price $0.02، circulating supply 5 ارب اور max supply 100 ارب ہو۔ Market cap $100m، FDV $2bn اور ratio 5% ہے۔ اگلے چھ ماہ میں team اور investors کے 15 ارب tokens unlock ہونا طے ہوں۔

Headline market cap چھوٹی دکھ سکتی ہے مگر current price کو full supply پر پھیلانے سے valuation بہت بڑی ہے۔ اگلا سوال unlock recipients کی cost basis، vesting contract، market liquidity اور disclosure ہے۔ 15 ارب unlock current float کے تین گنا ہیں، مگر اسے “price لازماً 75% گرے گی” کہنا غلط ہوگا۔ Demand، holding behavior، market making اور schedule changes نامعلوم ہیں۔ Risk statement یوں لکھیں: “موجودہ float کے مقابلے میں scheduled gross release بہت بڑی ہے؛ price effect غیر یقینی ہے اور liquidity evidence ضروری ہے۔”

Scenario C: no hard max اور privileged mint

Price $0.0005، circulating 200 ارب اور current total 250 ارب ہے، مگر contract role مزید mint کر سکتا ہے اور hard cap verify نہیں۔ Provider current total پر FDV $125m دکھا سکتا ہے۔ اسے lifetime fully diluted ceiling کہنا درست نہیں، کیونکہ future denominator open-ended ہے۔

اس case میں 250 ارب، 400 ارب اور 1 کھرب supply scenarios بنائیں۔ Prices constant رکھنے کے بجائے multiple price rows شامل کریں۔ Governance controls، multisig signers، timelock، historical mint events اور announced policy دیکھیں۔ FDV label کے ساتھ “current-total valuation” لکھنا زیادہ درست ہے۔

Scenario D: burn narrative مگر unclear accounting

Price $0.01، explorer total 80 ارب، project max 100 ارب اور marketing material 30 ارب burned بتاتا ہے۔ Numbers فوری طور پر reconcile نہیں ہوتے۔ ممکن ہے max historical cap ہو، current total burns کے بعد 80 ارب ہو، اور burn claim cumulative issuances کو شمار کرتی ہو۔ Provider شاید total پر $800m FDV دکھائے اور دوسرا max پر $1bn۔

یہاں arithmetic سے پہلے definitions کی reconciliation کریں۔ Burn transactions، totalSupply() history، issuer docs اور provider methodology محفوظ کریں۔ Evidence نہ ملے تو دونوں figures دکھائیں اور discrepancy note کریں؛ ایک پسندیدہ number منتخب کر کے certainty نہ بنائیں۔

مکمل تحقیق کی worksheet

قابلِ تکرار FDV تحقیق میں identity، supply، permissions، schedule، price اور liquidity کے الگ evidence fields ہونے چاہییں۔ نیچے کی worksheet copy کر کے ہر token کے لیے بھری جا سکتی ہے۔

A. شناخت

• Project اور token کا پورا نام
• Symbol، مگر صرف secondary label کے طور پر
• Official website/documentation URL
• ہر chain کا contract address
• Canonical، wrapped یا native status
• Explorer verification status
• Research timestamp، timezone سمیت

B. Price snapshot

• Price source اور venue scope
• Quote currency
• Observed price
• Timestamp
• Main markets اور apparent divergence
• Low-liquidity warning اگر relevant ہو

C. Supply snapshot

• Circulating supply + provider definition
• Total supply + explorer/contract evidence
• Maximum supply + code/document evidence
• Decimals
• Burn treatment
• Excluded treasury، vesting یا bridge wallets
• Cross-chain aggregation method

D. Privileged controls

• Mint function موجود ہے یا نہیں
• Minter/owner/admin addresses یا roles
• Proxy implementation اور upgrade admin
• Timelock/multisig evidence
• Pause، blacklist، fee یا transfer controls
• Recent role یا implementation changes

E. Distribution اور time

• Team، investor، treasury، community allocations
• Initial unlock
• Cliff dates
• Linear یا periodic releases
• اگلے 30/90/365 دن کی gross release
• Beneficiary wallets اور source confidence

F. Market capacity

• Largest pools/order books
• Quoted liquidity اور timestamp
• Hypothetical position sizes پر price impact
• LP ownership/lock evidence
• Top holders، exchange، bridge اور treasury categories

G. Calculations

• Current market cap دوبارہ حساب
• Total-supply FDV
• Max-supply scenario
• Market cap/FDV ratio
• 30/90/365-day float increase scenarios
• Low/base/high price sensitivity
• Provider discrepancy notes

H. نتیجہ لکھنے کا قالب

نتیجہ تین حصوں میں لکھیں۔ پہلے verified facts: contract، current supply، cap اور schedule۔ پھر assumptions: کون سی price اور denominator استعمال ہوئی۔ آخر میں unknowns: unverified roles، unclear bridge accounting، missing vesting یا thin liquidity۔ “خریدیں” یا “بیچیں” جیسے حکم کی جگہ evidence quality اور risk conditions بیان کریں۔

عام غلطیاں

FDV کی سب سے عام غلطیاں formula میں نہیں بلکہ labels، timing اور interpretation میں ہوتی ہیں۔ یہ checklist final review سے پہلے چلائیں۔

1. FDV کو project میں داخل cash سمجھنا: valuation ضرب ہے، bank balance یا cumulative inflow نہیں۔
2. Price کو مستقل مان کر prediction بنانا: supply بدلنے پر demand اور price بھی بدل سکتے ہیں۔
3. Total اور max کو خلط کرنا: دونوں مختلف سوالات کے denominator ہیں۔
4. Ticker سے contract چننا: copycat token پوری تحقیق کو غلط asset پر لے جاتا ہے۔
5. Decimals بھولنا: raw on-chain integer کو human units میں convert کیے بغیر ضرب غلط ہوتی ہے۔
6. Bridge backing دو بار شمار کرنا: locked origin اور wrapped destination ایک ہی economic units کی نمائندگی کر سکتے ہیں۔
7. Unlock کو mint کہنا: unlock circulation بدل سکتا ہے مگر total لازماً نہیں۔
8. Owner renounced کو مکمل immutability سمجھنا: الگ roles اور proxy admin باقی ہو سکتے ہیں۔
9. Burn claim کو بغیر transaction verify کرنا: marketing number اور contract accounting مختلف ہو سکتے ہیں۔
10. Liquidity نظر انداز کرنا: headline FDV executable exit value نہیں۔
11. مختلف timestamps ملانا: price ابھی کی اور supply پرانی ہو تو discrepancy چھپ سکتی ہے۔
12. ایک provider کو آخری authority ماننا: methodology اور chain coverage cross-check کریں۔
13. Low ratio کو automatic scam کہنا: schedule، utility اور governance context ضروری ہے۔
14. High ratio کو safe کہنا: mint permissions اور liquidity پھر بھی risk رہتے ہیں۔
15. فرضی مثال کو حقیقی data جیسا لکھنا: ہر scenario پر “فرضی” label صاف ہونا چاہیے۔

سوالات و جوابات

کیا FDV جتنی رقم project میں لگی ہوتی ہے؟

نہیں۔ FDV current unit price کو total یا max supply سے ضرب دیتی ہے۔ یہ cash inflow، treasury assets یا اسی price پر available exit liquidity نہیں۔ چند trades سے marginal price بدل سکتی ہے اور پورا FDV number فوراً بدل جاتا ہے۔

کیا بلند FDV لازماً خطرناک ہے؟

نہیں، مگر بلند FDV کو sector peers، product use، supply schedule، liquidity اور governance کے ساتھ compare کرنا چاہیے۔ بڑا number خود fraud یا overvaluation ثابت نہیں کرتا۔ کم float کے ساتھ بہت بڑا gap additional dilution research کا واضح سبب ہے۔

کیا کم FDV لازماً اچھا موقع ہے؟

نہیں۔ کم FDV thin liquidity، کم demand، غلط supply reporting یا risky contract permissions کے ساتھ ہو سکتی ہے۔ Valuation کم دکھنے سے token quality، security یا future return ثابت نہیں ہوتے۔

FDV total supply استعمال کرتی ہے یا maximum supply؟

Provider کے حساب پر منحصر ہے۔ Fixed cap والے token میں max supply استعمال ہو سکتی ہے؛ کہیں current total استعمال ہوتی ہے۔ Page label اور methodology پڑھیں، پھر دونوں denominators سے اپنی scenarios نکالیں۔

اگر maximum supply نہ ہو تو FDV کیا ہوگی؟

ایک دائمی ceiling FDV ممکن نہیں۔ Current total supply پر valuation نکالی جا سکتی ہے، مگر اسے current-total scenario لکھیں۔ Future issuance کے لیے متعدد supply horizons بنائیں اور mint/emission rules دکھائیں۔

Market cap/FDV ratio کتنا ہونا چاہیے؟

کوئی universal safe threshold نہیں۔ Ratio صرف full denominator کے مقابلے میں current circulation کا اشارہ ہے۔ Unlock timing، recipients، cap enforcement، liquidity اور demand کے بغیر کوئی فیصد فیصلہ نہیں بناتا۔

کیا token unlock سے price اسی تناسب سے گرتی ہے؟

ضروری نہیں۔ Unlock available supply بڑھا سکتا ہے، مگر price effect selling behavior، demand، liquidity، market sentiment اور already-priced expectations پر منحصر ہے۔ Gross float increase کو price forecast نہ بنائیں۔

Contract کا totalSupply() کافی evidence ہے؟

یہ current supply کے لیے مضبوط on-chain input ہے، مگر maximum cap، future mint ability، circulation اور cross-chain economic supply نہیں بتاتا۔ Source code، roles، proxy، burns اور bridge accounting ساتھ دیکھیں۔

FDV دو websites پر مختلف کیوں ہے؟

Price timestamp، total/max definition، burn treatment، chain coverage، decimals، migration mapping یا data freshness مختلف ہو سکتی ہے۔ دونوں values کے inputs دوبارہ نکالیں اور discrepancy note بنائیں۔

میم کوائن کے لیے سب سے پہلے کیا دیکھوں؟

صحیح contract address، current circulating/total/max supply، mint permissions، largest holders، liquidity، unlock schedule اور multi-chain status۔ FDV ان inputs کا summary ہے، ان کی جگہ نہیں۔

کیا FDV سے profit calculate کیا جا سکتا ہے؟

FDV alone سے نہیں۔ Entry price، future price، position size، fees، slippage اور exit liquidity الگ inputs ہیں۔ کسی scenario calculator کا output promise نہیں؛ صرف assumptions کی arithmetic ہے۔

کتنی بار FDV تحقیق update کرنی چاہیے؟

کسی material event پر: contract upgrade، mint/burn، migration، major unlock، bridge change، methodology revision یا liquidity shift۔ Calendar-based update مفید ہو سکتی ہے، مگر evidence-changing event زیادہ اہم trigger ہے۔

آخری عملی نتیجہ

FDV کو درست پڑھنے کا طریقہ ایک عدد دیکھنا نہیں، اس عدد کے denominator اور permissions کا audit کرنا ہے۔ پہلے contract identity اور chain طے کریں۔ پھر price کا timestamp، circulating/total/max definitions اور decimals محفوظ کریں۔ Market cap، total-supply FDV اور max-supply scenario الگ نکالیں۔ اس کے بعد unlock schedule، privileged mint paths، burns، bridge accounting، holders اور liquidity شامل کریں۔

ایک اچھی research note میں certainty کی سطح بھی لکھی ہوتی ہے۔ Verified contract call کو verified کہیں، project document کو issuer claim کہیں، provider estimate کو methodology-bound figure کہیں، اور missing evidence کو unknown چھوڑیں۔ یہی فرق ذمہ دار تحقیق اور خوبصورت مگر گمراہ کن dashboard کے درمیان ہے۔

اس site کے calculators live exchange یا blockchain API سے خودکار data نہیں کھینچتے؛ آپ جو numbers داخل کرتے ہیں انہی پر حساب کرتے ہیں۔ استعمال سے پہلے source اور timestamp خود verify کریں۔ Crypto assets میں مکمل سرمایہ ضائع ہونے، liquidity ختم ہونے، contract abuse اور regulatory restrictions کا خطرہ موجود ہے۔

اگر آپ کبھی Binance پر account بنائیں تو invitation code BN8812 درج کیا جا سکتا ہے۔ ممکنہ fee benefit زیادہ سے زیادہ 20% ہے؛ اصل اہلیت، علاقائی دستیابی، product coverage اور موجودہ شرائط Binance کی registration screen پر خود verify کریں۔ یہاں کوئی registration link نہیں دیا گیا اور code استعمال کرنا investment recommendation نہیں۔