قیمت سے آگے: مارکیٹ کیپ، FDV، سپلائی اور ڈائلیوشن سمجھیں

ڈیٹا اور حساب کا طریقۂ کار

ڈیٹا اور حساب کا طریقۂ کار

جانیں کہ سائٹ کے فارمولے کن تعریفوں پر مبنی ہیں، اعداد کہاں سے لینے چاہییں اور نتائج کی تصدیق کیسے کریں۔

Blockscout API reference میں token identity، supply اور exchange-related fields کی الگ ساخت

میم کوائن حساب کوئی live market feed نہیں چلاتی۔ Site کے formulas user-entered values پر کام کرتے ہیں، اور research pages public standards، explorer observations، provider methodologies اور project documents کو الگ evidence layers میں رکھتی ہیں۔ یہ page بتاتا ہے کہ data لیا، label کیا، compare کیا اور uncertainty کے ساتھ report کیا جاتا ہے۔

فہرست

مختصر جواب: ایک قابلِ اعتماد calculation کی شرط

Formula لگانے سے پہلے asset identity، field definition، economic scope، units اور timestamp match ہونے چاہییں۔ دو sources کا number مختلف ہونا لازماً error نہیں؛ وہ different chain، time، price type یا supply methodology measure کر سکتے ہیں۔

Data evidence hierarchy

Layer مثال کیا ثابت کرتی ہے؟ کیا ثابت نہیں کرتی؟
Standard EIP/ERC docs interface/expected behavior deployed token safe ہے
Chain state contract/explorer/events observed state at block/time wallet owner intent
Provider method supply/price methodology calculation/exclusion rules universal definition
Project document tokenomics/vesting disclosed plan current execution
Secondary summary article/calendar discovery/context primary proof

نتیجہ سب سے مضبوط available layer سے شروع ہوتا ہے اور دوسری layer سے cross-check ہوتا ہے۔

Step 1: Identity normalization

Ticker کے بجائے:

  • chain + chain ID
  • complete contract/mint
  • token standard/program
  • decimals
  • native/wrapped/bridged status
  • migration version

محفوظ کیے جاتے ہیں۔ Same symbol multiple assets پر ہو سکتا ہے۔ Official project source اور explorer match نہ ہوں تو calculation pause ہوتی ہے۔

Step 2: Units normalization

EIP-20 ERC-20 totalSupply()، balanceOf() اور related interface behavior کا primary reference ہے۔ Raw integer کو display units میں convert کرنے کا عام rule:

Display units = raw value ÷ 10^decimals

Decimals غلط ہوں تو result orders of magnitude بدل سکتا ہے۔ Raw string، decimals field اور converted amount تینوں record ہوتے ہیں۔ Rounded “B/M” display calculation input نہیں بنتی جب exact field دستیاب ہو۔

Step 3: Timestamp policy

Dynamic observation RFC3339 timezone offset کے ساتھ record کی جاتی ہے، مثلاً 2026-08-17T16:49:49+08:00۔ Source کا own updated time ملے تو capture time سے الگ رکھا جاتا ہے۔

  • observed_at: page/API کب دیکھا
  • source_updated_at: provider نے کب update بتایا
  • block_time: chain event کا timestamp
  • document_date: paper/methodology version

ان times کو ملانا data freshness سمجھنے کے لیے ضروری ہے۔ Historical screenshot کو current value نہیں کہا جاتا۔

Step 4: Price methodology

Price observation کو label کیا جاتا ہے:

  • last trade
  • exchange index
  • aggregated VWAP/reference
  • DEX pool spot
  • executable quote for specified size
  • historical snapshot

CoinGecko price aggregation methodology provider aggregation/filtering context دیتی ہے۔ CoinGecko price-difference note venue اور calculation differences explain کرتی ہے۔

Reference price کو guaranteed execution price نہیں کہا جاتا۔

Step 5: Supply methodology

CoinGecko Supply Methodology page میں Max Supply اور Total Supply کی الگ definitions

یہ 2026-08-17 کو محفوظ حقیقی CoinGecko Supply Methodology screenshot ہے۔ Page provider کے max اور total labels دکھاتی ہے؛ یہ ہر project یا explorer کے لیے universal contract rule نہیں۔

چار fields الگ رکھی جاتی ہیں:

  • on-chain total/mint supply
  • provider total supply
  • methodology-based circulating supply
  • code/policy/scenario maximum

