میم کوائن کی قیمت اور سپلائی کیسے تصدیق کریں؟

دو websites پر ایک meme coin کی price یا supply مختلف ہو تو پہلا کام “صحیح number” چننا نہیں، بلکہ یہ ثابت کرنا ہے کہ دونوں ایک ہی asset، chain، وقت اور definition کی بات کر رہے ہیں۔ Ticker، logo یا page title کافی نہیں۔ Contract یا mint address سے identity بند کریں، ہر reading کو timestamp دیں، اور single-chain on-chain field کو multi-chain یا methodology-based figure سے الگ رکھیں۔

یہ رہنمائی user کو ایک ایسا reconciliation sheet بنانے میں مدد دیتی ہے جس میں price snapshot، total supply، circulating supply، max supply، burn، bridge اور decimals کے اختلاف صاف نظر آئیں۔ مقصد live price feed دینا یا کسی platform کے عدد کو مستقل سچ قرار دینا نہیں۔

پہلے پورا workflow دیکھیں

1. Official source سے contract یا mint address لیں
2. Chain، decimals، token type اور migration status لکھیں
3. Price readings کو source، currency اور timestamp کے ساتھ freeze کریں
4. On-chain total supply کو raw units سے verify کریں
5. Circulating اور max supply کی methodology الگ پڑھیں
6. Burn، locked wallets اور mint authority شامل کریں
7. Multi-chain اور bridge accounting حل کریں
8. اختلاف کو documented، observed اور unresolved خانوں میں رکھیں
9. Market cap یا FDV میں صرف compatible inputs استعمال کریں
10. نئی snapshot کے ساتھ نتیجہ دوبارہ check کریں

مختصر جواب: price اور supply cross-check کی بنیادی شرط

قیمت کی comparison تب قابلِ معنی ہے جب asset identity اور observation time match ہوں۔ Supply comparison تب قابلِ معنی ہے جب chain scope، field definition، decimals اور excluded wallets match ہوں۔ Price اور supply دونوں درست دکھ سکتے ہیں مگر ان کے scopes مختلف ہوں؛ اسی لیے “دو numbers مختلف ہیں” خود بخود data error نہیں۔

ایک مضبوط record ہر value کے ساتھ یہ metadata رکھتا ہے:

Field	کیا محفوظ کرنا ہے؟
Identity	chain + مکمل contract/mint address
Source	exact URL یا API endpoint
Field name	exchange_rate، total_supply، circulating وغیرہ
Raw value	source جیسا ملا
Display value	decimals کے بعد human-readable amount
Currency	USD، USDT، ETH یا دوسری unit
Scope	single chain، combined chains، pool یا aggregator
Timestamp	RFC3339 + timezone
Methodology	calculation/exclusion rules کا link
Confidence	confirmed، supported، provisional یا unresolved

Step 1: Asset identity contract سے بند کریں

Project کی official website، repository یا documentation سے contract/mint address لیں۔ پھر explorer میں پورا address match کریں۔ Market data platform کی search result صرف discovery tool ہے؛ ایک ہی ticker کے fake، migrated، wrapped یا bridged versions ہو سکتے ہیں۔

اس مضمون کا cover Blockscout کے FLOKI Ethereum address endpoint کا حقیقی snapshot ہے، جو 2026-08-01T18:03:55+08:00 پر لیا گیا۔ اس میں مکمل address، is_verified: true، token name/symbol، exchange_rate اور total_supply fields ایک ہی response میں دکھائی دیتی ہیں۔ یہ صرف اسی endpoint اور capture time کا evidence ہے؛ آج کی price، FLOKI کی تمام chains یا circulating supply ثابت نہیں کرتا۔

Identity card میں یہ لکھیں:

• official name اور symbol
• chain اور chain ID
• مکمل address
• native، wrapped، bridged یا migrated status
• token standard/program
• decimals
• official source URL
• explorer verification status

is_verified source-code verification بتا سکتی ہے، investment safety نہیں۔ Verified token contract بھی concentrated ownership، weak liquidity یا risky permissions رکھ سکتا ہے۔

Step 2: EVM اور Solana supply fields الگ پڑھیں

