到今朝为止，55 M 的 XRP 已经通过这种方法释放了，我们简朴看了一下流向，大部门汇入了 Bitstamp。
截至发文的时间（北京时间 2019 年 5 月 17 日），有共计 17B 的 XRP 被释放，13.2B 返还到托管账户，净释放量 3.8B XRP。
Coin Metrics 的指控原文译文如下（下文 B 为十亿，M 指一百万）：
我们发此刻 2018 年第 3 季度和 2019 年第 1 季度，Ripple 错误地陈诉了返还给托管账户的 XRP 数量，这两次季度陈诉给出的返还数量都高于实际返还数量各 100M XRP。（意思就是这两个季度实际释放量都多了）
其它未知托管XRP 账本的托管属性是为了更好的打点 Ripple 手中的 55B XRP。而一些据悉还有 200M XRP 也有其它的托管打算。
托管行列执行进程的倒戈按照 Ripple 的官方声明，我们可以作出这样的假设告诉：当月月初被释放却没花出去的那部门 XRP，当月月末时候会被返还到托管账户中，到期月份继承向下顺延（译者按：就像之前说的，第 0 月没花完留到第 55 个月，第 1 个月留到第 56 个月，之前的 54 个月统统这样被布置，见前文）。Coindesk 在 Ripple 发出通告的当天的一篇文章中的论调跟我们的假设也是不约而同的。就在通告宣布的前一天，Ripple 更新了 Dev Blog 一篇，说法与我们一致。而偏偏链上数据讲了个纷歧样的故事：没被利用的资金没有依次顺延添加到新的托管合约中，而是要补足前一个合约中不敷 1B 的部门，剩下的顺延。
我们将建设 55 个合约，每个合约有 1B 的 XRP。以一个月为一期，从第 0 到第 54 个月一期释放一次（将第 0 月视为第一次释放月，在这里是 2018 年的 1 月份。共 55 个合约依次按月释放，第 54 个月释放完毕）…只要是我们没有用完的部门，每个月城市返还到这个托管行列中。好比说，假如第 0 个月（在这里是 2018 年 1 月）竣事了，我们尚有 500M 的 XRP 没花，这部门将被顺延存到托管账户中，到期日即为第 55 个月。
我们并不认为这样的操纵是切合 Ripple 之前发布的一些机制与打算的。
原文标题：《An on-chain analysis of Ripple’s escrow system》
与季度陈诉的相异之处
Ripple 每个季度城市宣布市场陈诉，具体叙述托管账户环境，给出每个季度 XRP 的托管与返还数量。我们挪用 API 获得了账本信息，将链上勾当数据与 Ripple 发布的数字举办了比对。
假如凭据 300M 来算，Ripple 宣称的释放打算仍然比它实际执行的要慢 20%。
由此可以得出的结论是：Ripple 在实际的释放执行中存在「不厚道」的行为，而且截至本篇文章宣布前，Ripple 官方并未给出令人满足的表明。Coin Metrcis 的指证固然属实，却离「重磅炸弹」还距有相当大的一段间隔。
这种模式自此就一直一连下去了。固然讲原理将剩余资金依次补齐并非犯上作乱，但这个阉割版的方案无疑加快了 XRP 的释放。这跟之前 Ripple 强调的，和我们公共领略的谁人禁欲版本显然纷歧样。在 Ripple 宣布的先容文章中，按照其宣称的托管释放行列，我们绘制了下图蓝线。而红线则是其实际的托管释放模式。假如是凭据原先 Ripple 所说的每月花 50% 的量来算，那么实际的释放时长与其打算模式的释放时长足足相差 21 年（译者按：鉴于前两个月只花了 10%，没到 50%，后期的补齐量也是远远低于 50%，因此这个相差年份其实没有那么浮夸）。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