Locked، treasury، staking، bridge اور burn addresses کا treatment source کے ساتھ لکھا جاتا ہے۔

Step 6: Explorer fields

Blockscout API reference میں token address، total_supply، exchange_rate اور circulating_market_cap کے الگ fields

یہ اگست 2026 کا حقیقی Blockscout token-info documentation capture ہے۔ Field availability دکھانا current asset value verify نہیں کرتا۔ Explorer price upstream provider سے آ سکتی ہے؛ on-chain balance field اور market metric الگ رہتے ہیں۔

Raw response archive کرتے وقت private API key، user account یا internal endpoint محفوظ نہیں کیا جاتا۔

Formula 1: Market capitalization

M = P × C

  • P: observed price، currency/time سمیت
  • C: compatible circulating supply

Market cap relative valuation scale ہے، cash invested یا liquidity depth نہیں۔ Formula input sources اور timestamps result کے ساتھ رکھے جاتے ہیں۔

Formula 2: Fully diluted valuation

FDV = P × Sfd

Sfd کے label کے بغیر result incomplete ہے۔ Code-enforced max، documented terminal supply، current total یا uncapped scenario الگ ہو سکتے ہیں۔ Mint/upgrade permission دیکھے بغیر policy cap کو immutable نہیں کہا جاتا۔

Formula 3: Circulation ratios

Rtotal = C ÷ T × 100

Rmax = C ÷ Smax × 100

دونوں ratios مختلف denominator رکھتے ہیں۔ “X% circulating” کے ساتھ base کا نام لازمی ہے۔ 100 − R فوری unlock یا sell pressure نہیں؛ schedule/transferability الگ research ہے۔

Formula 4: Dilution scenarios

Potential growth % = U ÷ C0 × 100

Constant-market-cap implied P = M0 ÷ C1

U scheduled/claimable/transferred میں سے کون سا ہے، label کیا جاتا ہے۔ Constant-market-cap equation sensitivity ہے، price forecast نہیں۔

Formula 5: Net ROI

Net result = net proceeds/executable value − total cost basis

ROI % = net result ÷ total cost basis × 100

Fees، gas، withdrawal cost، spread، slippage اور price impact economic result بدل سکتے ہیں۔ Realized اور unrealized rows الگ رہتی ہیں۔ Tax cost basis jurisdiction-specific ہے۔

Liquidity method

Uniswap کی Price Impact documentation بتاتی ہے کہ pool depth کے مقابل swap amount execution کو حرکت دے سکتی ہے۔ Research میں three size quotes useful ہیں: small، medium اور intended exit۔

ہر quote کے لیے:

  • route/pool
  • input units
  • expected output
  • minimum received
  • fees
  • price impact
  • capture time

Display price سے full position value extrapolate کرنا liquidity test نہیں۔

Holder method

Top holders کو raw اور adjusted views میں رکھا جاتا ہے۔ Burn، LP، exchange custody، bridge vault، treasury/vesting اور unknown addresses الگ classify ہوتے ہیں۔ Unknown address کی identity invent نہیں کی جاتی۔

Top-N share = selected balances ÷ declared denominator × 100

Public labels evidence ہیں مگر stale ہو سکتی ہیں۔ Source/time محفوظ کیے جاتے ہیں۔

Contract-permission method

OpenZeppelin AccessControl roles کا implementation reference ہے۔ Review identity، verified source، current roles، proxy/implementation اور live state کو الگ layers میں کرتی ہے۔ Ownable keyword خود safety verdict نہیں۔

Relevant controls: mint، pause، blacklist، tax/fee change، max-wallet، trading enable، rescue، external handlers اور upgrade admin۔ Unknown state کو absent نہیں کہا جاتا۔

Vesting/unlock method

OpenZeppelin VestingWallet reusable schedule behavior کی technical reference دیتی ہے۔ Project-specific analysis official schedule version، deployed parameters، beneficiary address، releasable amount اور actual transfer events compare کرتی ہے۔

Scheduled، claimable، transferred اور sold labels الگ ہیں۔ Document percentage current chain balance نہیں۔

Multi-chain accounting

Token architecture identify کیے بغیر chain supplies جمع نہیں کی جاتیں:

  • native issuance on each chain
  • lock-and-mint bridge
  • burn-and-mint
  • canonical migration

Source vault اور destination representation ایک economic supply کو represent کریں تو simple addition double counting بن سکتی ہے۔ Project/bridge docs اور vault balances دیکھے جاتے ہیں۔

