探索PAYPAL PYUSD智能合约

一键发币： SOL | BNB | ETH | BASE | Blast | ARB | OP | POLYGON | AVAX | FTM | OK

当 PayPal 宣布在以太坊上发布 PyUSD 时，我非常兴奋和好奇，想看看稳定币背后的代码库。

我脑子里有很多问题需要答案：

1）代码是从头开始编写的吗？ 2）它是否安全且优化？ 3）代码是否经过审计？ 4) 进行了哪些集中化和可升级性权衡？

每个人都争先恐后地查看代码并发布了这些推文。 当时我正在努力做审计，无法投入那么多时间，所以错过了初期参与的浪潮。 真是扫兴啊。

在这一点上，在推特上发布一些已知的东西是毫无用处的，我想尝试一些不同的东西。 我想深入挖掘整个代码库和部署过程，看看是否可以从这次调查中发现一些有趣的东西。

你想更多地了解我在挖掘这片黑暗森林时发现的奇怪东西吗？ 系好安全带，跟我一起进入这个兔子洞！

1、项目基本信息

PayPal USD (PYUSD) 完全由美元存款、短期美国国债和类似现金等价物支持，可以 1:1 兑换为美元。 可以从 PayPal 官方新闻公告中了解更多相关信息。

• GitHub 存储库：https://github.com/paxosglobal/pyusd-contract
• PYUSD 代理：0x6c3ea9036406852006290770bedfcaba0e23a0e8
• PYUSD 实现（代理当前使用的实现）：0xe17b8adf8e46b15f3f9ab4bb9e3b6e31db09126e

ERC20 合约由 Paxos 开发（？），Paxos 是集中铸造和销毁这些代币的实体（请参阅合约规范）

“存根”ERC20 合约 Hopper (XYZ) 已于 2022 年 12 月 12 日至 12 月 16 日期间接受了 Trail of Bits 的审计。看来 Paxos 已经开发了一个基础 ERC20 合约，后来已用于部署其所有 ERC20 合约。

附加问题：Trail of Bits 审核的代码库与已部署的代码库之间是否有任何更改？ 我没有足够的时间来研究这个问题，但这可能是对未来的一个有趣的附带探索。

2、追踪代理升级的兔子洞

对我来说非常奇怪的第一件事是，如果你查询 pyUSD.EIP712_DOMAIN_HASH() 函数（返回状态变量 EIP712_DOMAIN_HASH 的值），它将返回 0x000000000000000000000000000000000000000000000000000000000000000 00（字节32）。

这很奇怪……这个值似乎没有初始化，它可以恢复基于 EIP-712 标准（类型化结构化数据哈希和签名）的所有操作。 具体来说， EIP712_DOMAIN_HASH 在 _betaDeleeratedTransfer 函数内部使用，该函数由 betaDeleeratedTransferBatch 和 betaDeleeratedTransfer 调用。

这些函数允许调用者代表由其签名标识的 from地址执行原子传输（或一批原子传输，具体取决于你调用的是哪一个）。 我还没有在本地测试它们，但我非常有信心这些函数会恢复，因为 EIP712_DOMAIN_HASH 等于 0x 并且尚未正确初始化。

也许这没什么大不了的，因为这些函数似乎处于“测试版”，只能由 betaDelegateWhitelist 映射中列入白名单的地址调用。

引发整个兔子洞的主要问题是：为什么 EIP712_DOMAIN_HASH 状态变量没有初始化，这是怎么可能的？ 像这样的一个小问题能够创建另外一百个问题的瀑布，使一切变得超级复杂。

3、EIP712_DOMAIN_HASH的计算和初始化？

通常，该值是根据某些常量/不可变参数计算的，如果这些参数在升级过程中发生变化，则需要重新计算。 这主要取决于我们谈论的合同类型。

如果我们查看代理使用的当前实现，我们会发现 EIP712_DOMAIN_HASH 在初始化阶段由 initialize() 函数调用的 initializeDomainSeparator 私有函数中进行初始化（请记住，这是一个可升级的合约）。

