FDV کیا ہے؟ مکمل ڈائلیوٹڈ ویلیو کا تحقیقی ٹول

FDV ایک multiplication ہے، مگر denominator کا انتخاب تحقیق کا اصل مشکل حصہ ہے۔ یہ worksheet آج کی observed unit value اور منتخب مکمل-supply base کو ملانے سے پہلے contract identity، cap، mint authority، unlock schedule اور multi-chain scope کی جانچ کراتی ہے۔ یہاں کوئی price prediction یا live feed نہیں؛ ہر input آپ خود source اور timestamp کے ساتھ داخل کرتے ہیں۔

مختصر جواب: FDV کیا ہے؟

Fully Diluted Valuation وہ مفروضاتی valuation ہے جو current token price کو اس supply پر لاگو کرتی ہے جسے analysis مکمل/ممکنہ supply مانتا ہے۔ یہ future market cap نہیں، کیونکہ future price، demand، liquidity، burns، emissions اور governance actions آج سے مختلف ہو سکتے ہیں۔

بنیادی formula

FDV = P × Sfd

• P = observed current price
• Sfd = chosen fully diluted supply

Sfd کے ساتھ label لازمی دیں:

• coded max supply
• current total supply
• documented terminal supply
• uncapped emission scenario
• provider-reported fully diluted denominator

اگر project کے لیے true max موجود نہیں تو maximum supply گھڑنے کے بجائے chosen scenario واضح کریں۔

Worksheet شروع کرنے سے پہلے identity card

Name اور ticker identity کے لیے کافی نہیں۔ Migrated، bridged یا fake versions کا symbol ایک جیسا ہو سکتا ہے۔ FDV غلط address پر نکالنے سے formula صحیح اور conclusion بے معنی رہتا ہے۔

Max supply code میں کہاں دکھ سکتی ہے؟

یہ 2026-08 میں محفوظ کی گئی OpenZeppelin ERC20Capped documentation کی حقیقی تصویر ہے۔ ERC20Capped implementation میں cap mechanism کی مثال ملتی ہے، مگر screenshot کسی خاص Meme Coin کے deployed code کی تصدیق نہیں۔ Actual contract میں inheritance، constructor arguments، proxy implementation اور custom mint path الگ verify کریں۔

EIP-20 totalSupply() standard interface بتاتا ہے، immutable max cap نہیں۔ Token current total دکھا سکتا ہے مگر authorized role future mint کر سکتا ہے۔ اسی لیے current totalSupply() کو max کہنے سے پہلے source code اور role state پڑھیں۔

Mint authority اور access control کیوں ضروری ہیں؟

OpenZeppelin AccessControl role-based permissions کا pattern بیان کرتی ہے۔ Contract میں MINTER_ROLE، owner-only mint، upgrade admin، governance executor یا external controller ہو سکتا ہے۔ Role موجود ہونا future mint کی certainty نہیں؛ صرف capability کا ثبوت ہے۔ Role absent دکھے تو proxy upgrade یا دوسری issuance path check کریں۔

یہ سوال جواب کے ساتھ محفوظ کریں:

• کون mint call کر سکتا ہے؟
• کیا cap hard-coded ہے یا role سے بدل سکتی ہے؟
• proxy admin implementation بدل سکتا ہے؟
• ownership renounced واقعی current chain state میں ہے؟
• timelock یا multisig ہے، اور delay کیا ہے؟
• paused/blacklist/tax controls supply access کو بدل سکتے ہیں؟

Unknown کو no نہ لکھیں۔ Evidence نہ ملے تو unknown ہی درست status ہے۔

Supply denominator منتخب کرنے کا decision tree

Code-enforced cap موجود ہے؟

ہاں: cap value اور units record کریں، پھر confirm کریں کہ کوئی alternate mint bypass نہیں۔

Official terminal supply documented ہے؟

ہاں مگر code cap نہیں: اسے policy target کہیں، immutable max نہیں۔ Governance یا future migration اسے بدل سکتی ہے۔

Emission جاری اور uncapped ہے؟

ایک دور کا scenario منتخب کریں، مثلاً documented year-end supply، اور result کو scenario FDV label دیں۔

Multi-chain token ہے؟

Native issuance اور bridge representation الگ کریں۔ Lock-and-mint design میں اصل chain کے vault balance کو دوسری chain کی نمائندہ issuance کے ساتھ جوڑ دینا ایک ہی economic units کو دو مرتبہ گن سکتا ہے۔