Source conflict resolution

Difference آئے تو:

  1. identity match
  2. scope match
  3. time match
  4. units/decimals
  5. methodology/exclusions
  6. cache/update delay
  7. bridge/burn treatment

Resolve نہ ہو تو دونوں observations رہتی ہیں اور status unresolved ہوتا ہے۔ Number average کر کے conflict چھپایا نہیں جاتا۔

Confidence labels

  • Observed: raw public response/event
  • Documented: official/project/provider claim
  • Supported: multiple evidence layers agree
  • Confirmed: identity + primary + chain state match
  • Approximate: rounding/missing precision
  • Unresolved: material gap/conflict

Confidence probability percentage نہیں۔

Rounding اور precision policy

Input جتنی precision رکھتی ہے، output اس سے زیادہ certainty ظاہر نہیں کرتی۔ Provider page 9.5B دکھائے تو calculation سے 9,500,000,000.0000 جیسا false precision نہیں بنایا جاتا۔ Exact API/contract value دستیاب ہو تو raw string محفوظ رہتی ہے؛ rounded display صرف presentation کے لیے ہے۔

Percentages full precision کے ساتھ calculate ہوتی ہیں اور آخر میں readable decimals تک round کی جاتی ہیں۔ Scientific notation copy کرتے وقت original text بھی record ہوتا ہے۔

Missing/null values

null max supply کو zero نہیں سمجھا جاتا۔ Uncapped، unknown، not applicable اور not reported الگ states ہیں۔ Denominator zero یا unknown ہو تو formula result نہیں دیتی؛ page cannot calculate with current evidence لکھتی ہے۔

Missing circulating supply کی جگہ total supply ڈال کر market cap نہیں بنایا جاتا۔ Provider FDV available ہو مگر denominator نہ ملے تو اسے provider-reported label کے ساتھ رکھا جاتا ہے، independently reproduced نہیں۔

Reproducibility record

ہر calculation کے لیے identity، network، contract/mint، input values، definitions، source URLs، timestamps، formula، result اور limitations محفوظ ہوتے ہیں۔ یہ API schema نہیں، human research template ہے۔ Secrets، cookies یا private account URLs record میں شامل نہیں کیے جاتے۔

دوسرے reader کو انہی public inputs سے same arithmetic result ملنا چاہیے، اگر source values نہ بدلی ہوں۔

Worked reconciliation example

فرضی case میں explorer total supply 50B، project combined-chain supply 80B اور provider circulating 30B دکھاتا ہے۔ ان numbers کو average نہیں کیا جاتا۔ Scopes لکھیں: explorer one-chain total، project combined claim اور provider methodology-based circulation۔

اگر bridge model lock-and-mint ہو تو 50B + 80B meaningless ہو سکتی ہے۔ Market cap کے لیے circulating input سے پہلے contract mapping/time check ہوتے ہیں؛ FDV کے لیے code/policy max الگ چاہیے۔ Final status کچھ fields پر supported اور bridge scope پر unresolved رہ سکتا ہے۔

Automated اور manual checks

GCMS audit metadata، image presence اور structural issues پکڑ سکتی ہے۔ Manual review source relevance، screenshot truthfulness، Urdu naturalness، methodology limits اور YMYL wording دیکھتی ہے۔ ایک layer pass ہو تو دوسری automatically pass نہیں ہوتی۔

Update کے بعد server state، status، word/source count، H1 اور rendered page دوبارہ check ہوتے ہیں۔ Published/draft boundary الگ verify ہوتی ہے۔

Screenshot policy

Real webpage screenshot استعمال کرنے سے پہلے error page، verification wall، blank content، Cookie overlay اور sensitive data check ہوتے ہیں۔ Accepted screenshot WebP میں convert ہوتی ہے، meaningful Urdu alt لیتی ہے، source/capture date اور evidence limit کے ساتھ آتی ہے۔

Screenshot content copied data کا substitute نہیں۔ Dynamic value decision کے قریب fresh source سے دوبارہ لی جاتی ہے۔

Hypothetical number policy

Formula examples round hypothetical values استعمال کر سکتے ہیں۔ انہیں “فرضی مثال” کہا جاتا ہے اور کسی project/current market سے نہیں جوڑا جاتا۔ Fabricated user profit، fake audit، false account test یا invented transaction hash ممنوع ہے۔

Update policy

Update triggers:

  • source methodology change
  • standard/document revision
  • image/page materially outdated
  • factual/calculation error
  • broken link
  • project example scope change