EVM ERC-20 token میں EIP-20 totalSupply() کو standard interface کا حصہ بناتا ہے۔ balanceOf wallets کے balances اور Transfer movement دکھاتا ہے۔ Mint کے لیے zero address سے Transfer event کی سفارش ہے، مگر ہر deployed token کی implementation اور compliance verify کرنا پڑتی ہے۔

Solana asset کو صرف ticker سے شناخت نہ کریں؛ اس کا منفرد mint address اصل نقطۂ آغاز ہے۔ سرکاری Get a Token Mint رہنمائی کے مطابق اسی account سے موجودہ supply، authority اور decimals حاصل کیے جاتے ہیں۔ Mint authority باقی ہو تو future issuance ممکن ہو سکتی ہے؛ authority absent ہو تو بھی program extensions اور token type سمجھیں۔

دو chains کی raw fields کو ایک table میں لاتے وقت standard کا نام ضرور لکھیں۔ ERC-20 totalSupply() اور Solana mint supply دونوں units بتا سکتے ہیں، مگر contract controls، bridges اور burn mechanics ایک جیسے نہیں۔

Step 3: Decimals کی غلطی پہلے ختم کریں

On-chain raw integer اکثر display amount نہیں ہوتا۔ Human-readable amount عام طور پر یہ ہے:

Display units = raw integer ÷ 10^decimals

فرضی مثال: raw supply 1000000000000 اور decimals 9 ہوں تو display supply 1,000 units بنتی ہے۔ اگر decimals 6 سمجھ لی جائیں تو نتیجہ 1,000,000 ہو جائے گا—ایک ہی raw value سے ہزار گنا فرق۔

API string، browser-formatted number اور localized commas کو الگ رکھیں۔ Scientific notation copy کرنے سے precision ضائع ہو سکتی ہے۔ Raw field کو text کے طور پر محفوظ کریں، conversion formula اور decimals source ساتھ لکھیں۔

Step 4: Price snapshot کو “on-chain truth” نہ کہیں

Explorer address page پر price field ہو سکتی ہے، مگر وہ value کسی external aggregator یا selected market feed سے آ سکتی ہے۔ DEX pool price reserves اور route سے نکل سکتی ہے؛ CEX price last trade یا order-book basis پر ہو سکتی ہے؛ aggregator کئی tickers کو combine کر سکتا ہے۔

CoinGecko کی price-difference وضاحت volume-weighted average کو مختلف exchanges اور pairs سے جوڑتی ہے۔ اس کی chart-error methodology note approved spot tickers، USD conversion، outlier handling اور VWAP کی وضاحت کرتی ہے۔ یہ کسی single pool کے executable quote کے برابر نہیں۔

ہر price row میں لکھیں:

• displayed value اور quote currency
• source/venue یا aggregator
• observation time
• source کا last-updated time، اگر موجود ہو
• spot، last trade، index، VWAP یا conversion field
• contract/address mapping
• executable quote ہے یا صرف reference

دو snapshots 29 منٹ apart ہوں تو انہیں simultaneous comparison نہ کہیں۔ Volatile token میں اتنا gap meaningful ہو سکتا ہے۔

Step 5: Supply labels کی methodology دیکھیں

یہ حقیقی CoinGecko Supply Methodology screenshot ہے، جسے 2026-08-17T16:49:49+08:00 پر محفوظ کیا گیا۔ تصویر Max Supply کو coded theoretical maximum اور Total Supply کو minted amount minus permanently burned tokens کے طور پر دکھاتی ہے۔ Page کی definitions CoinGecko methodology ہیں؛ انہیں ہر explorer یا project پر خودکار طور پر لاگو نہ کریں۔

چار labels الگ رکھیں:

• On-chain supply: contract یا mint account کا current field
• Total supply: provider کی burn treatment کے بعد figure
• Circulating supply: public market میں active units کا methodology-based estimate
• Max supply: code cap، policy cap، infinite/uncapped یا unknown

