.bit 的 官方文档 有这么一句话：
每注册一个 .bit 账户，其 inviter（如果有） 和 channel 都分别能获得这次注册费用的 10% 的奖励
本文会对这句话背后的一些诸多疑问做一些比较深入的解答
奖的是什么
奖励的是 CKB。.bit 的奖励逻辑都是写进了合约里的，所以奖励动作全程都发生在链上。而链上目前最方便的就是直接奖 CKB
奖给了谁
- 注册商在搭建 das-register 的时候，里面的配置文件有个字段叫
pay_server_address，这个地址负责支付注册账户的开销，同时注册商的 channel 的奖励也是给到这个地址。 - inviter 的奖励就是给了当时注册时填写的 .bit 账户，奖励结果可以从其 .bit 余额 看到。
如何奖励的
在解释 .bit 如何分发各个角色的奖励逻辑之前，需要先给大家普及一下 CKB 上著名的 泛 61 问题
CKB 上的 61 问题
传统的奖励方法一般都是从注册费用里分 10% 出来，直接打给受益地址就行了。但是 CKB 上由于 泛 61 问题 无法这样简单地操作。举个例子：
假设 CKB 的单价是 $0.01 ，$5 就是 500 CKB（再加上一个常见的普通账户的基础存储费至少 206 个 CKB，那么注册一个账户就需要至少 706 个 CKB），那么 10% 就是 50 个 CKB，而
inviter大概率是一个 das-lock，而一个常见的 das-lock 的基础大小至少为 83（即便是一个普通的 CKB cell，它的基础大小也是 61），所以由于这 50 个 CKB 的奖励小于了基础大小，导致无法直接打给受益者。
.bit 的解法
为了解决上面的问题， .bit 引入了一个叫 income-cell 的概念。
简单来说，income-cell 里存储了一个奖励的账本，谁谁应得多少钱都写入了这个账本，这个 cell 的大小就等于里面所有奖励记录的总金额。所以奖励的钱首先都是先 写 & 存 入账本，然后等待 keeper 扫描全网所有的 income-cell，最后再将总量合适的奖励（约大于 126，准确来说是：120 / 0.95 = 126.32）打给受益者，受益者会到账至少 120 CKB（扣除 keeper 的 5% 的合并奖励后的结果）。所以这也是为什么每次奖励到账都是超过 120 CKB 的。
以下图为例，由于 inviterA 在 IncomeCellA 和 IncomeCellB 里记录的奖励总额大于了 126 CKB，那么这两个 IncomeCell 就可以合并成一个 IncomeCellC：
奖励未到账的情况
情况一
而考虑到 income-cell 本身也是有基础大小的（目前设定的是 200 CKB），而维持这个至少 200 CKB 的资金来源就是账本里的各个受益者的奖励总额。所以如果受益者发现自己的奖励迟迟未到账，那么大概率这部分奖励正在维持着网络上的某个 income-cell 去了，比如上图里的 inviterB、inviterC、inviterD 和 inviterE
情况二
当然也会存在某个 inviter 的总奖励超过 126 CKB 但奖励依旧未到账的少数情况。
如下图的场景，虽然 inviterA 总奖励已经超过 126，但是 keeper 还是无法将这两个 IncomeCell 合并成一个，因为剩下的所有 inviter 的奖励总和都凑不够一个新的 IncomeCell 的基础大小（200 CKB）。
总之，.bit 的 channel 奖励和 inviter 奖励都是实时分配的，只要用户注册成功，奖励分配就完成了。只是鉴于 CKB 的底层原理，奖励无法立马发放，但也不会延迟太久。