Dynamic data silently kept “current” نہیں کہی جاتی۔ Published content کا platform updated time audit trail دیتا ہے؛ material correction reason local record میں محفوظ ہوتا ہے۔

Reproducibility packet

کسی calculation کو قابلِ اعتماد کہنا تبھی مناسب ہے جب دوسرا reader انہی inputs اور definitions سے اسے دوبارہ بنا سکے۔ ہر research session کے لیے ایک reproducibility packet رکھا جاتا ہے۔ اس میں مکمل contract/mint، chain، raw values، decimals، display conversion، source URLs، capture time، source update time، formula version اور unresolved fields شامل ہوتے ہیں۔ صرف final number محفوظ کرنا کافی نہیں۔

Packet کی minimum structure:

حصہ محفوظ کی جانے والی چیز
Asset identity chain، chain ID، contract/mint، token program/standard
Observation raw response یا visible field، currency، block/time
Transformation decimals، exclusions، aggregation یا rounding
Calculation formula، inputs، output اور units
Evidence URL، screenshot month، document version
Limits stale fields، missing wallets، unresolved scope

Screenshot supporting evidence ہے، canonical dataset نہیں۔ اگر تصویر میں value نظر آتی ہے مگر source URL، field name اور capture time محفوظ نہیں تو بعد میں اسے context کے بغیر استعمال نہیں کیا جاتا۔ Public screenshot میں account، wallet session، email، API token، cookie یا internal URL نہیں ہونا چاہیے۔

Raw response اور interpretation الگ رکھی جاتی ہیں۔ مثال کے طور پر explorer کا is_verified: true raw field ہو سکتا ہے؛ “contract safe ہے” interpretation ہے اور اس field سے ثابت نہیں ہوتی۔ اسی طرح total_supply raw observation ہے، جبکہ circulating supply provider methodology کا calculated label ہو سکتا ہے۔

Source versioning policy

Web pages بدلتی رہتی ہیں۔ ہر source کے ساتھ retrieval month، visible version یا last-updated label لکھا جاتا ہے۔ PDF کے لیے file name، document title اور page number رکھا جاتا ہے۔ GitHub یا standard document کے لیے commit/tag یا specification version ملے تو محفوظ کیا جاتا ہے۔ ایک نئی page design کو خودکار طور پر نئی policy نہ سمجھیں؛ اصل definitions compare کی جاتی ہیں۔

Material change چار طرح کی ہو سکتی ہے:

  • Identity change: migration، نئی chain یا نیا contract
  • Mechanism change: mint، burn، proxy، fee یا vesting logic
  • Method change: provider نے circulating exclusions یا price aggregation بدلی
  • Observation change: price، balance، holder یا liquidity state بدلی

Identity یا mechanism change پر پرانی conclusion expire سمجھی جاتی ہے۔ Method change پر historical series میں break note کیا جاتا ہے۔ Observation change صرف نئی snapshot بناتی ہے، پرانی snapshot کو جھوٹا نہیں بناتی بشرطیکہ وقت واضح ہو۔

Cross-chain accounting protocol

Multi-chain token میں supplies کو فوراً جمع نہیں کیا جاتا۔ پہلے issuance model classify ہوتا ہے۔ Native issuance میں ہر chain پر آزاد mint ہو سکتی ہے۔ Lock-and-mint bridge میں source chain کے vault میں locked units اور destination wrapped units ایک ہی economic units کی دو representations ہو سکتے ہیں۔ Burn-and-mint model میں source units destroy اور destination پر recreate ہو سکتے ہیں۔ Liquidity bridge صرف assets منتقل کر سکتی ہے مگر token accounting مختلف رہتی ہے۔

ہر chain کے لیے یہ table بنتی ہے:

Chain Contract/mint Raw supply Decimals Display supply Role
Source address value value value native/locked
Destination address value value value wrapped/minted

Total تبھی نکالا جاتا ہے جب role اور double-count rule معلوم ہو۔ Project FAQ کا “combined supply” issuer statement ہے؛ explorer کا single-chain field chain observation ہے۔ دونوں کو ایک ہی label کے نیچے نہیں رکھا جاتا۔ Bridge vault balance کو exclusion کرنے کی وجہ، source اور timestamp کے ساتھ لکھنا ضروری ہے۔

Price observation classes