Circulating supply direct universal contract call نہیں۔ Provider locked، vested، team، foundation، treasury یا ecosystem wallets کو rules کے مطابق exclude کر سکتا ہے۔ اسی لیے two providers کے circulating numbers مختلف اور پھر بھی internally consistent ہو سکتے ہیں۔

Step 6: Burn کی تعریف verify کریں

Zero/dead address پر token بھیجنا، contract-level supply reduce کرنا اور inaccessible wallet claim تین مختلف mechanisms ہو سکتے ہیں۔ totalSupply() واقعی کم ہوئی یا provider نے balance کو circulating/total سے subtract کیا؟ دونوں cases نوٹ کریں۔

Burn evidence کے لیے transaction hash، address، amount، event، block اور supply before/after دیکھیں۔ Project کے “burned” claim کو label کے ساتھ رکھیں جب تک chain effect independently verify نہ ہو۔ Buyback announcement completed burn نہیں؛ intended action اور observed event الگ ہیں۔

Step 7: Multi-chain scope کو واضح کریں

یہ FLOKI official FAQ کا حقیقی snapshot ہے، جو 2026-08-01T17:54:02+08:00 پر لیا گیا۔ Page ETH، BSC اور combined supply values الگ دکھاتا ہے۔ یہ project-reported multi-chain methodology اور capture-time values ہیں؛ اسے Blockscout کے Ethereum-only total_supply کے ساتھ برابر field نہ سمجھیں۔

Multi-chain reconciliation سے پہلے architecture منتخب کریں:

1. Native issuance on each chain: الگ supplies واقعی جمع ہو سکتی ہیں، مگر mint controls دیکھیں۔
2. Lock-and-mint bridge: destination representation source-chain locked balance سے backed ہو سکتی ہے؛ دونوں کو جمع کرنا double count ہو سکتا ہے۔
3. Burn-and-mint: source burn اور destination mint کے event timing میں temporary mismatch آ سکتا ہے۔
4. Liquidity network: wrapped liquidity obligations simple token count سے مختلف ہو سکتی ہیں۔

CoinGecko کی Supply Update FAQ native multi-chain issuance اور bridge models کے لیے الگ accounting cases بیان کرتی ہے۔ Asset-specific result کے لیے bridge contracts، official documentation اور current chain state پھر بھی دیکھیں۔

Step 8: Price اختلاف کا diagnostic tree

Price A اور Price B مختلف ہوں تو یہ ترتیب آزمائیں:

کیا contract ایک ہے؟

نہیں تو comparison روکیں۔ Wrapped، fake یا migrated asset کا سوال حل کریں۔

کیا timestamp قریب ہے؟

نہیں تو fresh snapshots لیں۔ پرانی value کو current error نہ کہیں۔

کیا currency ایک ہے؟

USD، USDT، USDC یا local fiat conversion میں depeg یا FX فرق ہو سکتا ہے۔

کیا price type ایک ہے؟

Single-pool spot، last trade، executable quote اور aggregated VWAP مختلف products ہیں۔

کیا venue liquid ہے؟

Thin pair کا outlier print broad market value نہیں۔ Order-book depth یا pool liquidity دیکھیں۔ CoinGecko Trust Score methodology liquidity، order-book depth، spread اور reported volume consistency کو exchange-quality context میں رکھتی ہے؛ score کو individual token safety guarantee نہ بنائیں۔

کیا route یا token tax شامل ہے؟

DEX quote token tax، pool fee یا multiple hops سے مختلف ہو سکتی ہے۔ Screen price کے بجائے actual buy/sell size quote compare کریں۔

Step 9: Supply اختلاف کا diagnostic tree

Raw field اور label کیا ہیں؟

total_supply نام دکھنے کے باوجود decimals یا burn treatment معلوم کریں۔

Chain scope match ہے؟

Ethereum-only value کو combined ETH+BSC figure سے compare نہ کریں۔

Snapshot block/time ایک ہے؟

Mint یا burn کے دوران adjacent blocks بھی فرق پیدا کر سکتے ہیں۔

Excluded wallets کون سے ہیں؟

Circulating methodology میں team، vesting، treasury، ecosystem، bridge vault اور burn addresses کا treatment لکھیں۔

Max supply code سے ثابت ہے؟