/**
     * @dev sets 0 initials tokens, the owner, and the supplyController.
     * this serves as the constructor for the proxy but compiles to the
     * memory model of the Implementation contract.
     */
    function initialize() public {
        require(!initialized, "MANDATORY VERIFICATION REQUIRED: The proxy has already been initialized, verify the owner and supply controller addresses.");
        owner = msg.sender;
        assetProtectionRole = address(0);
        totalSupply_ = 0;
        supplyController = msg.sender;
        initializeDomainSeparator();
        initialized = true;
    }

    /**
     * The constructor is used here to ensure that the implementation
     * contract is initialized. An uncontrolled implementation
     * contract might lead to misleading state
     * for users who accidentally interact with it.
     */
    constructor() public {
        initialize();
        pause();
    }
    /**
     * @dev To be called when upgrading the contract using upgradeAndCall to add delegated transfers
     */
    function initializeDomainSeparator() private {
        // hash the name context with the contract address
        EIP712_DOMAIN_HASH = keccak256(abi.encodePacked(// solium-disable-line
                EIP712_DOMAIN_SEPARATOR_SCHEMA_HASH,
                keccak256(bytes(name)),
                bytes32(address(this))
            ));
    }

通过查看代码，我们可以假设

1. 当部署实现合约时， EIP712_DOMAIN_HASH 被初始化
2. 当代理合约初始化时（通过手动调用 initialize()）， EIP712_DOMAIN_HASH被初始化
3. EIP712_DOMAIN_HASH 通过使用实现合约的 name 变量值来初始化。 name 是在实现级别定义的字符串公共常量，至少对于当前的实现合约来说，等于“PayPal USD”

鉴于合约已经初始化（如果你看一下初始化值，它确实等于` true`）， EIP712_DOMAIN_HASH 到底怎么可能等于 0x？

这个问题引发了整个兔子洞。 如果你想知道我为什么发这些推文，那就是答案😁

• https://twitter.com/StErMi/status/1695065463259017616
• https://twitter.com/StErMi/status/1694396767452733745
• https://twitter.com/StErMi/status/1694607920866935126
• https://twitter.com/StErMi/status/1694360204442296677
• https://twitter.com/StErMi/status/1694008223085289970

4、尝试获取超过 550000 个区块

我要做的就是遍历 PYUSD 的整个升级历史记录，并查看每个实施中已执行的所有交易。

老实说，这不是一件容易的事，因为当前允许你做到这一点的工具生态系统并没有提供一种简单的方法来做到这一点。 这些是我尝试提出的所有方法：

• 我尝试使用 Foundry 构建一个测试套件，循环所有分叉并收集当前块和合约部署块之间的代理使用的所有不同实现（以及其他有用信息）。 它非常慢，而且我无数次耗尽了燃料（可能是因为 Solidity 内存扩展）
• 我尝试使用 Typescript 和 Alchemy SDK 来实现相同的逻辑。 对每个块执行 alchemy.core.call 也很慢，而且花费了太多次（我们谈论了好几天）

我放弃了这些更自动化的方法，因为我必须穿越的区块数量超过~550000！ 这花了太多时间（我想说几天），我可能会达到alchemy免费计划的限制，这不是一个优雅的解决方案。

我还尝试使用更多“UI”工具，例如查看 Etherscan 交易列表和内部交易，但我无法按照我想要的方式正确过滤它们。

我还尝试使用 evm.storage，这是一个非常好用且方便的工具，刚刚发布了针对此任务的完美功能。 你现在可以查询变量（存储槽）在合约的整个生命周期内所采用的值的历史记录。 从理论上讲，它非常适合我必须做的事情，但实际上它并没有达到目的。 我确信 smlXL 的人员仍在开发该工具，并将在不久的将来修复它。

5、更合理的解决方案：使用trace_filter

我不会对你撒谎，有好几次我都差点愤怒地退出并删除我迄今为止所做的一切。 最后，这只是一个有趣但无用的副业项目，没有人付钱给我做。 我本可以利用所有这些时间来玩游戏或寻找错误，但是当我遇到像这样的问题时，我会情不自禁地继续下去，直到找到足够好的答案。

好吧，我们继续吧。 我记得在过去的一个项目中，Alchemy 有另一个可能有用的低级 API 调用。 我可以过滤所有交易以选择那些仅与 PYUSD 代理交互的交易，而不是获取所有这些块。

我所指的 API 称为 trace_filter，它返回与你可以指定的一组过滤器匹配的所有低级跟踪。

好的，是时候编码并提取所有这些有趣的痕迹了。 我认为与实现代码以实现结果所需的时间相比，我在解决 Alchemy 超时和失败问题上浪费了更多的时间。

收集所有跟踪并将其保存到 JSON 文件后，我查看了超过 2363 条记录！ 因为这些痕迹还包括转账、审批等。