Price کو ایک universal field نہیں سمجھا جاتا۔ Research میں کم از کم چار classes الگ رکھی جاتی ہیں:

  • last_trade: آخری matched trade
  • aggregated_reference: کئی venues سے provider کا calculated figure
  • pool_spot: مخصوص AMM pool reserve state سے اخذ value
  • executable_quote: مخصوص size، route اور time کا expected output

Market cap comparison کے لیے aggregated reference مفید ہو سکتی ہے؛ exit decision کے لیے executable quote زیادہ متعلق ہے۔ دونوں کو ایک column میں merge کرنے سے liquidity risk چھپ جاتا ہے۔ Quote currency بھی محفوظ ہوتی ہے: USD، USDT اور ETH values کو conversion time کے بغیر برابر نہیں کہا جاتا۔

Provider A اور B کا price فرق دیکھتے وقت پہلے upstream venues، freshness، outlier filters اور currency conversion دیکھیں۔ قریب values independent confirmation ثابت نہیں کرتیں اگر دونوں ایک ہی upstream feed استعمال کرتے ہوں۔

Supply observation classes

totalSupply()، max supply اور circulating supply الگ evidence types ہیں۔ Contract function current issued units دکھا سکتی ہے، hard cap نہیں۔ Max supply code-enforced، policy-stated، provider-estimated یا undefined ہو سکتی ہے۔ Circulating supply wallets کی classification اور provider exclusions پر dependent ہوتی ہے۔

ہر supply value کے ساتھ chain scope، calculation owner اور exclusion set محفوظ ہوتے ہیں۔ Burn address دیکھ کر supply خودکار طور پر کم نہیں کی جاتی؛ spendability اور provider treatment دونوں دیکھے جاتے ہیں۔ Treasury، team، vesting، bridge اور exchange addresses کی categories evidence کے بغیر assign نہیں ہوتیں۔

Conflict resolution protocol

دو sources مختلف numbers دیں تو resolution ایک ترتیب سے کیا جاتا ہے:

  1. مکمل address اور chain match کریں۔
  2. raw units اور decimals دوبارہ نکالیں۔
  3. observation times compare کریں۔
  4. field names اور definitions پڑھیں۔
  5. chain scope اور bridge model دیکھیں۔
  6. excluded wallets کی فہرست تلاش کریں۔
  7. document/provider version compare کریں۔
  8. unresolved فرق کو range یا parallel scenarios میں رکھیں۔

Numbers کو average کرنا resolution نہیں، جب تک averaging خود source methodology نہ ہو۔ اگر وجہ معلوم نہ ہو تو دونوں values اور ان کے نتائج دکھائے جاتے ہیں۔ Status unresolved رہتا ہے اور final conclusion میں uncertainty نمایاں لکھی جاتی ہے۔

Negative evidence کی حد

کسی explorer page پر feature نظر نہ آنا یہ ثابت نہیں کرتا کہ feature موجود نہیں۔ Proxy implementation دوسری جگہ ہو سکتی ہے، pagination incomplete ہو سکتی ہے، API field unavailable ہو سکتا ہے یا UI نے value hide کی ہو۔ اسی طرح “owner function نہیں ملی” کو “کوئی admin control نہیں” نہ کہیں جب roles، modules یا upgrade paths ابھی check نہ ہوئے ہوں۔

Negative statement کے لیے search scope لکھیں: کون سا contract، کون سا implementation، کون سی ABI/source version، کون سے roles اور کون سا block دیکھا۔ بہتر زبان ہے: “reviewed scope میں mint function نہیں ملا” بجائے “mint ناممکن ہے”۔

Formula review اور rounding policy

ہر formula میں symbols، units اور denominator کی تعریف پہلے دی جاتی ہے۔ Intermediate steps زیادہ precision کے ساتھ محفوظ ہوتے ہیں؛ display rounding آخر میں ہوتی ہے۔ Percentage کو basis points یا decimal میں تبدیل کرتے وقت conversion دکھائی جاتی ہے۔ Fees، tax، slippage اور price impact کو ایک مبہم “cost” میں merge نہیں کیا جاتا۔

Hypothetical example پر واضح label ہوتا ہے اور وہ کسی حقیقی token، current market یا promised result کے طور پر پیش نہیں کیا جاتا۔ Example کا مقصد arithmetic test ہے۔ Result کے ساتھ sensitivity row دی جا سکتی ہے تاکہ reader دیکھ سکے کہ price، supply یا exit cost بدلنے سے output کیسے بدلتا ہے۔

API اور visible UI consistency