Max field null ہے؟

Provider کے displayed FDV کا denominator پڑھیں۔ اگر methodology نہ ملے تو result کو independent fact نہ کہیں۔

Price input کو ثابت کریں

FDV current price کو پوری supply پر پھیلاتی ہے۔ Thin pool کی last trade future unlocked units کے لیے durable price نہیں۔ CoinGecko کی FDV explanation conceptual relation دیتی ہے، جبکہ CoinGecko supply methodology supply labels کا provider context دیتی ہے۔

Price record میں یہ لکھیں:

• source/venue
• quote currency
• last trade، index، VWAP یا pool quote
• timestamp
• contract mapping
• available liquidity context

Uniswap price impact note بتاتی ہے کہ trade size liquidity کے مقابل execution price بدل سکتی ہے۔ FDV reference valuation ہے، liquidation value نہیں۔

فرضی example: cap واضح ہو

یہ صرف formula demonstration ہے:

• P = 0.002 USD
• code-verified Smax = 50,000,000,000

FDV = 0.002 × 50,000,000,000 = 100,000,000 USD

اگر circulating supply 10,000,000,000 ہو تو اسی price پر market cap:

Market cap = 0.002 × 10,000,000,000 = 20,000,000 USD

FDV / Market cap = 5

یہ ratio صرف denominator gap دکھاتا ہے۔ یہ نہیں بتاتا کہ باقی supply کب آئے گی، recipients بیچیں گے یا demand بڑھے گی۔

فرضی example: max supply موجود نہ ہو

فرض کریں emission schedule کے مطابق analysis date سے دو سال بعد expected supply 80,000,000,000 ہے۔ اسے S2y کہیں:

Scenario value = current P × S2y

Result کا نام two-year constant-price supply scenario رکھیں، FDV definitive نہیں۔ ساتھ emission assumptions، schedule version اور capture date لکھیں۔ Schedule بدلے تو old result archive کریں؛ value چپکے سے replace نہ کریں۔

Unlock schedule کو denominator کے ساتھ جوڑیں

Supply cap بتاتی ہے کتنے units ممکن ہیں؛ vesting بتاتی ہے access کب کھل سکتی ہے۔ OpenZeppelin VestingWallet اور VestingWalletCliff schedule mechanics کی implementation examples دیتی ہیں۔ Project-specific allocation کے لیے official document، deployed contract parameters، beneficiary wallets اور on-chain release events دیکھیں۔

ہر allocation row:

اعلان شدہ unlock sell event نہیں۔ Tokens unlocked مگر held، staked، bridged یا OTC منتقل ہو سکتے ہیں۔ Pressure conclusion کے لیے wallet movement اور liquidity الگ دیکھیں۔

FDV sensitivity grid

ایک point estimate کے بجائے grid بنائیں۔ Rows supply scenarios اور columns price scenarios رکھیں:

یہ forecast نہیں۔ Grid دکھاتی ہے کہ answer دو assumptions سے کتنا sensitive ہے۔ نام bear/base/bull دینے سے prediction کا تاثر پیدا ہو سکتا ہے؛ neutral labels بہتر ہیں۔

FDV-to-market-cap ratio کو کیسے پڑھیں؟

Dilution multiple = FDV ÷ current market cap

اگر price snapshot دونوں calculations میں ایک ہو تو یہ ratio تقریباً diluted supply ÷ circulating supply کے برابر ہو سکتی ہے۔ Ratio 4 کا مطلب یہ نہیں کہ price لازماً 75% گرے گی۔ اس کا سیدھا مطلب یہ ہے کہ selected diluted denominator current circulation سے چار گنا ہے۔ Demand، release timing، burns اور market conditions price path بدل سکتے ہیں۔

Ratio sheet میں یہ columns رکھیں:

Ratio کو peers سے compare کرتے وقت projects کی emission schedule، age اور token utility match کریں۔ ایک mature fixed-supply asset اور launch-stage high-emission token کی ratios کو side-by-side رکھنا context کے بغیر کمزور comparison ہے۔

Release velocity کا الگ metric

Total gap بڑا ہونے کے باوجود near-term issuance چھوٹی ہو سکتی ہے۔ اگلے period کے لیے:

Release rate % = scheduled new transferable units ÷ current circulating supply × 100

