Circulating، Total اور Maximum Supply میں فرق

آخری نظرثانی: 2026-08-17T12:38:00+08:00
دائرۂ کار: یہ رہنمائی circulating، total اور maximum supply کو الگ پہچاننے اور میم کوائن کے اعداد دوبارہ جانچنے کے لیے ہے۔ یہاں دکھائے گئے حساب فرضی ہیں؛ site کوئی live market API استعمال نہیں کرتی۔

ایک میم کوائن کے صفحے پر تین supply numbers نظر آئیں تو سب سے بڑا عدد اٹھا کر price سے ضرب دینا آسان ہے، مگر اکثر غلط۔ Circulating supply بازار میں شمار کی گئی موجودہ float کا اندازہ ہے۔ Total supply اب تک بنائے گئے tokens میں سے تسلیم شدہ burns نکالنے کی کوشش کرتی ہے۔ Maximum supply وہ آخری حد ہے جو protocol یا contract کے مطابق کبھی موجود ہو سکتی ہے—اگر ایسی حد واقعی مقرر اور enforce ہو۔ یہ تینوں labels ایک ہی سوال کا جواب نہیں دیتیں۔

فہرست

• تین supply اعداد کا سیدھا فرق
• Circulating supply کیسے بنتی ہے
• Total supply میں کیا شامل ہوتا ہے
• Maximum supply کب قابلِ اعتماد ہے
• Chain کا totalSupply اور provider کا عدد کیوں مختلف ہو سکتا ہے
• Burn، lock اور bridge کو کیسے شمار کریں
• اپنی supply تحقیق کیسے کریں
• فرضی مثال سے تینوں حساب
• عام غلطیاں
• سوالات و جوابات

تین supply اعداد کا سیدھا فرق

Circulating supply موجودہ public float کا اندازہ، total supply موجودہ issued units کا حساب، اور maximum supply نظریاتی آخری ceiling ہے۔ CoinGecko Supply Methodology تینوں کو الگ بیان کرتی ہے: circulating کو total میں سے uncirculated wallets نکال کر estimate کیا جا سکتا ہے، total minted units میں سے permanently burned tokens نکالتی ہے، اور max supply coded theoretical maximum ہوتی ہے۔

Supply label	بنیادی مطلب	عام استعمال	جس بات کی ضمانت نہیں
Circulating	public market میں شمار کی گئی دستیاب مقدار	market cap	ہر unit واقعی اسی لمحے فروخت کے لیے موجود ہے
Total	موجود issued/minted مقدار، تسلیم شدہ burns کے بعد	current issued valuation اور supply reconciliation	تمام units آزادانہ circulate کر رہی ہیں
Maximum	lifetime میں ممکنہ آخری مقدار	FDV یا long-term ceiling scenario	cap واقعی immutable ہے یا کبھی پوری mint ہوگی

CoinMarketCap کی supply methodology بھی circulating کو public hands کا بہترین تخمینہ، total کو issued supply net of verifiable burns، اور max کو theoretical maximum net of burns کہتی ہے۔ دونوں providers کے الفاظ قریب ہیں، مگر excluded wallet rules، verification status اور update timing مختلف ہو سکتے ہیں۔ اسی لیے دو websites کا اختلاف خود بخود کسی ایک کی غلطی ثابت نہیں کرتا۔

کون سا عدد کس فارمولے میں جاتا ہے؟

Market cap عموماً circulating supply استعمال کرتی ہے:

Market cap = موجودہ price × circulating supply

FDV اکثر maximum یا provider کے متعلقہ full-supply denominator سے بنتی ہے:

FDV = موجودہ price × maximum supply

اگر hard maximum دستیاب نہ ہو تو کچھ services total supply سے diluted valuation دکھا سکتی ہیں۔ Label اور methodology پڑھے بغیر FDV کو ایک universal formula نہ سمجھیں۔ CoinGecko کی market cap وضاحت یہ بھی واضح کرتی ہے کہ market cap project میں داخل حقیقی cash نہیں؛ marginal price کو circulating units پر پھیلایا جاتا ہے۔

