# Portaldot 黑客之屋 2026 | 评委与投票演示帖（ReviveCheck） **URL:** \ **Category:** Hackathon\ **Created:** [2026 年11 月 7 日 16:56 UTC](https://portaldot.discourse.group/t/topic/156 "2026-11-07T16:56:04Z")\ **Posts on this page:** 4\ **Page:** 1
作者： ![Mrooo](https://avatars.discourse-cdn.com/v4/letter/m/ba8739/32.png) [@Mrooo](https://portaldot.discourse.group/u/Mrooo)\ 发布日期： [2026 年11 月 7 日 16:56 UTC](https://portaldot.discourse.group/t/topic/156/1 "2026-11-07T16:56:04Z")
## 项目介绍 ReviveCheck 帮助代币列表维护者和应用程序在接受发布版本之前进行验证。它整合了 Portaldot V3 的最终检查、可检索的报告、链上审批以及应用程序策略。该演示展示了一个 pUSD 上币流程，从检查失败到获批发布，最终被一个独立的应用程序使用。 ## 解决的问题 演示始于一个候选 pUSD 条目，该条目声明了 18 位小数，但 Portaldot V3 测试网报告的是 6 位小数。错误的精度会导致代币数量计算错误。审批还需要严格对应具体的发布版本。ReviveCheck 将决策与已检查的报告及其修订版本绑定，因此当修订版本发生变化、审批被撤销或证据过期时，应用程序可以扣留该条目。 ## 链接 - **演示视频** · [ReviveCheck 演示日 (2:33)](https://www.youtube.com/watch?v=D-Wql9-QMV0) - **GitHub** · [源代码和复现说明](https://github.com/a252937166/ReviveCheck) - **路演幻灯片** · [ReviveCheck 最终演示文稿 (PDF)](https://revivecheck.axiqo.xyz/revivecheck-final-deck.pdf) ## 技术亮点 1. **对比原生视图与 EVM 视图。** ReviveApi 对齐最终检查点和账户映射。验证器通过 Assets pallet 及其 ERC-20 预编译合约对比 pUSD 的精度、供应量和余额。在真实的合约试运行中，18 位小数的条目被拒绝。 2. **重放已批准的证据。** Remark 将封存的报告存储在链上，Solidity 注册表记录针对其精确指纹的批准。视频验证了该指纹，并在原始检查点复现了 13 项观察结果中的全部 13 项。 3. **遵循完整的发布生命周期。** Portaldot V3 测试网记录包含 12 个步骤和 10 个最终收据。它们涵盖了批准、上币、修订版本失效、显式重新绑定、撤销和恢复。修订版本 2 的 pUSD 上币在区块 187205 处最终确定，原生和 EVM 读回结果一致。[发布记录和收据](https://revivecheck.axiqo.xyz/release-status.json) 4. **将决策置于消费者端。** 项目开发的独立应用程序安装开源包，并在接受代币前检查其自身策略。录制中显示的报告于 11 月 1 日达到了七天新鲜度限制。策略要求持续接受必须有新鲜且已批准的证据。演示在测试网上运行，两个签名者账户均由项目控制。 ## 团队 Ouyang Duning，独立开发者。ReviveCheck 参加了 Modular Cloud & Middleware 赛道。[DoraHacks Build 50176](https://dorahacks.io/build/50176) ## 评委与投票契合度 **给评委。** 视频和链接的收据追溯了一个代币经历精度检查失败、修正发布、链上批准以及消费者准入决策的全过程。代码库包含合约、验证包以及复现检查的步骤。 **给社区投票者。** 演示展示了为什么代币列表应该检查链实际上报告的内容。当目录存在分歧或证据过期时，应用程序会扣留代币，直到发布版本再次符合其策略。 ---
作者： ![ympangbill](https://avatars.discourse-cdn.com/v4/letter/y/779978/32.png) [@ympangbill](https://portaldot.discourse.group/u/ympangbill)\ 发布日期： [2026 年11 月 10 日 02:56 UTC](https://portaldot.discourse.group/t/topic/156/2 "2026-11-10T02:56:41Z")
The innovation and technical implementation are both average, and the business and community contributions are open to discussion. 75 points ---
作者： ![Jungle](https://avatars.discourse-cdn.com/v4/letter/j/df788c/32.png) [@Jungle](https://portaldot.discourse.group/u/Jungle)\ 发布日期： [2026 年11 月 10 日 03:43 UTC](https://portaldot.discourse.group/t/topic/156/3 "2026-11-10T03:43:37Z")
**ReviveCheck (65)** ReviveCheck is a token list verification tool project with moderate completeness. It demonstrates the flow of precision check failure, on-chain approval and consumer policy rejection, and its materials are relatively complete. However, in the current submission state, **the lack of concrete on-chain evidence** is the main weakness, which makes it hard for the technical completeness to be fully recognized. ---
作者： ![Rishabh](https://avatars.discourse-cdn.com/v4/letter/r/ea5d25/32.png) [@Rishabh](https://portaldot.discourse.group/u/Rishabh)\ 发布日期： [2026 年11 月 10 日 04:25 UTC](https://portaldot.discourse.group/t/topic/156/4 "2026-11-10T04:25:37Z")
starting the demo with a pUSD entry that claims 18 decimals when the chain says 6 shows the problem right away, and tying each approval to one exact report revision makes sense