Project policy future governance سے بدل سکتی ہے؛ immutable cap، role-controlled mint اور “no cap” الگ risks ہیں۔

Migration یا denomination ہوئی؟

Old/new contracts، token split یا redenomination numbers کو nominally مختلف بنا سکتے ہیں۔ Official migration ratio اور deadline دیکھیں۔

Step 10: Reconciliation table بنائیں

فرضی example:

Source	Scope	Field	Value	Time	Status
Explorer A	Ethereum contract	totalSupply	1.0B	T1	observed
Project page	ETH + BSC	combined supply	1.6B	T2	documented
Aggregator	multi-market	circulating	1.2B	T3	methodology estimate
DEX pool	one pair	executable sell quote	0.0042	T4	size-specific

اس table سے “400M لازماً locked ہیں” نتیجہ نہیں نکلتا۔ Bridge backing، burns، excluded wallets اور snapshot times ابھی حل ہونے چاہییں۔ درست interim result یہ ہے کہ fields اور scopes مختلف ہیں۔

اپنا conclusion چار حصوں میں لکھیں:

• Confirmed identity: address، chain، decimals
• Observed: raw chain/API fields اور timestamps
• Methodology-based: circulating/aggregated price calculations
• Unresolved: scope، bridge، burn یا update mismatch

Compatible price اور supply pair کیسے چنیں؟

Market cap کے لیے price اور circulating supply ایک ہی economic asset scope کی نمائندگی کریں۔ Ethereum-only illiquid pool price کو broad multi-chain circulating supply سے ضرب دینے پر number بن جائے گا، مگر وہ meaningful valuation لازماً نہیں۔

FDV میں max یا fully diluted supply استعمال کرنے سے پہلے cap اور mint permissions verify کریں۔ Tool arithmetic کو source validation نہ سمجھیں۔ Market cap tool اور FDV tool میں input کے ساتھ source، date، currency اور definition محفوظ کریں۔ Supply concepts کے لیے circulating، total اور max supply الگ تفصیل دیتی ہے۔

Screenshot اور API evidence کی حد

Screenshot page کی visible state دکھاتی ہے، source calculation نہیں۔ API response field دیتی ہے، مگر upstream feed یا cache الگ ہو سکتی ہے۔ دونوں کے ساتھ exact URL، captured time اور scope لکھیں۔ Dynamic value کو مضمون کی مستقل حقیقت نہ بنائیں؛ caption میں snapshot واضح کریں۔

API endpoint later schema بدل سکتا ہے۔ Raw JSON save کرتے وقت secret key یا internal URL شامل نہ کریں۔ Public endpoint کی screenshot میں بھی browser extensions، wallet addresses یا account data نظر آئے تو redact یا نئی clean capture لیں۔

Update cadence کیسے طے کریں؟

Price-sensitive observation decision کے وقت تازہ لیں۔ Supply snapshot material mint، burn، unlock، migration یا bridge change کے بعد دوبارہ لیں۔ Static article میں live number نہ لکھیں جب live API موجود نہیں؛ methodology اور verification steps لکھیں، جبکہ historical screenshot کو date کے ساتھ label کریں۔

دو checks useful ہیں:

• Identity check: contract/mint migration یا naming change ہوا؟
• Data check: source fields، methodology یا supply events بدلے؟

Calendar-based “ہر ہفتے لازماً number update” مفید تب ہے جب source واقعی بدلتا ہو۔ Event-based review زیادہ اہم ہے۔

Evidence lineage map

ہر final value کے پیچھے lineage لکھی جائے: value کہاں دیکھی، کس field سے آئی، کس transformation سے گزری اور کس formula میں استعمال ہوئی۔ مثال: Blockscout total_supply raw → decimals conversion → single-chain issued supply۔ دوسری مثال: provider circulating field → methodology exclusions → market-cap denominator۔ Lineage کے بغیر صحیح دکھنے والا number بھی audit نہیں ہو سکتا۔