یہ maximum mechanical exposure ہے، expected sell volume نہیں۔ Cliff کے دن wallet transfer permissions، actual release transaction اور recipient behavior الگ observe کریں۔ Monthly linear vesting اور one-time cliff ایک جیسے total units کے باوجود مختلف liquidity stress پیدا کر سکتے ہیں۔

Report میں three horizons رکھیں: اگلا event، اگلے 12 ماہ، اور terminal supply۔ ہر horizon کے source version اور calculation date لکھیں۔ اس سے distant max supply کی headline اور near-term exposure الگ رہتے ہیں۔

Governance اور migration scenario

Token contract future upgrade allow کرے تو current cap analysis permanent نہیں۔ Proxy admin، governance proposal اور migration contract supply rules بدل سکتے ہیں۔ “آج cap موجود ہے” کو “کبھی نہیں بدلے گی” نہ بنائیں۔ Current implementation address، admin state اور observation block archive کریں۔ Migration announced ہو تو old/new contracts کا conversion ratio، deadline اور overlapping circulation check کریں؛ دونوں supplies blindly جمع نہ کریں۔

Provider FDV سے اختلاف کیسے حل کریں؟

1. Same contract اور chain check کریں۔
2. Price timestamp compare کریں۔
3. Provider denominator معلوم کریں۔
4. Max، total اور diluted supply labels الگ کریں۔
5. Decimals conversion verify کریں۔
6. Burned supply treatment پڑھیں۔
7. Multi-chain/bridge accounting حل کریں۔
8. Provider cache یا delayed update نوٹ کریں۔

Blockscout token info reference available explorer fields دکھاتی ہے، مگر provider-specific FDV methodology کا substitute نہیں۔ Explorer field اور aggregator metric دونوں کے scope لکھیں۔

FDV سے کیا نتیجہ نہیں نکلتا؟

• future price کی guarantee
• اتنی cash market میں داخل ہونے کی خبر
• unlocked supply لازماً فروخت ہونے کا ثبوت
• contract safe ہونے کی تصدیق
• liquidity کافی ہونے کی ضمانت
• project revenue یا utility کی value
• max supply immutable ہونے کا ثبوت

FDV بہت بڑی ہو تو بھی token لازماً overvalued نہیں؛ بہت چھوٹی ہو تو بھی bargain نہیں۔ یہ supply exposure کا research prompt ہے۔

عام calculation errors

• totalSupply() کو hard cap کہنا
• decimals غلط لگانا
• policy cap کو code-enforced cap کہنا
• current price اور پرانی max supply ملانا
• bridge representations double count کرنا
• burned tokens دو بار subtract کرنا
• proxy implementation نظرانداز کرنا
• provider FDV copy کر کے denominator نہ لکھنا
• liquidity کے بغیر FDV کو realizable value کہنا

نتیجہ لکھنے کا template

“Contract ___ پر observed price ___، وقت ___ ہے۔ Diluted denominator ___ units ہے، جسے ___ source نے ___ label کے ساتھ دیا۔ Formula سے scenario value ___ بنتی ہے۔ Cap کی enforcement ___ evidence سے supported/unknown ہے۔ Unlock schedule، mint permission، bridge scope اور liquidity کے یہ points unresolved ہیں: ___۔”

یہ paragraph reader کو number کے ساتھ assumptions بھی دیتا ہے۔ صرف bold FDV دکھانا تحقیق نہیں۔

آخری checklist

• contract/mint identity verified
• price source، type اور time محفوظ
• denominator label واضح
• raw units اور decimals درست
• code cap یا policy cap میں فرق کیا
• mint اور upgrade roles پڑھے
• vesting schedule version محفوظ
• bridge/burn treatment حل کیا
• market cap comparison same price پر کیا
• liquidity limitation لکھی
• result کو forecast نہیں کہا

مزید context کے لیے FDV کی تفصیلی تحقیق اور unlock/dilution analysis پڑھیں۔

یہ tool تعلیمی worksheet ہے، financial advice نہیں۔ Meme Coin میں supply control، thin liquidity اور شدید volatility مکمل loss کا سبب بن سکتے ہیں۔ اہل صارف اپنی مرضی سے Binance دعوتی کوڈ BN8812 استعمال کر سکتا ہے۔ سائٹ آپریٹر کے مطابق spot trading fee پر زیادہ سے زیادہ 20% رعایت ممکن ہے؛ حقیقی شرح، اہلیت، علاقائی دستیابی اور موجودہ Binance terms خود check کریں۔