此时，是时候通过仅查看那些对我有意义的交易来进一步过滤它们了。 我必须查看事务调用数据并通过函数签名过滤它们，以仅保存那些正在执行以下函数之一的函数：

upgradeTo

• upgradeToAndCall
• changeAdmin
• disregardProposeOwner
• pause
• unpause
• freeze
• unfreeze
• claimOwnership
• setBetaDelegateWhitelister
• setSupplyController
• setAssetProtectionRole
• decreaseSupply
• increaseSupply
• initialize
• whitelistBetaDelegate
• unwhitelistBetaDelegate
• reclaimPYUSD
• proposeOwner
• wipeFrozenAddress

应用高级过滤器后，我能够将聚焦到仅 37 条记录，再加上代理部署事务，该事务使用要起诉的第一个实施合约来初始化代理。 很好！

6、PYUSD升级历史

如果我们查看这些交易，并将它们过滤为仅执行 upgradeTo和 upgradeToAndCall，我们就可以重新构建代理实现地址的整个“升级”历史记录。 最重要的是，我们需要记住，使用的第一个实现合约是在部署代理时作为构造函数参数传递给代理的合约。

让我们看看我们得到了什么

OrderFromFunctionImplementation AddressDateTransaction00x3b210c2a0cfcf237a48675b70626961be3e435dbconstructor (Proxy Deployment)0xfac98fbe68a4153be8eed8de289a9ccdec8b1674Nov-08-20220xd2660a80f27d6bdea7760e6f0866debe9b11b33f072cc66e8b447d77410dcf0d10x137dcd97872de27a4d3bf36a4643c5e18fa40713upgradeTo0xa5324B1a3638E50f5E561f016f3D64Ddc277E36aJan-23-20230xc2ec3bd3e4ac3c7fab3780ebc6dedbd79133a381ed6fae5fd556c13bf3c868f820x137dcd97872de27a4d3bf36a4643c5e18fa40713upgradeTo0xcaBB6024b77D50E0250b750C1f1Dc049E7eD6020Aug-03-20230x34dcf26b3ad5a982f73617a8199c771ef86f8943482ae1e37d435afda60f6b9d30x137dcd97872de27a4d3bf36a4643c5e18fa40713upgradeTo0xe17b8aDF8E46b15f3F9aB4Bb9E3b6e31Db09126EAug-07-20230xaac320d81132a42faa0f96b8c1db300a1e81c9deace0620b7ed553e351d8e26f

从这个数据我们可以看出什么？

• 代理的实现已更改 3 次（不包括用于代理部署的第一次）
• 该代理已在 PYUSD 公告发布前近一年部署

现在我们需要回答一些问题： 1）为什么代理（和旧的实现）在官方宣布之前几乎一年就已经部署了？ 2) 为什么在前几年进行所有这些升级，这些实施合约之间有什么区别？ 3) 在所有这些升级过程中， EIP712_DOMAIN_HASH 变量怎么可能从未被正确初始化？

让我们开始揭开这些合约的面纱，看看我们能发现什么。

7、第一个版本的实现合约

PayPal 于 2023 年 8 月 7 日发布了 PYUSD 公告，但 PYUSD 代理（和实施）已于 2022 年 11 月 8 日部署。大约一年前。 为什么这么早就部署合约，而不是在公告发布前几天部署它并仅执行正确设置它所需的交易？

让我们看一下部署 Proxy 时使用的实现 0xfac98fbe68a4153be8eed8de289a9ccdec8b1674。 嗯……该合约尚未在 Etherscan 上得到验证，我们只有它的原始字节码……

让我们打开方便的 Dedaub 合约库工具来尝试解码这个令人讨厌的原始字节代码：https://library.dedaub.com/ethereum/address/0xfac98fbe68a4153be8eed8de289a9ccdec8b1674/decompiled

• name() 函数返回 Hopper 而不是 PayPal USD（现在通过代理调用 PYUSD 合约返回）
• symbol() 函数返回 XYZ 而不是 PYUSD（现在通过代理调用 PYUSD 合约返回什么）
• initialize()函数与当前实现使用的不同，并且没有initializeDomainSeparator()函数

function initialize() public nonPayable { 
    require(!_initialize, Error('already initialized'));
    _owner = msg.sender;
    _assetProtectionRole = 0;
    _totalSupply = 0;
    _supplyController = msg.sender;
    _initialize = 1;
}