ایک lineage row میں source host، exact endpoint/page، asset identity، raw value، unit، scope، observation time، transformation، output اور reviewer note شامل ہوں۔ Screenshot صرف visual checkpoint ہے؛ raw API response یا visible field text الگ محفوظ کریں۔ اگر source بعد میں بدل جائے تو old snapshot اپنی تاریخ کے ساتھ باقی رہتی ہے۔

Decimal and unit test cases

Decimals conversion کو صرف ایک calculator پر نہ چھوڑیں۔ تین test cases بنائیں: raw value صفر کے قریب، بہت بڑا raw integer، اور value جس میں fractional display units ہوں۔ Calculation دو آزاد طریقوں سے check کریں، مثلاً spreadsheet formula اور simple local arithmetic۔ Scientific notation استعمال ہو تو original integer بھی محفوظ رکھیں۔

Common unit failures:

• 6 decimals کو 18 سمجھ لینا
• comma یا locale separator غلط پڑھنا
• wei-like raw amount کو whole token کہنا
• percentage کو decimal میں تبدیل نہ کرنا
• USD اور USDT کو timestamp کے بغیر برابر کہنا
• billions label اور exact integer mix کرنا

اگر conversion سے provider display match نہ ہو تو rounding، token upgrade، rebasing behavior یا غلط contract check کریں۔ Difference چھپا کر provider number copy نہ کریں۔

Rebase، reflection اور elastic supply tokens

ہر token fixed-balance ERC-20 جیسا behave نہیں کرتا۔ Rebase mechanism holder balances کو proportionally بدل سکتا ہے۔ Reflection یا fee-on-transfer model balances/received amounts میں extra behavior لاتا ہے۔ Wrapped representation underlying asset سے مختلف accounting رکھ سکتی ہے۔ Contract documentation اور verified logic سے mechanism classify کیے بغیر simple total/circulating comparison گمراہ ہو سکتا ہے۔

Rebase asset میں دو snapshots کے balance فرق کو transfer نہ کہیں جب supply adjustment ممکن ہو۔ Reflection token میں received amount quote سے کم یا balance movement سے مختلف ہو سکتا ہے۔ Methodology note میں token behavior لکھیں اور ایسے field کو standard calculator میں ڈالنے سے پہلے limitation نمایاں کریں۔

Mint authority اور max supply confidence

Max supply کو confidence levels دیں:

• Code-enforced: reachable mint paths کے باوجود hard cap logic واضح
• Policy-stated: project document limit بتاتی ہے مگر code enforcement ثابت نہیں
• Provider-labeled: aggregator نے max field دیا، primary mechanism واضح نہیں
• Undefined: کوئی قابلِ دفاع cap نہیں

totalSupply() current issued supply دکھا سکتی ہے، future maximum نہیں۔ Mint role، owner، proxy admin یا upgrade path cap کی interpretation بدل سکتے ہیں۔ “Max supply = total supply” صرف numbers equal ہونے سے ثابت نہیں؛ future issuance authority الگ دیکھنی ہے۔

Burn reconciliation

Burn کے لیے تین evidence layers الگ کریں: protocol burn event/function، ناقابلِ خرچ address balance، اور provider methodology۔ Project کا “burned” claim transaction یا chain state سے match ہونا چاہیے۔ Dead-address transfer circulating estimate سے exclude ہو سکتا ہے، مگر contract totalSupply() تبھی کم ہو گا جب mechanism supply کو واقعی reduce کرے۔

Burn table:

Evidence	observed amount	total supply پر اثر	circulating treatment	status
burn function/event	value	code کے مطابق	provider method	confirmed/supported
dead address	balance	لازماً نہیں	ممکن exclusion	supported/unknown
project statement	claimed value	claim only	claim only	documented

یہ table supply disagreement کا بڑا حصہ واضح کر سکتی ہے۔ ایک ہی burn amount کو event اور address balance دونوں سے double-count نہ کریں۔

Bridge conservation test

Bridge model میں source vault inflow اور destination mint کو pair کریں۔ Lock-and-mint میں economic units conserve ہو سکتے ہیں: source پر liquid supply کم، destination wrapped supply بڑھے، مگر combined economic supply لازماً double نہیں ہوتی۔ Native multi-chain issuance میں ہر chain کی supply واقعی اضافی ہو سکتی ہے۔ Official bridge docs، contract roles اور event pattern سے model طے کریں۔