Circulating supply کیسے بنتی ہے

Circulating supply صرف contract call نہیں؛ یہ wallet classification اور provider methodology سے بنا market-data estimate ہے۔ Chain پر ہر address کا balance دکھ سکتا ہے، مگر یہ فیصلہ کہ کون سا balance “public circulation” میں ہے، اضافی context مانگتا ہے۔

Providers عام طور پر locked، team، private investor، treasury، ecosystem reserve یا غیر فروخت پذیر allocations کو circulation سے خارج کر سکتے ہیں۔ مگر کسی wallet کا unlocked ہونا لازماً public float نہیں، اور locked ہونا لازماً permanent exclusion نہیں۔ Vesting ختم ہونے، treasury transfer، airdrop distribution یا exchange deposit سے classification بدل سکتی ہے۔

Circulating figure چیک کرتے وقت کیا لکھیں؟

چار چیزیں محفوظ کریں:

1. عدد اور data provider؛
2. observation کا timestamp؛
3. provider کی supply methodology؛
4. خارج کیے گئے بڑے wallets یا category notes۔

اگر project self-reported circulating supply دے تو اسے issuer claim کے طور پر لکھیں، پھر explorer holder list، vesting contracts اور provider status سے cross-check کریں۔ Exact number پر مصنوعی یقین بنانے کے بجائے discrepancy کی وجہ درج کریں۔

Unlock circulating supply کو کیسے بدلتا ہے؟

پہلے سے minted token vesting contract میں بند ہو تو وہ total supply میں شامل مگر circulating میں خارج ہو سکتا ہے۔ Unlock کے بعد total وہی رہ سکتی ہے جبکہ circulating بڑھ جائے۔ اگر reward emission کے وقت نئے tokens mint ہوں تو total اور circulating دونوں بدل سکتے ہیں۔ Unlock اور mint کو ایک لفظ میں ملانا dilution research کو خراب کرتا ہے۔

اس لیے schedule پڑھتے وقت “کتنے tokens release ہوں گے” کے ساتھ “کیا یہ units پہلے سے total میں ہیں” بھی پوچھیں۔ مزید عملی طریقہ token unlock اور vesting verify کرنے کی رہنمائی میں ہے۔

Total supply میں کیا شامل ہوتا ہے

Total supply موجودہ token issuance کا on-chain نقطۂ آغاز ہے، public float کا مترادف نہیں۔ ERC-20 standard میں totalSupply() موجودہ total token supply واپس کرنے والا interface ہے۔ EIP-20 specification اس function کو standard method کے طور پر درج کرتی ہے، مگر maximum cap یا circulating classification مقرر نہیں کرتی۔

Ethereum.org کی حقیقی ERC‑20 دستاویز، 2026-08 میں اسکرین شاٹ لی گئی۔ تصویر میں standard کی مثالوں کے ساتھ network پر total supply حاصل کرنے کی صلاحیت واضح ہے۔

Ethereum.org ERC-20 page دکھاتا ہے کہ token contract total supply اور account balances پڑھنے کا standard interface دے سکتا ہے۔ پھر بھی totalSupply() سے یہ معلوم نہیں ہوتا کہ tokens کس کے پاس ہیں، کتنے locked ہیں، کون سے bridge backing ہیں یا مزید minting ممکن ہے۔

Decimals کی غلطی سے total supply کیسے بگڑتی ہے؟

Contract اکثر raw integer واپس کرتا ہے۔ Human-readable amount کے لیے raw value کو 10^decimals سے divide کرنا پڑتا ہے۔ Ethereum.org کی ERC-20 contract tutorial خبردار کرتی ہے کہ ہر token کے decimals لازماً 18 نہیں ہوتے۔ اگر explorer کی formatted value اور raw call compare کر رہے ہوں تو decimals دونوں جگہ ایک جیسے apply کریں۔