至此，我想说我们知道为什么 EIP712_DOMAIN_HASH 如果被 PYUSD 合约调用可能会返回 0x。 如果它确实是由该合约初始化的，那么它将使用“错误”的名称来设置 betaDeleeratedTransferBatch 和 betaDeleeratedTransfer 函数使用的 EIP712_DOMAIN_HASH 值。

我不会检查该合约的解码版本与另一个合约之间有哪些差异，或者至少我不打算在这篇博文中这样做。 如果你认为这可能是一个值得深入探讨的有趣主题，请告诉我，我会考虑它。

8、第二个版本的实现合约

2023 年 1 月 23 日，代理已更新为部署在 0xa5324B1a3638E50f5E561f016f3D64Ddc277E36a 的第二个合约。

此实现与 PYUSD 代理当前使用的实现有什么区别？ 你可以点击此处查看。

• 合约名称已从 XYZImplementation 更改为 PYUSDImplementation
• name常量已从 Hopper 更改为 PayPal USD
• symbol常量已从 XYZ 更改为 PYUSD
• reclaimXYZ 函数已重命名为 reclaimPYUSD

其他小的变化仅与注释和命名有关，与函数的名称或逻辑无关。

9、第三个版本的实现合约

2023 年 8 月 3 日，代理已更新为部署在 0xcaBB6024b77D50E0250b750C1f1Dc049E7eD6020 的第三个合约。

之前的实现和这次有什么区别？ 你可以点击此处查看。

• name常量已从 Hopper 更改为 Hopper USD
• 注释的其他更改，与函数名称或逻辑无关

10、升级回顾和结论

从第一个实现到最后一个（当前由 PYUSD 代理使用）有什么变化？

• name 常量值已从 Hopper 更改为 Hopper USD 更改为 PayPal USD
• symbol 常量值已从 XYZ 更改为 PYUSD
• reclaimXYZ 已重命名为 reclaimPYUSD

那么 EIP712_DOMAIN_HASH 又如何呢？ 状态变量 EIP712_DOMAIN_HASH 尚未初始化，因此我假设在某个时候会有另一次升级，允许合约所有者调用目前是私有的（并且没有身份验证检查）的 initializeDomainSeparator。

这一切对我来说有意义吗？ 说实话，不……我不明白为什么要使用旧的、模糊的和未经验证的合约作为 PYUSD 代理的第一个实现，该代理的升级只是为了修复名称、符号和回收函数中的不一致问题。 最重要的是，即使进行了所有这些升级，`EIP712_DOMAIN_HASH` 仍然根本没有初始化。

听到 Paxos 或 PayPal 的人讲述所有幕后故事会很有趣 😁

11、PYUSD的完整历史

为了完整起见，并且只是因为我浪费了太多时间来获取已在代理本身上执行的所有事务，所以我必须写下所有这些事务。 再耐心听我说一点，也许你会发现一些有趣的东西！