Test کے steps:

1. canonical token اور wrapped token identify کریں۔
2. source vault/escrow address verify کریں۔
3. destination mint/burn authority دیکھیں۔
4. matching deposit/mint یا burn/release events sample کریں۔
5. fees اور pending transfers الگ رکھیں۔
6. combined supply formula واضح لکھیں۔

Model unresolved ہو تو single-chain numbers دکھائیں، combined total نہ بنائیں۔

Price source independence test

دو websites قریب price دکھائیں تو upstream independence دیکھیں۔ دونوں ایک ہی exchange ticker، index vendor یا cached API استعمال کر سکتے ہیں۔ Methodology، venue list، update frequency اور outlier rules دستیاب ہوں تو compare کریں۔ Executable DEX quote تیسری evidence class ہے، مگر وہ مخصوص pool/size ہے اور aggregator reference کے برابر نہیں۔

Price table میں source class column شامل کریں۔ Aggregator A اور explorer B کی values اگر ایک ہی upstream provider سے ہوں تو انہیں “دو independent confirmations” نہ لکھیں۔ Conversely، مختلف venues پر temporary spread data error نہیں؛ market fragmentation یا liquidity difference ہو سکتی ہے۔

Stale-data detection

Page capture time اور field update time الگ رکھیں۔ API response میں timestamp نہ ہو تو اسے unknown freshness کہیں۔ Price unchanged ہونا stale ہونے کا proof نہیں، مگر low-activity asset میں caution ہے۔ Supply field مہینوں نہ بدلے تو ممکن ہے supply واقعی fixed ہو یا provider update نہ کر رہا ہو؛ contract/event check سے فرق سمجھیں۔

Staleness indicators:

• page timestamp absent یا بہت پرانا
• migrated contract کے باوجود old address active دکھنا
• supply project announcement سے مختلف مگر method/update note نہیں
• price venue بند ہونے کے بعد بھی وہی ticker
• decimals یا symbol contract سے mismatch
• explorer اور provider block/time میں بڑا gap

Indicator ملنے پر value حذف نہیں کی جاتی؛ status provisional ہوتا ہے اور final calculation میں sensitivity range دی جاتی ہے۔

Reconciliation decision tree

اگر price مختلف ہے تو identity → timestamp → currency → source class → venue liquidity → aggregation filter ترتیب سے دیکھیں۔ اگر supply مختلف ہے تو identity → decimals → field label → chain scope → burn/lock exclusions → bridge model → methodology version دیکھیں۔ دونوں مختلف ہوں تو پہلے supply اور price separately resolve کریں؛ ایک adjusted number سے دونوں gaps بند نہ کریں۔

Final sheet میں ہر pair کو compatible، conditionally compatible یا incompatible label دیں۔ Market cap صرف compatible price/supply pair سے نکالیں۔ Conditional pair کے ساتھ assumption واضح لکھیں۔ Incompatible pair کا arithmetic دکھانا ضروری ہو تو اسے rejected test کہیں، primary result نہیں۔

Historical comparison policy

دو dates کا market cap compare کرتے وقت دونوں dates کے price، supply اور methodology چاہیے۔ Current supply کو old price سے ضرب دے کر historical market cap نہ بنائیں۔ Provider نے methodology بدلی ہو تو old/new series میں break marker دیں۔ Migration یا redenomination کے بعد per-token price اور supply بدل سکتی ہیں جبکہ economic value relation مختلف رہتا ہے۔

Historical archive میں source snapshots، formulas اور version note شامل ہوں۔ Chart smooth نظر آئے مگر definitions بدل گئی ہوں تو visual continuity misleading ہے۔ Missing period کو interpolate نہ کریں جب method معلوم نہ ہو۔

Reviewer handoff

دوسرا reviewer result کھولے تو اسے یہ معلوم ہونا چاہیے: canonical identity کیا ہے، کون سی chains شامل ہیں، prices کس وقت اور class کی ہیں، supply labels کس methodology سے ہیں، کون سی exclusions کی گئیں، کون سے conflicts unresolved ہیں، اور calculation کب expire سمجھی جائے گی۔