مثلاً raw total 500000000000000000000 اور decimals 18 ہوں تو display total 500 tokens ہے، پانچ سو quintillion نہیں۔ Meme coin کی بڑی supply میں ایک decimal mistake market cap اور FDV کو کئی orders of magnitude غلط کر سکتی ہے۔

Total supply اور holder balances کیوں reconcile نہیں ہوتے؟

Holder list pagination، hidden contract balances، rebasing mechanics، reflection accounting، bridge contracts یا explorer indexing delay فرق پیدا کر سکتے ہیں۔ سب visible holder rows کو جمع کر کے total سے ملانا مفید check ہے، مگر mismatch آئے تو فوراً fraud conclusion نہ دیں۔ Token mechanics اور explorer coverage پڑھیں۔

Maximum supply کب قابلِ اعتماد ہے

Maximum supply مضبوط تب ہے جب code، governance اور deployment structure اسے بڑھنے سے روکتے ہوں۔ Whitepaper کا عدد اکیلا technical ceiling نہیں۔ Contract میں cap check، mint functions، owner/roles اور proxy upgrade authority دیکھیں۔

OpenZeppelin ERC-20 API بتاتی ہے کہ base ERC-20 implementation خود supply mechanism سے agnostic ہے؛ derived contract میں _mint کے ذریعے mechanism شامل کیا جاتا ہے۔ اسی library کا ERC20Capped extension minting کے وقت total supply پر cap enforce کرتا ہے۔ اس کا مطلب یہ نہیں کہ ہر ERC-20 capped ہے۔

Maximum supply verify کرنے کے لیے یہ ترتیب رکھیں:

• verified source میں cap constant یا constructor value تلاش کریں؛
• ہر mint path دیکھیں کہ cap check سے گزرتا ہے؛
• proxy ہو تو current implementation اور upgrade admin لکھیں؛
• role-based minting ہو تو minter اور role admin شناخت کریں؛
• governance cap بدل سکتی ہو تو process اور timelock note کریں؛
• source unverified ہو تو “hard cap independently verified نہیں” صاف لکھیں۔

اگر maximum undefined ہو اور emissions جاری رہ سکتی ہوں تو ایک lifetime FDV number نامکمل ہے۔ مختلف future supply scenarios—مثلاً ایک سال، تین سال اور پانچ سال—زیادہ دیانت دار ہیں۔ FDV کی تفصیلی رہنمائی denominator اور price assumptions کو الگ دکھاتی ہے۔

Chain کا totalSupply اور provider کا عدد کیوں مختلف ہو سکتا ہے

فرق اکثر definition، burn treatment، chain aggregation یا update time سے آتا ہے۔ Explorer current contract state پڑھ سکتا ہے، جبکہ market-data provider token migration، excluded addresses اور circulating methodology شامل کرتا ہے۔

Blockscout token information API total supply، decimals، holders اور exchange rate جیسے fields دے سکتی ہے۔ یہ useful snapshot ہے، مگر field names کو economic interpretation نہ سمجھیں۔ Explorer کا total_supply circulating supply نہیں، اور exchange rate کی موجودگی liquid market کی ضمانت نہیں۔

Price اور supply ایک وقت کے ہونے چاہییں

Price آج کی اور supply کئی دن پرانی ہو تو market cap discrepancy پیدا ہو سکتی ہے۔ ہر observation کے ساتھ timezone والا RFC3339 timestamp رکھیں۔ Dynamic dashboard screenshot کو ہمیشہ اس لمحے کی snapshot کہیں، مستقل fact نہیں۔

Token migration

Old contract سے new contract پر swap ہو تو دونوں contracts کچھ عرصہ supply دکھا سکتے ہیں۔ Official migration ratio، canonical contract، old-token burn/lock اور provider mapping دیکھیں۔ دونوں totals جمع کرنا double count بن سکتا ہے۔