• Nov-08–2022 0x3b210c2a0cfcf237a48675b70626961be3e435db（标记为 PayPal USD Deployer）已部署 PayPal USD 代理合约并使用 0xfac98fbe68a4153be8eed8de289a9ccdec8b1674 实施合约进行初始化 | 查看交易 0xd2660a80f27d6bdea7760e6f0866debe9b11b33f072cc66e8b447d77410dcf0d
• 2022 年 11 月 8 日 0x3b210c2a0cfcf237a48675b70626961be3e435db（标记为 PayPal USD Deployer）在代理上执行了changeAdmin(0x137Dcd97872dE27a4d3bf36A4643c5e18FA40713)。 我假设 0x137Dcd97872dE27a4d3bf36A4643c5e18FA40713 是执行 PYUSD 合约的“admin”功能的 PayPal/Paxos 多重签名 | 查看交易 0xaac320d81132a42faa0f96b8c1db300a1e81c9deace0620b7ed553e351d8e26f
• Nov-08-2022 0x3b210c2a0cfcf237a48675b70626961be3e435db（标记为 PayPal USD Deployer）在代理合约上执行了initialize()（此时代理正在使用未设置 EIP712_DOMAIN_HASH 值的未经验证的实现）| 查看交易 0x36a4358e3106e4a2face8d733a603b77a49b4b1432b93f139a1d20a09ee99d1a
• Nov-08-2022 0x3B210C2A0CFCF237A48675B70626961BE3E435DB（标记为PayPal USD Deployer）执行SetSupplyController（0xE25A329D329D385DF77DF77DF55D55556265BABE）薄荷和燃烧令牌| 查看事务0x6bc22250e7fbfbfc71977da778cf3081712b3fa65222dc08f424d7b9fb877b6c
• Nov-08-2022 0x3b210c2a0cfcf237a48675b70626961be3e435db（标记为PayPal USD Deployer）执行了proposeOwner（0x0644Bd0248d5F89e4F6E845a91D15c23591e5D33），提议代币合约的新所有者（不要误认为是代理的管理员）| 查看交易 0x99d72ebc4a714445bfce4677a09f11c2afc020bbf89c8355e233709288519d9e
• 2022 年 11 月 8 日 0x0644Bd0248d5F89e4F6E845a91D15c23591e5D33（提议的所有者，请参阅之前的交易）执行了 ClaimOwnership()，设置了一个新的供应控制器，该控制器将能够铸造和销毁代币 | 查看交易 0x40d453e2617705abf7644d6f0adbbd8de757c2f87b187b4abba7806009481fe2
• 2022 年 11 月 8 日 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了 raiseSupply(1100336220000) 铸造 1_100_336 的 PYUSD | 查看交易 0x416b6ed913dba77f99fdc0dd022d28f71648f95702112f984b4aec1815f563d8
• 2022年11月8日0x0644bd0248d5f89e4f6e845a91d15c23591e5d33（合约所有者）执行setAssetProtectionRole（0x0644Bd0248d5F89e4F6E845a91D15c23591e5D33）将自己设置为新的“资产保护角色”| 查看事务 0xcdbc5de8965a8472a31d7e7faa8cf32352f745dee12cdc06a1307795912e1317
• 2022 年 11 月 10 日 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了减少供应（1000000）燃烧 1 PYUSD | 查看交易 0x885055bf81bf8851cd30ff54fdff40e468f10b9bbb8a3697c2eff32627cdcbc1
• 2022 年 11 月 16 日 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了 raiseSupply(1000000) 铸造 1 PYUSD | 查看交易 0x142ac7813b5e01f984e4ec5c86a09949eb821b5c0ed105bfd1da97987baf0b3d
• Jan-23-2023 0x137dcd97872de27a4d3bf36a4643c5e18fa40713（代理管理员）执行了upgradeTo(0xa5324B1a3638E50f5E561f016f3D64Ddc277E36a)，将代理升级到新的实现0xa5324B1a3638E5 0f5E561f016f3D64Ddc277E36a | 0f5E561f016f3D64Ddc277E36a 查看交易 0xc2ec3bd3e4ac3c7fab3780ebc6dedbd79133a381ed6fae5fd556c13bf3c868f8
• Jan-24-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了increaseSupply(1000000)铸造1 PYUSD | 查看事务 0xa3bf4a8fc8a68d4eebcf84e649bf42e95ac34906e48ebaf597daf0fb794d7701
• Jan-24-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行减少供应（1000000）燃烧1 PYUSD | 查看交易 0x25636577412798ea556011ca14b239abeb51c78f9a3ff57610db525da584d189
• Jan-31-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了increaseSupply(1000000)铸造1 PYUSD | 查看事务 0xe0e03ef7b09595c58028e3a93fa5c5c08e1d65602fa437d510f6713d71c1561a
• Jan-31-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了增加供应（26400719690000）铸造26_400_719.690 PYUSD | 查看交易 0xe324b3a6cdd41ef2e04a6822667c74b147b396b2c628b40cb9ab00cc0508b3de
• Feb-23-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行减少供应（25501056910000）燃烧25_501_056.910 PYUSD | 查看交易 0x658bd02d7b705122204e234aa9b6e00fcf0aa02cb79317890c30f2dda28de560
  Aug-02-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了increaseSupply(1000000)铸造1 PYUSD | 查看事务 0x20c083241b1b2a35002f44ca0dc52b195378338570cfc879a2d5c6d6d913e4a1