Handoff summary چار blocks میں لکھیں: confirmed observations، provider/project claims، transformations اور open questions۔ یہی separation accidental certainty کم کرتی ہے۔ Live feed نہ ہونے کی وجہ بھی واضح رہے: values user یا researcher نے snapshot کے طور پر داخل کیں، site نے exchange account یا blockchain API سے خودکار sync کا دعویٰ نہیں کیا۔

Stop signs

• Platform contract address نہیں دکھاتا یا official address سے match نہیں
• Source timestamp/last update نامعلوم اور value غیر معمولی ہے
• Price صرف ایک thin pair سے آتی ہے مگر broad market price کہی گئی ہے
• Decimals conversion explain نہیں ہوتی
• Multi-chain supplies bridge model کے بغیر جمع ہیں
• Circulating figure کے excluded wallets معلوم نہیں
• Burn claim کے مقابل total supply یا events reconcile نہیں ہوتے
• Max supply policy لکھی ہے مگر mint authority موجود ہے
• Project page dynamic value کو audit کے بغیر “verified” کہتی ہے
• Different scopes کے numbers کو ایک ہی formula میں ڈال دیا گیا ہے

ایک stop sign fraud کا قطعی ثبوت نہیں، مگر calculation روکنے کی وجہ ہے۔ Missing field کو guess کرنے کے بجائے unresolved لکھیں۔

آخری checklist

• Official contract/mint اور chain verify کیے
• Wrapped، bridged، migrated یا native status لکھا
• Decimals اور raw-to-display conversion محفوظ کی
• Price source، currency، type اور timestamp درج ہیں
• Executable quote اور reference price الگ ہیں
• On-chain، total، circulating اور max labels الگ ہیں
• Burn mechanism chain events سے check کیا
• Mint authority یا cap verify کی
• Multi-chain bridge model معلوم کیا
• Excluded wallets اور methodology link محفوظ ہے
• Different-time snapshots کو synchronous نہیں کہا
• Market cap/FDV میں compatible scope کے inputs ہیں
• Remaining conflict صاف “unresolved” لکھا ہے

عام سوالات

Explorer price کیا on-chain price ہوتی ہے؟

ضروری نہیں۔ Explorer external feed یا aggregator value دکھا سکتا ہے۔ Field کی methodology دیکھیں اور executable pool quote سے الگ رکھیں۔

totalSupply() کیا circulating supply ہے؟

نہیں۔ totalSupply() chain-level issued units کا field ہو سکتا ہے؛ circulating figure locked، treasury، team، bridge اور burn rules کے مطابق estimate ہو سکتی ہے۔

دو chains کی supply ہمیشہ جمع کرنی چاہیے؟

نہیں۔ Native issuance میں جمع ممکن ہو سکتی ہے، جبکہ lock-and-mint bridge میں source locked اور destination minted units جمع کرنا double counting ہو سکتا ہے۔

دو prices مل جائیں تو data verified ہے؟

صرف اتنا کہ دو observations قریب ہیں۔ Upstream source ایک، timestamp مختلف یا liquidity کم ہو سکتی ہے۔ Identity اور methodology پھر بھی check کریں۔

Supply disagreement حل نہ ہو تو کیا لکھیں؟

Raw values، scopes، timestamps اور possible causes دکھائیں، پھر status unresolved رکھیں۔ فرضی balancing number نہ بنائیں۔

آخری احتیاط

Price اور supply verification کا مقصد ایک خوب صورت number نہیں بلکہ reproducible evidence chain ہے۔ Address، chain، decimals، time اور definition میں سے ایک بھی mismatch ہو تو market cap یا FDV غلط سمت لے جا سکتی ہے۔ Static snapshot کو live quote نہ کہیں، project claim کو on-chain observation سے جدا رکھیں، اور نامعلوم بات کو نامعلوم ہی لکھیں۔ Meme coins میں غلط contract، thin liquidity، centralized control اور تیز volatility سے مکمل سرمایہ ضائع ہو سکتا ہے۔

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