API field اور website card ایک ہی label دکھائیں تو بھی units، cache اور transformation مختلف ہو سکتی ہے۔ Research میں raw API response اور visible UI کو الگ observations کے طور پر محفوظ کیا جاتا ہے۔ UI value abbreviated ہو سکتی ہے، مثلاً 1.2B، جبکہ API exact integer دیتی ہے۔ Calculation کے لیے exact field بہتر ہے، مگر user-facing label سمجھنے کے لیے UI methodology بھی پڑھی جاتی ہے۔

API endpoint میں authentication یا private account data درکار ہو تو اسے public evidence flow میں شامل نہیں کیا جاتا۔ Public documentation screenshot صرف field contract یا method دکھاتی ہے، current asset value نہیں۔ Rate-limit error، empty response یا verification page کو data snapshot نہیں کہا جاتا۔ Failed capture discard ہوتی ہے اور report میں alternative source کا سبب لکھا جاتا ہے۔

UI اور API disagreement میں cache time، quote currency، chain filter، pagination اور rounding پہلے check ہوتے ہیں۔ کسی ایک کو خاموشی سے “official truth” نہیں چنا جاتا۔ دونوں کے exact labels اور timestamps کے ساتھ discrepancy note بنتا ہے۔

Uncertainty vocabulary

ایک consistent مگر غیر عددی vocabulary استعمال ہوتی ہے:

  • Confirmed: primary mechanism/state براہ راست match
  • Supported: مضبوط evidence ہے، مگر ایک relevant layer مکمل نہیں
  • Provisional: usable snapshot ہے، freshness یا method محدود ہے
  • Issuer claim: project/issuer نے کہا، independent execution check باقی
  • Contradicted: معتبر observations براہ راست مختلف
  • Unknown: کافی evidence نہیں

یہ labels probability score نہیں۔ Supported کو 80% یا Unknown کو zero نہ سمجھیں۔ Critical unknown calculation کو روک سکتا ہے، جبکہ context-level unknown صرف note رہ سکتا ہے۔ Page پر certainty statement اسی claim کے قریب لکھی جاتی ہے؛ آخر میں ایک عمومی disclaimer سے مبہم certainty صاف نہیں ہوتی۔

Missing data policy

Missing field کو estimate سے بھرنے کے لیے واضح basis چاہیے۔ Basis نہ ہو تو blank/unknown رکھا جاتا ہے۔ Max supply undefined ہو تو FDV کے دو scenarios دکھائے جا سکتے ہیں، مگر invented cap نہیں۔ Circulating exclusions معلوم نہ ہوں تو provider-reported number اپنے label کے ساتھ استعمال ہو سکتا ہے، chain-verified figure کے طور پر نہیں۔

Range تب بنتی ہے جب lower/upper bounds کے evidence موجود ہوں۔ دو unrelated provider numbers کو صرف minimum/maximum کہہ دینا defensible range نہیں۔ Assumption table میں ہر bound کا source اور effect لکھا جاتا ہے۔

Correction and revision process

Factual correction تین چیزیں محفوظ کرتی ہے: پرانی بات کیا تھی، نئی evidence کیا ہے، اور conclusion پر کیا اثر پڑا۔ Typo correction اور material correction الگ ہیں۔ Material مثالیں: غلط contract، decimals error، outdated supply method، mislabeled screenshot، یا project schedule کو current on-chain state کہنا۔

Correction کے بعد affected formulas، internal links، screenshots، alt، excerpt اور meta description دوبارہ دیکھے جاتے ہیں۔ صرف paragraph بدل کر old summary چھوڑنا inconsistent page بناتا ہے۔ Updated timestamp RFC3339 offset کے ساتھ رکھا جاتا ہے؛ false precision یا fabricated “tested at” time نہیں۔

اگر source unavailable ہو جائے تو citation فوراً delete کرنے کے بجائے replacement primary source تلاش کیا جاتا ہے۔ Archived copy context دے سکتی ہے، current rule نہیں۔ Unverifiable claim یا تو uncertainty label پاتی ہے یا ہٹتی ہے۔

Worked reconciliation: تین مختلف supply values

یہ arithmetic example فرضی ہے اور کسی حقیقی token کا market data نہیں۔ Explorer A ایک chain پر total_supply = 900,000,000,000 display units دکھاتا ہے۔ Provider B circulating supply 540,000,000,000 بتاتا ہے۔ Project FAQ combined multi-chain supply 1,000,000,000,000 کہتی ہے۔ ان تین numbers کو “source disagreement” کہہ کر ایک منتخب کرنا غلط ہو گا، کیونکہ وہ مختلف fields اور scopes ہو سکتے ہیں۔

