规则解读10 / 10
社区关系
30 秒看懂
- 合约只记谁推荐了谁，层级不是会员等级
- 现有关系大多从 Polygon 迁移，Anubis 上邀请未开放
- 白皮书没有推荐奖励比例，本站不能改动关系
关系合约
推荐关系记录在 Anubis 链上的社区关系合约里：
Community0xc9f9a8a2dBf8188AD6610e0239105CAbE67c4993
- 部署时间：区块 1,841,628（2026-04-28）开始有合约代码。
- 合约性质：截至 2026-09-24，区块浏览器显示它是 EIP-1967 可升级代理合约，逻辑合约的源代码没有在浏览器上验证公开。
合约为每个成员保存两项数据：
| 数据 | 含义 |
|---|---|
| level | 成员在关系树中的层级。根成员为 1，每个成员比推荐人多 1 |
| referrer | 推荐人地址 |
合约提供的查询：
members(地址)：返回该地址的层级和推荐人；不是成员的地址层级为 0。referrerOf(地址)：返回推荐人。referrals(地址, 起点, 数量)：分页返回该地址的直推列表和直推总数。
合约只记录“谁推荐了谁”。更深层的团队人数、团队创世共建总额等数据，需要把全部关系按树汇总，这是本站索引服务做的事。
关系树的根
关系树的根成员是 commRoot() 返回的地址 0x159ec1f43d18ff1f275156a4a8b0e53503503c1b，层级为 1，它的推荐人是合约里的占位地址 ORIGIN()，即 0x0000000000000000000000000000000000000001。所有成员都能沿推荐人一路追溯到这个根。
两类事件：Joined 与 Imported
| 事件 | 字段 | 什么时候发出 |
|---|---|---|
| Joined | member、referrer、level | 每个成员加入关系树时 |
| Imported | member、referrer、operator | 关系由操作地址批量导入时 |
链上记录显示，关系树的成员绝大多数是通过 Imported 事件从 Polygon 批量迁移过来的：迁移从区块 1,856,081 开始，分多批进行，仅截至区块 1,888,000 就导入了 318,155 名成员（加上根成员共 318,156 名）。现有成员总数、迁移导入的人数和在 Anubis 上直接加入的人数，见社区数据里的“成员总数”“迁移导入”和“链上加入”，每天的加入数量也在那里。
邀请在 Anubis 上尚未开放
官方 dApp 显示，Anubis 链上的邀请功能尚未开放，页面提示用户到 Polygon 上邀请。官方 dApp 页面 因此 Anubis 上的推荐关系绝大多数来自迁移，新的邀请关系要等官方开放后才会在 Anubis 上正常产生。
关系树有多深
截至 2026-09-24 的数据，创世计划的参与地址分布在关系树的第 6 层到第 97 层之间，中位数是第 45 层。关系树很深，所以本站用索引服务预先汇总团队数据，而不是每次打开页面都去链上逐层查询。
白皮书里的社区算力
白皮书规定，每天的社区生态排放按 50% 与 50% 分为个人算力和社区算力两部分：个人算力部分按个人有效 Power 的权重竞争分配，社区算力部分进入社区算力竞争体系。两部分共享同一个经过三层门控的排放预算，50% 与 50% 只是内部配置比例，不会产生新增排放。白皮书第 73–74 页
Daily Community Emission = 50% Personal Power + 50% Community Power
白皮书没有说明社区算力如何计算，也没有提到它与这份关系合约的关系。
本站的团队工具
本站根据这份合约和创世认购合约，为每个地址整理出下面这些数据：
- 地址页（用导航栏的“查询地址”进入）：该地址是否为成员、层级、推荐人、上级链路、直推列表，以及它自己的创世共建记录。
- 团队数据：地址页公开显示全部下级人数（任意深度）和团队创世共建总额；按深度的分布和完整的团队成员列表在团队页面，属于会员功能。这些汇总来自本站索引服务，同步中时页面会显示“索引同步中”和当前进度。
- 备注、分组与关注的地址（会员功能）：你可以给地址写备注、分组，也可以把常看的地址设为关注的地址；关注的地址可以带备注，和它在其他地方的成员备注是同一条。这些内容保存在你的账号里，存放在本站服务器上，也可以导出和导入备份。不要在备注里写私钥、助记词或任何密码。