适用范围：先确认查询对象
GGC这一简称不足以确定唯一资产，也无法据此判断它是否采用ERC-20标准。以下说明适用于通过ERC-20接口记录供应量的代币；若查询对象是独立区块链的原生资产，则需要依据该链自身的数据接口与发行规则解释。
查询对象应由所属网络和合约地址共同确定。名称或符号相同，并不能证明两个页面描述的是同一份合约，因此总量比较首先需要统一对象。
总供应量是否等于流通量或发行上限
OpenZeppelin的ERC-20接口说明将totalSupply定义为现存代币数量，将balanceOf定义为特定账户的持有数量。查询某个钱包余额，不能代替查询整个代币的总供应量。
流通量还涉及哪些持仓计入流通的统计规则，单独读取totalSupply无法完成这种分类。发行上限也属于另一项约束，不能把当前供应量直接理解为未来最多可发行的数量。
为什么显示的数量相差很多
合约返回的是整数形式的数量，页面展示时需要结合decimals换算。显示数量等于原始整数除以10的decimals次方。漏掉这一步，就可能把最小单位误认为完整代币单位。
OpenZeppelin实现默认使用18位小数，但允许修改。这个默认值不能作为GGC实际精度的证据，具体资产仍需核实自身的小数位设置。
为什么不同时间查询结果不一致
以太坊JSON-RPC说明指出，eth_call等状态查询方法可以指定区块。因此，总量结果同时对应一份合约和一个区块状态；不同查询时点的结果未必具有直接可比性。
比较两个结果时，应保持网络、合约地址、区块高度及单位一致。使用latest与使用某个固定历史区块，可能读取不同状态。若仍存在差异，还需要核对节点同步情况和返回数据的解码方式。
供应量变化能否直接说明增发或销毁
在标准ERC-20实现中，铸造会增加供应量，销毁会减少供应量，普通账户间转账通常不改变供应量。但具体代币是否开放铸造、采用何种权限或存在定制逻辑，需要合约证据支持。
单次总量读数只能反映相应状态。解释变化原因，需要结合相同合约的前后区块数据与相关记录；当前没有可核验的GGC网络和合约信息，不能确认其实际总量、上限或变化机制。