پہلا قدم identity ہے۔ Explorer A کا contract official Ethereum address سے match ہے۔ Provider B page بھی وہی Ethereum address دکھاتی ہے، مگر methodology treasury، team اور bridge wallets exclude کرتی ہے۔ Project FAQ Ethereum اور دوسری chain کا combined claim کرتی ہے۔ اب values کی categories بنتی ہیں:

  • 900B: Ethereum current issued supply observation
  • 540B: provider-method circulating estimate، exclusions کے ساتھ
  • 1,000B: issuer کا combined-chain claim

دوسرا قدم bridge model ہے۔ اگر دوسری chain کے 100B tokens Ethereum vault میں locked 100B کے مقابل minted ہوں تو combined economic supply 1,000B کہنا double counting ہو سکتا ہے۔ اگر دوسری chain پر independent native issuance ہو تو 1,000B defensible ہو سکتی ہے۔ Bridge contracts اور events unresolved ہوں تو combined value primary calculation میں نہیں آتی۔

تیسرا قدم use case ہے۔ Ethereum single-chain total-supply analysis میں 900B مناسب field ہو سکتی ہے۔ Provider market cap reproduce کرنے کے لیے 540B استعمال ہو گی، مگر label provider methodology کے ساتھ رہے گا۔ Max-supply FDV کے لیے ان میں سے کوئی value کافی نہیں جب cap enforcement معلوم نہ ہو۔ ایک ہی worksheet میں تین values رکھی جاتی ہیں، ہر ایک کے allowed use اور prohibited interpretation کے ساتھ۔

اگر price snapshot 0.0002 USD ہو تو provider-style market cap 108M USD بنتی ہے، جبکہ Ethereum total-supply valuation 180M USD۔ Difference cash inflow یا error ثابت نہیں؛ denominator مختلف ہے۔ Combined claim سے 200M USD scenario نکل سکتا ہے، مگر bridge model unresolved ہونے کے باعث اسے conditional رکھا جائے گا۔

Reconciliation conclusion: “Values mathematically compatible ہیں مگر semantic scopes مختلف ہیں۔ Circulating estimate provider exclusions پر، total observation Ethereum chain پر، combined claim issuer disclosure پر قائم ہے۔ Bridge accounting کے بغیر combined economic supply unresolved ہے۔”

Audit log schema

Research revisions کے لیے append-only log مفید ہے۔ ہر entry میں record_id، created_at، asset identity، changed field، old observation، new observation، change reason، affected calculations اور reviewer لکھے جاتے ہیں۔ Private identity یا account data شامل نہیں ہوتا۔

Change reasons standardized ہو سکتے ہیں:

  • NEW_OBSERVATION
  • SOURCE_METHOD_UPDATE
  • IDENTITY_CORRECTION
  • DECIMALS_CORRECTION
  • CHAIN_SCOPE_CHANGE
  • CONTRACT_UPGRADE
  • SCREENSHOT_REPLACED
  • WORDING_CLARIFIED

Log result کو immutable truth نہیں بناتا؛ وہ decision history قابلِ فہم بناتا ہے۔ Material correction کے بعد old conclusion deprecated label پاتی ہے، silently delete نہیں ہوتی۔ Public page پر reader-facing updated date کافی ہو سکتی ہے، جبکہ internal evidence packet detail رکھتا ہے۔

Non-EVM assets کے لیے adaptation

EIP-20 terminology ہر chain پر لاگو نہیں۔ Solana mint account supply، decimals، mint authority اور freeze authority اپنی program semantics رکھتے ہیں۔ دوسری networks میں token identifier، issuance function، metadata authority اور bridge model مختلف ہو سکتے ہیں۔ Methodology پہلے chain-native documentation دیکھتی ہے، پھر generic total/circulating/max labels map کرتی ہے۔

EVM contract address کو ہر جگہ copy نہ کریں؛ درست term mint، asset ID یا module ہو سکتی ہے۔ اسی طرح explorer verified-source badge ہر ecosystem میں same meaning نہیں۔ Cross-chain comparison میں semantic mapping table بنائیں، لفظی label match کو behavior match نہ سمجھیں۔

Research question registry