• Aug-02-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了减少供应（1000000）燃烧 1 PYUSD | 查看事务0x92fac8b00776766bf0f86a843fcf8153df230e41c889f5f0e8905fb922cc4ac4
• Aug-03-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了increaseSupply(1000000)铸造1 PYUSD | 查看事务 0xe49dd9c785fde4fae19b9058ec500efaa8897d5066b3c334080d06a2b12ed955
• Aug-03-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行减少供应（1000000）燃烧 1 PYUSD | 查看交易 0x1f83a3df01acf92ad32c6459f445dc48064aaaf1aa8079a418888fc3b9b84f35
• Aug-03-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了增加供应（24904995660000）铸造 24_904_995.660 PYUSD | 查看事务 0xecede3ce7a5c890196af5b456c8d59ee369495b0839cfb935eb69104e1dc9084
• Aug-03-2023 0x137dcd97872de27a4d3bf36a4643c5e18fa40713（代理管理员）执行了upgradeTo(0xcaBB6024b77D50E0250b750C1f1Dc049E7eD6020)，将代理升级到新的实现0xcaBB6024b77D50E02 50b750C1f1Dc049E7eD6020 | 查看事务0x34dcf26b3ad5a982f73617a8199c771ef86f8943482ae1e37d435afda60f6b9d
  Aug-04-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了increaseSupply(1000000)铸造1 PYUSD | 查看事务 0xddaac0cf9d9ac7110ab572e0adecf741d304a0b31d6d18f31c12839bb224c969
• Aug-04-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行减少供应（1000000）燃烧 1 PYUSD | 查看交易 0xaaf2b9dd07207da4e7d56c5f9b156e98cc78add804cd1e764c7232838187e82d
• Aug-04-2023 0xe25a329d385f77df5d4ed56265babe2b99a5436e（供应控制器）执行了increaseSupply(10000000)铸造10 PYUSD | 查看事务 0xf54992efde0ba3dc74afc00c256a6bc5fd91123d5f1360c0e88365969bb20db9
• Aug-07-2023 0x137dcd97872de27a4d3bf36a4643c5e18fa40713（代理管理员）执行了upgradeTo(0xe17b8aDF8E46b15f3F9aB4Bb9E3b6e31Db09126E)，将代理升级到新的实现0xe17b8aDF8E46b15 f3F9aB4Bb9E3b6e31Db09126E | 查看事务 0xaac320d81132a42faa0f96b8c1db300a1e81c9deace0620b7ed553e351d8e26f

在这笔交易之后，我又收集了 11 笔交易，但我不会浪费更多的时间和空间，它们只是在我们感兴趣的日期之后（当 PYUSD 合约公开时）发生的一堆增加供应和减少供应 发布并最终升级）。 如果您想自己查看所有内容，可以深入研究这个强大的 JSON 转储（请注意，内容格式已被重新设计以满足我的需求）。

我想知道为什么他们必须在向公众实际发布代币之前增加/减少代币的供应（铸造/销毁）。 他们是否测试一切正常？ 其中一些确实已经过去了（2022 年 11 月）……另一个只有 PayPal 或 Paxos 的人才能为我们回答的问题……

对于那些对 PYUSD 状态的数字、统计数据和信息感兴趣的人，以下是我通过汇总这些交易收集的一些信息。 我收集的最后一个数据块是 18006261。

• 铸造总量：67_799_761_500_000 PYUSD（约 6780 万美元）
• 销毁总量：2_550_1063_910_000 PYUSD（约250万美元）
• 总供应量：42_298_697_590_000 PYUSD（约4230万美元）
• 代理地址：0x6c3ea9036406852006290770bedfcaba0e23a0e8
• PYUSD 代理当前使用的实现：0xe17b8adf8e46b15f3f9ab4bb9e3b6e31db09126e
• 代理管理员：0x137Dcd97872dE27a4d3bf36A4643c5e18FA40713
• PYUSD 所有者：0x0644Bd0248d5F89e4F6E845a91D15c23591e5D33
• 供应控制器：0xE25a329d385f77df5D4eD56265babe2b99A5436e
• 资产保护角色：0x0644Bd0248d5F89e4F6E845a91D15c23591e5D33

12、最终结论（这次是真的）

首先，我要感谢 Hari 和 cmichel 对 Discord 的支持。 他们非常耐心地听我关于这项研究的所有废话😁

另外，还要感谢 devtooligan 和 emilebaizel，他们都非常友善地审阅了这篇文章，并为我提供了一些有用的反馈。

在将来的某个时候，我可能会发布我用于该项目的代码。 目前，它非常混乱，因为我正在尝试不同的路径来实现我的目标，我想在与你分享之前先整理一下。 因此，如果你对此事的任何更新感兴趣，请关注我的 Twitter 帐户！

我希望你喜欢我所做的这项有趣的调查。 有用吗？ 可能是的，至少对我来说。 我能够测试一些不同的方法和工具，并建立了一种深入研究此类调查的方法。 我唯一的遗憾是花了比我预期更多的时间，但我认为这是第一次在某些事情上很正常......对吧？

原文链接：A fun on-chain investigation about PayPal `PYUSD` smart contract

DefiPlot翻译整理，转载请标明出处