Burn، lock اور bridge کو کیسے شمار کریں

Burn total کو کم کر سکتا ہے، lock صرف availability بدل سکتا ہے، اور bridge ایک ہی economic unit کی دوسری chain پر نمائندگی بنا سکتا ہے۔ تینوں کو “supply کم یا زیادہ” کہہ کر ملانا غلط ہے۔

OpenZeppelin Contracts 5.x کی حقیقی ERC20Burnable دستاویز، 2026-08 میں اسکرین شاٹ لی گئی۔ یہ extension holder کے tokens کو قابلِ شناخت طریقے سے destroy کرنے کے functions دکھاتی ہے۔

Burn

Protocol-level burn total supply گھٹا سکتی ہے۔ Zero/dead address transfer کو provider burn مان سکتا ہے، مگر verify کریں کہ tokens واپس نہیں آ سکتے اور methodology اسے کیسے treat کرتی ہے۔ Cumulative marketing claim کو current net total کے برابر نہ سمجھیں۔ OpenZeppelin ERC20Burnable event analysis سے پہچانے جانے والے burn functions کی مثال ہے۔

Lock

Vesting یا treasury lock tokens کو unavailable بنا سکتا ہے، مگر units total supply میں رہتی ہیں۔ Unlock پر total لازم نہیں بدلتی؛ circulating classification بدل سکتی ہے۔ Lock contract، beneficiary، cliff اور release function دیکھیں۔ صرف wallet label کافی نہیں۔

Bridge

Origin chain پر 10 ارب tokens escrow میں lock ہوں اور destination chain پر 10 ارب wrapped units mint ہوں تو economic representation عموماً 10 ارب ہی رہتی ہے، 20 ارب نہیں—بشرطیکہ backing one-to-one ہو۔ Cross-chain total بناتے وقت backing اور representation دونوں کو جمع نہ کریں۔ Bridge pause یا exploit risk الگ نوٹ کریں۔

اپنی supply تحقیق کیسے کریں

قابلِ تکرار تحقیق contract identity سے شروع ہوتی ہے، dashboard کے بڑے عدد سے نہیں۔ نیچے کی آٹھ قدم workflow ہر میم کوائن پر استعمال کی جا سکتی ہے۔

1. Official documentation سے network اور canonical contract address لیں۔
2. Explorer پر address، symbol، decimals اور verified source match کریں۔
3. totalSupply() کی formatted value اور timestamp محفوظ کریں۔
4. Market-data provider سے circulating، total اور max تینوں labels نقل کریں۔
5. Provider methodology میں excluded wallets اور burn rule پڑھیں۔
6. Mint، cap، proxy، owner اور roles کی permissions check کریں۔
7. Vesting، treasury، bridge اور burn addresses الگ categories میں رکھیں۔
8. Differences کو explanation سمیت لکھیں؛ numbers کو زبردستی برابر نہ کریں۔

اپنے verified inputs circulating supply tool میں رکھ کر ratio نکال سکتے ہیں۔ یہ tool user-entered values پر arithmetic کرتا ہے، chain یا exchange سے live data نہیں کھینچتا۔ Source URL اور timestamp خود محفوظ کرنا ضروری ہے۔

فرضی مثال سے تینوں حساب

ایک ہی token کے تین supply numbers تین مختلف مگر compatible نتائج دے سکتے ہیں۔ فرض کریں price $0.002، circulating 20 ارب، total 70 ارب اور verified hard maximum 100 ارب ہے۔

حساب	فارمولا	فرضی نتیجہ
Market cap	0.002 × 20bn	$40m
Issued-supply valuation	0.002 × 70bn	$140m
Max-supply FDV	0.002 × 100bn	$200m
Circulating / total	20 ÷ 70	28.6%
Circulating / max	20 ÷ 100	20%