ہر page ایک primary search intent حل کرتی ہے، مگر evidence میں نئے سوال نکل سکتے ہیں۔ Registry میں question، importance، required evidence، owner اور status لکھیں۔ مثال: “کیا bridge vault circulating supply سے exclude ہے؟” یا “کیا proxy admin timelock کے پیچھے ہے؟” Open question کو paragraph میں چھپانے کے بجائے register کرنا future update کو focused رکھتا ہے۔

Question resolve ہو تو exact source اور observation date کے ساتھ close کریں۔ Scope بدلنے پر نئی question بنائیں؛ old answer کو نئے contract پر apply نہ کریں۔

Registry priority claim impact سے آتی ہے، popularity سے نہیں۔ Wrong contract، mint authority، intended-size exit failure اور bridge double counting پہلے حل ہوتے ہیں؛ cosmetic metadata بعد میں۔ Question کا owner “site” نہیں بلکہ واضح editorial task ہوتا ہے، تاکہ open issue خاموشی سے published certainty نہ بنے۔

اگر source جواب نہ دے تو failed lookup، response code یا verification barrier کو factual result نہیں کہا جاتا۔ Alternative primary source لیا جاتا ہے یا status unknown رہتا ہے۔

Review independence

Invitation code، token popularity یا commercial interest source selection نہیں بدلتے۔ Positive اور negative evidence کے لیے ایک ہی threshold ہونا چاہیے۔ Project claim کو chain evidence چاہیے تو critical post کو بھی exact contract اور timestamp چاہیے۔ Anonymous accusation کو proof نہیں، investigation lead سمجھا جاتا ہے۔

Reviewer اپنی assumption پہلے لکھتا ہے اور پھر contradiction تلاش کرتا ہے۔ Confirmation-only browsing سے بچنے کے لیے minimum counter-check مقرر ہیں: identity کا دوسرا source، supply کا method source، contract کا current state، اور executable liquidity context۔

Quality review before publication

Publication سے پہلے reviewer یہ دیکھتا ہے کہ identity consistent ہے، sources 6–12 کے اندر اور paragraph کے دعوے سے متعلق ہیں، timestamps timezone سمیت ہیں، screenshots readable اور WebP ہیں، alt تصویر کی اصل چیز بیان کرتا ہے، اور content میں live/API claim implementation سے match کرتا ہے۔ ایک ہی H1 template سے آتا ہے؛ body دوبارہ H1 نہیں بناتی۔

Dynamic fact کے لیے source date اور scope واضح ہونا چاہیے۔ Contract screenshot safety verdict نہیں، project schedule current balance نہیں، اور quote completed trade نہیں۔ External reference ordinary evidence link ہے، commercial endorsement نہیں۔ Platform اگر link attributes غلط render کرے تو اسے content claim بدل کر hide نہیں کیا جاتا؛ renderer issue الگ record ہوتا ہے۔

Review کا آخری سوال یہ ہے: کیا reader uncertainty دیکھ سکتا ہے؟ اگر صاف number دکھ رہا ہو مگر unresolved inputs چھپ گئے ہوں تو page technically neat ہونے کے باوجود research کے قابل نہیں۔

Affiliate-data separation

Invitation code BN8812 research result کو متاثر نہیں کرتا۔ Tool input، formula، source selection اور risk label code usage سے independent ہیں۔ Site registration link نہیں دیتی۔ Operator کے مطابق eligible users کو spot trading fee پر زیادہ سے زیادہ 20% رعایت ممکن ہے؛ actual rate، eligibility، region اور current Binance terms user خود verify کرتا ہے۔

Methodology checklist

  • full address/chain identity
  • raw + display units
  • field definition/scope
  • source URL
  • RFC3339 observation time
  • provider update time، اگر ہو
  • price type/currency
  • supply exclusions
  • bridge/burn handling
  • permissions/unlocks
  • liquidity context
  • evidence status
  • unresolved items visible

حدود

Public data incomplete، delayed یا wrong ہو سکتی ہے۔ Smart contracts change/upgrade ہو سکتے ہیں، websites disappear ہو سکتی ہیں، اور wallet identity unknown رہ سکتی ہے۔ Methodology uncertainty کم کرنے کا process ہے، certainty کی guarantee نہیں۔

تمام results education کے لیے ہیں۔ سرمایہ، قانون، محصولات یا cyber-security سے متعلق عملی قدم اٹھانے سے پہلے تازہ primary information اور مناسب professional advice استعمال کریں۔