یہ table price prediction نہیں۔ باقی 50 یا 80 ارب tokens کب market میں آئیں گے، یہ vesting، emissions، minting اور demand پر منحصر ہے۔ نئی supply کے وقت rate بدل جائے تو بعد کی valuation اس snapshot کے diluted عدد سے مختلف نکل سکتی ہے۔

اس مثال میں اگلا مفید سوال “کون سا number صحیح ہے؟” نہیں بلکہ “ہر number کس definition اور date سے آیا؟” ہے۔ Circulating estimate market cap کے لیے، total current issuance کے لیے، اور max long-term ceiling scenario کے لیے استعمال ہوا۔

عام غلطیاں

Supply research کی زیادہ تر غلطیاں arithmetic سے پہلے ہوتی ہیں۔ Final note سے پہلے یہ فہرست دیکھیں:

• symbol سے token چن لینا اور contract address نہ ملانا؛
• total کو circulating لکھ کر market cap بڑھا دینا؛
• max کو current total سمجھنا؛
• raw integer پر decimals apply نہ کرنا؛
• locked tokens کو burned کہنا؛
• bridge escrow اور wrapped supply دونوں جمع کرنا؛
• owner renounced دیکھ کر دیگر mint roles بھول جانا؛
• old اور migrated contracts کی supplies جوڑ دینا؛
• مختلف timestamps کے price اور supply ملانا؛
• provider methodology پڑھے بغیر discrepancy کو manipulation کہنا؛
• unlock percentage کو یقینی price fall بنا دینا؛
• فرضی scenario کو live data کی طرح پیش کرنا۔

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

کیا circulating supply chain پر براہِ راست ملتی ہے؟

عام طور پر نہیں۔ Chain balances اور total supply دیتی ہے؛ circulating figure provider کی wallet classification، locks اور public availability methodology سے بن سکتی ہے۔

کیا total supply ہمیشہ totalSupply() کے برابر ہوتی ہے؟

سادہ ERC-20 میں قریب ہو سکتی ہے، مگر provider burns، migration یا chain aggregation الگ treat کر سکتا ہے۔ Rebase، reflection اور bridge mechanics بھی reconciliation مشکل بنا سکتے ہیں۔

Maximum supply نہ ہو تو کیا لکھیں؟

“No verified hard maximum” لکھیں، current total دکھائیں اور future issuance scenarios بنائیں۔ Open-ended supply پر ایک آخری lifetime FDV نہ گھڑیں۔

Burn سے circulating اور total دونوں کم ہوتے ہیں؟

Protocol burn total کم کر سکتی ہے؛ circulating effect اس بات پر ہے کہ burned units پہلے circulating میں شمار تھیں یا excluded wallet میں۔ Provider methodology چیک کریں۔

Locked team tokens total میں ہوتے ہیں؟

اگر پہلے سے mint ہو چکے ہوں تو عموماً total میں شامل اور circulating سے خارج ہو سکتے ہیں۔ اگر future میں mint ہونے ہیں تو current total میں نہیں ہوں گے۔

دو data providers کے numbers مختلف ہوں تو کیا کریں؟

دونوں کے timestamp، definitions، excluded wallets، burn treatment اور chain coverage لکھیں۔ اپنی contract observations الگ رکھیں اور range یا discrepancy note دیں۔

کون سا supply ratio محفوظ سمجھا جاتا ہے؟

کوئی universal safe ratio نہیں۔ Low ratio future dilution کی تحقیق بڑھاتا ہے، مگر schedule، recipients، liquidity اور mint authority فیصلہ کن context دیتے ہیں۔

نتیجہ

Circulating، total اور maximum supply کو تین الگ layers سمجھیں: market float، current issuance اور possible ceiling۔ درست contract سے شروع کریں، decimals اور totalSupply() verify کریں، پھر provider methodology سے circulating exclusions پڑھیں۔ Burn، lock، migration اور bridge کو الگ categories دیں، اور maximum supply کو code اور permissions کے بغیر یقینی cap نہ کہیں۔

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