rayls

@Rayls 의 스테이킹 APY를 볼 때 단순히 표시된 수익률만 확인하면 충분할까?
실제 수익률을 이해하려면 한 가지를 더 살펴봐야 한다.
수익이 어떻게 기록되고, APY로 계산되며, 실제 보상 지급까지 연결되는가?
이번에는 Rayls 공식 저장소의 "RewardCurve"와 "RewardDistributor" 코드를 직접 비교해 봤다.
1. 스테이킹 APY에 네트워크 수익이 자동으로 반영될까?
"RewardCurve"는 기본 월간 배출량과 변동 배출량을 합산해 연간 APY를 계산하도록 설계돼 있다.
여기서 중요한 부분은 "recordRevenue()"다.
이 함수는 네트워크 수익을 자동으로 가져오는 기능이 아니다. "REVENUE_REPORTER_ROLE" 권한을 가진 계정이 직접 호출해야 변동 배출량에 반영된다.
즉, 수수료를 처리하는 "FeeAggregator"가 존재한다고 해서 그 수익이 자동으로 "RewardCurve"에 기록되는 것은 아니다.
수익 처리와 APY 계산에 반영하는 과정은 별개다.
2. 계산된 APY가 실제 보상 지급액을 보장할까?
그렇지는 않다.
"RewardCurve"는 APY를 계산하지만 RLS를 직접 보관하거나 지급하지 않는다.
실제 보상 분배는 "RewardDistributor"가 담당한다.
코드를 보면 보상 목표액을 계산한 뒤, 부족한 경우 "RLSAccumulator"에 있는 사용 가능한 잔액으로 보충을 시도한다.
따라서 APY가 계산된다는 사실만으로 해당 수익률이 그대로 지급된다고 볼 수는 없다.
실제 지급은 보상 재원과 분배 조건에도 영향을 받는다.
3. 그렇다면 RewardCurve는 실제 메인넷에 적용됐을까?
이번 분석에서 가장 중요했던 부분이다.
Rayls 공식 저장소의 RewardCurve 배포 안내서를 확인해 보니, 해당 문서에는 RewardCurve가 고정된 배포 주소와 "deployments.json" 등록 항목을 갖고 있지 않으며, 아직 어디에도 배포되지 않았다고 명시돼 있다.
또한 배포 스크립트는 Rayls 메인넷에서 실행을 거부하도록 작성돼 있다.
물론 "RewardDistributor"에는 RewardCurve 주소를 연결하는 설정 기능이 존재한다.
하지만 코드에 연결 기능이 있다는 것과 실제 메인넷에서 연결돼 작동한다는 것은 다른 이야기다.
따라서 공개 저장소만으로 현재 메인넷에서 수익 연동 APY가 활성화됐다고 판단할 수는 없다.
4. 이번 코드 분석으로 확인한 내용
- 코드에서 확인: RewardCurve는 기본 배출량과 변동 배출량을 바탕으로 APY를 계산한다.
- 코드에서 확인: 수익 기록과 월간 초기화에는 별도 권한을 가진 계정의 호출이 필요하다.
- 코드에서 확인: 실제 보상 분배는 RewardDistributor가 담당한다.
- 공식 문서에서 확인: RewardCurve의 배포 상태에 관한 안내와 메인넷 배포 제한이 기록돼 있다.
- 아직 확인하지 못한 것: 현재 메인넷에서 RewardCurve가 실제로 배포되고 RewardDistributor에 연결돼 있는지 여부다.
이번에 코드를 살펴보면서 느낀 점은 명확하다.
스테이킹 APY를 평가할 때는 숫자만 보는 것이 아니라, 그 숫자가 어떤 데이터로 계산되는지, 실제 보상 재원은 어디서 나오는지, 그리고 해당 기능이 실제 네트워크에 적용됐는지까지 확인해야 한다.
코드가 존재한다는 것과 실제로 작동한다는 것은 다르다.
이 차이를 구분하는 것이 스테이킹 수익률을 제대로 이해하는 첫걸음이라고 생각한다.
참고 자료
RewardCurve 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardCurve.sol
RewardDistributor 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardDistributor.sol
RewardCurve 공식 배포 안내서
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/script/interactions/reward-curve/README.md
RewardCurve 배포 도구 관련 PR
https://github.com/raylsnetwork/axyl/pull/174
#Rayls $RLS

前几篇我一直在测 Rayls 的证明要算多久，但对银行来说还有一个更基本的问题：钱什么时候才算真正到账、再也撤不回来？这周我换了个方向，让 GitHub 的服务器同时盯着以太坊和 Rayls 公链两个小时，看它们自己怎么回答这个问题。
先给短答案。银行说的"到账"有两层意思：法律上不可撤销，和技术上不会被回滚。技术这一层，以太坊节点自己标记"已最终确定"的区块，比最新区块落后 12.6 到 19.2 分钟，中位数 16 分钟；Rayls 公链则在每个区块出来的那一刻就把它标记为最终确定，区块大约 1.35 秒一个。这种"确定性终局"（deterministic finality）也有代价：共识推进不下去时，链会停下来而不是分叉。Rayls 公链上线以来至少停过两次，一次 11.72 小时，一次 9.15 小时，两次恢复后都直接接在停下前的那个区块后面。
两种"终局"，银行两种都要
国际清算银行支付委员会和国际证监会组织 2012 年发布的《金融市场基础设施原则》（PFMI）第 8 条说，金融市场基础设施应当提供"清晰、确定的最终结算"，至少在起息日结束前完成，必要时应做到日内或实时。它的关键考量之一，是系统规则必须清楚定义结算在哪一刻成为最终。欧盟 1998 年的《结算最终性指令》第 5 条也是同一个思路：从系统规则定义的那一刻起，参与者和第三方都不能再撤销转账指令。
这是法律上的终局，靠规则和法律来定。技术上的终局问的是另一件事：这笔交易所在的区块，还有没有可能被替换掉。
公链在这里分两类。比特币属于概率性终局，区块后面接的块越多，被替换的可能就越小，但永远不是零，所以交易所会说"等多少个确认"。确定性终局的链用的是拜占庭容错共识，一个区块只要被足够多的验证者签署，就不会再变。今天的以太坊介于两者之间：最新的区块仍有可能被替换，要等验证者对检查点完成投票，才算最终确定。
两层终局之所以要放在一起看，是因为银行的规则需要一个能写进去的时刻。确定性终局给了这个时刻：区块出来，就是终局。概率性终局只能给出一个风险越来越小的过程。
怎么测的，任何人都能复现
测试代码在公开仓库 hansonhan0520-lang/enygma-bench 的 finality 文件夹里，由 GitHub Actions 运行，结果自动存进仓库。这是我第一次实测终局，前几篇测的都是零知识证明的算力，和本篇没有重叠。
采样脚本同时盯着两条链，每次一小时，连续测了两次：Rayls 公链每 0.25 秒问一次，以太坊每 1 秒问一次。每次用一个批量请求同时取回"最新"、"安全"和"已最终确定"三个区块，保证三者是同一时刻的读数。每个高度第一次出现时的区块哈希都记下来，结束后逐个重新查询，几个小时后又全部再查一遍，看有没有哪个区块被替换过。
两次采样分别是 Actions 运行 40642493952 和 40649630038，时间是 2026 年 10 月 28 日 06:12 到 08:22（UTC）。以太坊用的是 PublicNode 的公共节点，Rayls 用的是官方公共节点 mainnet-rpc.rayls.com。
以太坊：节点自己说，要等大约 16 分钟
两个小时里，以太坊出了 599 个区块，平均约 12 秒一个，其中有三次空了一个时隙。节点标记的"已最终确定"区块始终落后最新区块 62 到 95 个，折合 12.6 到 19.2 分钟，两个小时的中位数都是 16 分钟。"安全"区块落后 30 到 63 个。
这和 ethereum.org 的说法一致：一个以太坊区块大约 15 分钟后才最终确定，因为验证者要跨两个周期（epoch）完成投票。
这两个小时里，以太坊的 605 个区块事后重查，一个都没有被替换。但这不能说明以太坊不会回滚，头部区块被替换本来就少见，两个小时的样本太小，看不出频率。以太坊和 Rayls 真正的差别，在于节点自己愿意承诺什么。
Rayls：区块一出来，就是最终确定
Rayls 这边，两个小时里问了 27,788 次，"已最终确定"区块和最新区块每一次都是同一个，"安全"区块也是。平均每 1.35 秒出一个区块，一共看到 5,325 个高度。采样结束 0.3 到 1.4 小时后全部重查，没有一个哈希变过。
这个结果是节点的设计，不是巧合。Rayls 公链的共识客户端叫 Axyl，代码公开在 GitHub。公共节点报告的版本号 1.4.1（6909618），正好对应公开仓库里的 mainnet-v1.4.1 这个标签。在这个版本的执行流程里，共识层每提交一批结果，节点执行完后先把它设为最新区块，紧接着下一行就调用 finalize_block，把"已最终确定"和"安全"同时指向这个区块。也就是说，节点不会等"再过几个块看看"，共识提交即终局。
还有一个观察者视角的数字：一个 Rayls 区块从它自带的时间戳算起，大约 2 秒后出现在公共节点上，以太坊也在 2 秒左右。区块时间戳只精确到秒，所以这个数字只能看量级。
代价：宁可停下，也不分叉
确定性终局的另一面，是共识推进不下去时，链只能停。Axyl 自己的文档写得很直白：区块顺序和终局，要靠当前活跃的验证者正常工作才能产生，没有它们，什么都不会被提交。
我用二分查找在链上找区块之间最长的空档，找到了两次停摆。第一次从 2026 年 5 月 5 日 21:59:32 到 5 月 6 日 09:42:29（UTC），停了 11.72 小时。第二次从 6 月 21 日 01:05:33 到 10:14:47，停了 9.15 小时。两次停摆后出的第一个区块，父哈希都正好是停摆前最后一个区块，说明链是原地续上的，没有分叉，也没有区块被替换。
第二次停摆，Axyl 仓库里有一份事故报告。原因是第 52 个周期切换时，一批被延后执行的交易建成了最新区块，却带着一个更旧的轮次编号，提议者据此认为执行严重落后，便一直限速，最后 7 个验证者全部停住，重启也没用。修复是提交 3a71a1a。第一次停摆在公开仓库的事故文件夹里没有记录。
这两次是我在两个日期范围里各找的最长空档。我没有逐块扫描整条链，所以不能排除还有更短的停顿。
出块间隔变过两次
回溯整条链的出块节奏，还有一个公开资料里没有的发现。我从创世区块到现在均匀取了 61 段，每段算平均出块间隔：4 月 30 日上线到 9 月 9 日左右，除了包含停摆的两段，稳定在 1.29 到 1.32 秒；9 月 11 日到 10 月 5 日，缩短到 0.69 到 0.70 秒；10 月 7 日以后，又回到 1.33 到 1.38 秒。
这解释了一个旧数字。9 月 12 日我从区块浏览器读到的平均出块时间是 568 毫秒，那正是快的那段时间。今天再引用这个数字，就已经过时了。
变化的原因我没能确定。公开的三个主网版本分别在 7 月 27 日、8 月 25 日和 10 月 2 日发布，第一次变化前后没有新版本；第二次变化前几天有 10 月 2 日的版本，但时间接近不等于就是原因。代码里出块节奏相关的参数由运营方配置，默认值是最长 10 秒、最短 5 秒提议一次，主网实际出块远快于这个默认值。
另外，Rayls 文档里"亚秒级终局"的说法，写在 Sovereign 机构账本的介绍页上。Sovereign 和公链都用 Axyl 共识，但部署方式不同，我测的是公链，这个数字既不能证实也不能否定 Sovereign 的说法。
对银行意味着什么
这一节是推断，不是测量。
第一，确定性终局让规则里那个"最终时刻"可以直接对应到区块上。PFMI 要求系统规则定义结算何时最终，Rayls 公链的区块天然就是这样一个时刻，以太坊则要再等一刻钟左右。
第二，银行要多问的是可用性。英国 CHAPS 每个工作日的结算时间是 06:00 到 18:00，一次 9 到 12 小时的停摆，能占掉大半个结算日。停摆不会让已结算的交易被撤销，但新的结算做不了。所以评估这类网络时，除了终局，还要问停摆的频率、时长和恢复流程，这属于监管在运营韧性上关心的问题。
第三，技术终局不等于法律终局。区块不可替换只是技术事实，交易何时在法律上不可撤销，仍然要靠系统规则和所在地法律来定。
还没定的部分
我测的是 Rayls 公链，不是银行实际使用的 Sovereign 账本和私有网络枢纽。第二次采样快结束时，Rayls 官方公共节点开始返回"请求过多"（HTTP 429），说明它有限流；那一次的 Rayls 读数在此之前已经存下，汇总由原始数据重新计算。根据 Rayls 的资料，枢纽目前仍运行在 Besu 的权威证明网络上，文档还写到跨机构的 Enygma 交易完成最终确认需要几十秒，这两项这次都没有测。观察只来自一个公共节点和一个 GitHub 运行器。以太坊两小时没看到回滚，不代表它的回滚频率可以忽略。停摆只在两个日期范围里各找了最长的一次。
我的看法
"到账"这两个字，在以太坊上要等一刻钟左右才算数；在 Rayls 公链上，区块出来就算数，节点代码也是这么写的。但确定性终局换来的是另一种风险：停下来。Rayls 公链半年里至少停过两次，每次超过 9 小时。
判断标准很简单：任何人都可以在 enygma-bench 仓库运行 finality 和 finality-halt 两个工作流，看 Rayls 的"已最终确定"是否始终等于最新区块，以及链上有没有新的长时间空档。如果 Rayls 公布 Sovereign 和枢纽的终局时间和可用性数据，就可以拿同一套方法去对照。
参考来源：
CPMI-IOSCO《金融市场基础设施原则》第 8 条，2012 年 4 月 16 日：https://www.bis.org/committees/cpmi/pfmi/overview
欧盟《结算最终性指令》98/26/EC，1998 年 5 月 19 日：https://legislation.gov.uk/eudr/1998/26/data.html
ethereum.org，Single slot finality（页面更新于 2026 年 7 月 23 日）：https://ethereum.org/roadmap/single-slot-finality/
Axyl 共识客户端源码，标签 mainnet-v1.4.1（2026 年 10 月 2 日），事故报告 doc/incidents/2026-06-21-mainnet-halt.md：https://github.com/raylsnetwork/axyl
本文采样代码与全部日志，Actions 运行 40642493952、40649630038、事后重查与停摆定位（2026 年 10 月 28 日）：https://github.com/hansonhan0520-lang/enygma-bench
#Rayls $RLS #区块链结算

Публичные блокчейны обеспечивают прозрачность, но банки не могут относиться к каждой финансовой транзакции как к публичной публикации в социальных сетях. Остатки на счетах клиентов, суммы платежей и контрагенты могут содержать коммерчески или личностно чувствительную информацию.
Поэтому главный вопрос не в том, должны ли банки использовать блокчейн. Вопрос в том, как воспользоваться преимуществами расчётов в блокчейне, не раскрывая конфиденциальную финансовую информацию.
1. Почему обычные публичные блокчейны создают проблему
В типичном прозрачном блокчейне транзакции могут раскрывать адреса кошельков, суммы токенов и закономерности финансовой активности. Даже если к адресам напрямую не привязаны настоящие имена, повторяющиеся транзакции иногда помогают наблюдателям связать активность с конкретными организациями или людьми.

Если перевод в Rayls завершится ошибкой, вернутся ли мои токены?
Что произойдёт с токенами, обработанными в исходной сети, если транзакция в целевой сети завершится ошибкой? $RLS
При перемещении токенов в другой блокчейн активы в исходной сети могут быть заблокированы или сожжены. Но если обработка в целевой сети завершится ошибкой, потребуется процедура восстановления состояния активов.
В официальной документации Rayls описан механизм восстановления на такой случай. Однако изучение открытого кода выявляет дополнительные моменты, которые необходимо проверить.

Что я выяснил, изучая консенсус, архитектуру расчётов и квитанции о транзакциях в Rayls.
Я начал с простого вопроса:
Если блокчейн обещает окончательность менее чем за секунду, значит ли это, что вся транзакция завершается быстрее чем за секунду?
На первый взгляд ответ кажется очевидным. Транзакция подтверждается, сеть достигает консенсуса — операция завершена.
Но финансовая инфраструктура устроена сложнее.
Транзакция может быть зафиксирована в одном реестре, в то время как более масштабная операция всё ещё зависит от другого реестра, ретранслятора, проверки доказательства или выполнения на стороне сети-получателя.

$RLS
Пересматривая код Rayls Relayer, я заметил кое-что странное.
Если Relayer отвечает за передачу сообщения, разве у него не должно быть права RELAYER и на "executeMessage()"?
Но когда я проследил за реальным кодом, оказалось, что это не так.
Напротив, в Rayls права на передачу сообщений и их фактическое выполнение разделены.
В Public Chain Relayer впервые появляется в "PublicRNEndpoint.receivePayload()".
Здесь сообщение не выполняется напрямую,

Блокчейн дает финансовым учреждениям то, в чем они остро нуждаются: возможность проверять расчеты, не полагаясь целиком на закрытую базу данных.
Но здесь есть очевидная проблема.
Банки не могут просто размещать все детали каждой транзакции в публичном блокчейне.
Сведения о балансах, контрагентах, суммах транзакций и другая конфиденциальная информация должны оставаться закрытыми, но при этом регуляторам, контрагентам и участникам сети нужны достаточные доказательства того, что транзакция действительно состоялась.
Как же обеспечить одновременно конфиденциальность и возможность проверки?

В прошлый раз я прогнал публичный код доказательства, опубликованный Rayls, и измерил: для анонимной группы из 6 человек на каждую запись уходит 1,96 секунды. Но в той статье было три фразы, которые являются выводами, а не измерениями — я это понимаю. На этой неделе я заменил машину на 2-ядерную и добавил несколько наборов данных, чтобы вернуться и восполнить те три фразы измерениями.
Сначала уточню, какое отношение у этой статьи к предыдущей, чтобы читатели не подумали, что это просто повтор публикации. В прошлый раз измерялось время доказательства для режимов на 2 человека и на 6 человек в однопроцессорной среде; эти два числа при повторном тестировании почти не изменились. В этой статье всё новое — это те три вещи, которые в прошлой работе не удалось измерить и можно было только предположить.

Я думаю, что в уведомлениях о блокировке обычно волнует лишь одна вещь: можно ли проверить это обещание. В большинстве проектов «блокировка команды» в итоге сводится к одной фразе — вы можете либо верить, либо не верить. На этот раз иначе, поэтому я проверил это on-chain.
Сначала обозначим факты. Parfin — ключевой технологический партнер за спиной Rayls: он отвечает за разработку приватных узлов, приватной сети, privacy-фреймворка Enygma и блокчейна Rayls. В качестве вознаграждения за работу до TGE он получил 1 070 493 535 RLS — около 11% от первоначального общего предложения в 10 млрд.
Эти токены ранее хранились у институционального кастодиана на Ethereum. Причина довольно практичная: на момент TGE блокчейн Rayls еще не был запущен, поэтому их пришлось сначала держать в хранилище. Сейчас сеть работает, и эти токены перенесли в блокчейн Rayls, где они заблокированы в публично верифицируемом смарт-контракте; при этом время разблокировки перенесено с декабря 2026 года на декабрь 2027 года.

Честно говоря, когда я впервые увидел эти три аббревиатуры рядом, мне показалось, что это три ответа на один и тот же вопрос: кто быстрее, кто безопаснее — выбирай один и дело с концом. Потом я понял: ставить их рядом в рейтинге — всё равно что спрашивать «какой лучше инструмент — молоток, отвёртка или гаечный ключ»: ответ зависит от того, у тебя гвоздь, шуруп или болт.
Каждый из них решает на самом деле три проблемы, которые по ошибке сводят в одну.
Первая проблема такая: я хочу доказать, что нечто истинно, но для доказательства нужны данные, которые слишком чувствительны, и я не хочу показывать их тебе. Банк хочет показать регулятору, что «эта сделка законна, полномочия в порядке, нет повторов», но не желает раскладывать суммы и плательщика/получателя по бухгалтерским книгам. Такое доказательство, при котором требуется правда, но без раскрытия данных,— это вотчина ZK. В чём прелесть: гарантия рождается из математики, а не из «я обещаю, что не загляну». Регулятор или аудиторы, получившие ключ верификации, могут проверить вывод, но не могут добраться до базовых данных. Цена тоже вполне реальная: ZK хорошо доказывает свойства данных, но плохо подходит для совместных вычислений нескольких сторон, когда у каждой нет полного набора данных, и при этом требует существенно больше вычислительных ресурсов, чем открытый текст.

Братья, я всё время прятался и наблюдал за сообществом Rayls. Я знаю, что многие недовольны командой, и я тоже, но команда действительно работает и всё время старается. Просто команда Rayls идёт по пути соблюдения регламентов. Братья, ни в коем случае не сдавайтесь, всё зависит от времени. Я верю, что в итоге команда Rayls предоставит нам экзаменационную работу, которая нас удовлетворит. Я хочу поделиться с вами хорошими новостями — о том, что недавно команда Rayls подключила RPC. Это очень важное событие！！
Коротко и по делу
Что такое RPC
Вы можете понять RPC как выделённую линию между приложением и блокчейном.

В таблице сравнения поставщиков Rayls на девять строк, и я выбрал строку «приватность». Причина очень простая: приватность важна, а Besu — с открытым исходным кодом, так что я могу проверить и документацию, и код.
В таблице Rayls отмечен галочками в обеих строках — «изолирующая приватность» и «криптографическая приватность», а Besu — только в первой строке. Я собирался перепроверить по их собственной документации, поэтому я посмотрел документацию Besu, а затем скачал его код и пересчитал всё.
Вывод не в том, что «Besu не подходит». Настоящее различие такое: эти две компании разместили приватность на разных уровнях, и Besu перенёс это раньше, чем многие думают.

В крипто-сообществе каждую неделю можно увидеть: «какой-то крупный традиционный финансовый игрок выходит в блокчейн». Я теперь такие заголовки в основном просто пролистываю, потому что в большинстве случаев всё в итоге заканчивается инновационными лабораториями: выпустят пресс-релиз — и дальше тишина. Проверить правду довольно простым критерием: обычный клиент в своём приложении — может ли он напрямую открыть и воспользоваться сервисом?
XP Inc. На этот раз этот стандарт был пройден.
Сначала нужно чётко описать эту компанию, потому что масштаб определяет значимость вопроса. XP — бразильская инвестиционная платформа, котирующаяся на NASDAQ, тикер XP. Я сверил данные на их странице для инвесторов за I квартал 2026 года: активы клиентов — порядка 1,529 млрд бразильских реалов, точнее 1,529 трлн; консультантов — более 18 000 человек; за последние двенадцать месяцев общая выручка — 19,8 млрд реалов; прибыль до налогообложения — 5,8 млрд реалов.

19 сентября Rayls опубликовал статью (Privacy has a price). В заголовке было написано honest math, но по всей статье был дан лишь один числовой диапазон: доказательство занимает от нескольких сотен миллисекунд до нескольких секунд. Я несколько недель подряд писал про приватную архитектуру Rayls. На этот раз делюсь с вами новым материалом: я скачал опубликованный код доказательства, реально прогнал его десятки раз — и спешу поделиться этой интересной находкой!
Сначала скажу, о чём был блог. Его ключевые тезисы можно сжать в две фразы. Первая — где именно цена: конфиденциальные транзакции дороже прозрачных — дорого именно генерировать zk-доказательства, а проверка при этом получается дешевле; для базового конфиденциального перевода доказательство на обычном коммерческом оборудовании занимает от нескольких сотен миллисекунд до нескольких секунд. Вторая — что стоит спрашивать: организации не должны смотреть только на TPS, нужно спрашивать, каков будет throughput при той приватности и уровне аудита, которые им реально нужны, и при работе с реальной бизнес-нагрузкой. В блоге считают, что объём расчётов между банками небольшой и полностью укладывается в возможности систем конфиденциальных расчётов.

Я начал делать стейкинг с той партии предопределённых обязательств в июне, поэтому я уже прошёл этот процесс один раз. На этот раз его открыли для всех, и многие из моих знакомых спрашивают, как это сделать и на что обратить внимание — так что я решил всё один раз подробно расписать.
Сначала поговорим о самих изменениях.
Rayls использует делегированное proof-of-stake: валидаторы запускают ноды, производят блоки и обеспечивают безопасность блокчейна. Обычным держателям не нужно самим поднимать ноду — они могут делегировать свои RLS какому-то валидатору и делиться частью наград за стейкинг.
Этот механизм запустили ещё в июне, но тогда он был доступен только кошелькам, которые участвовали в плане предопределённых обязательств и в мероприятии по ликвидному семени. Те участники заранее заблокировали свои монеты до мейннета: официально им дали трёхмесячный бонус к годовой доходности 55%, а ещё даже отправили по 1 USDr в каждый кошелёк, который соответствует условиям, чтобы у них не возникло проблем даже с gas.

В прошлый раз, когда я писал статью про XP, меня всё время мучил один вопрос: после того как выпускается институциональный стейблкоин вроде USDXP, как он вообще участвует в реальных трансграничных расчётах? Эта статья как раз закрывает мою догадку — и попутно впервые помогает мне понять одно слово: «стейблкоиновый сэндвич» (стаблкоин-три смэндвич).
Сначала объясню это слово: оно очень образное. Одно международное платежное поручение: с двух сторон — фиатная валюта, а между ними — слой публичного стейблкоина. Плательщик обменивает свою фиатную валюту на долларовый стейблкоин, стейблкоин на блокчейне выполняет трансграничные расчёты, а затем получатель снова обменивает его на свою фиатную валюту. Похоже на два ломтика хлеба с прослойкой посередине? Это как раз то, как отрасль начала описывать трансграничные расчёты со стейблкоинами.

Я начал стейкать RLS еще на этапе предподтверждения: в обычное время читаю официальный блог, в основном чтобы понять, повлияет ли на меня моя позиция. Но статья про квантование от 30 августа — другая: по сути, она учит организации тому, как делать закупки, и мне, как частному инвестору, к этому напрямую отношения нет. Но я все равно дочитал, потому что в самом начале она установила довольно жесткое правило, а это правило потом вернуло меня обратно к самой статье — к тому, что в ней про меня.
То правило такое: формулировка про «квантовую безопасность» — если не указано четко, какой именно стандартизированный алгоритм применяется и на каком уровне параметров, то это не утверждение, а просто ярлык.

В прошлой статье я рассказал о самом факте открытия стейкинга. Но в чате/в бэкэнде больше всего братья спрашивали одну и ту же фразу: «Как именно это сделать?» Поэтому на этот раз я с нуля и до конца заново прошёл весь процесс, записал каждое действие и все места, где чаще всего можно застрять — просто повторяйте по шагам.
Ссылка на прошлую статью здесь: 质押开放给所有人了,但有几件事最好先知道
Сначала скажите, для кого эта статья. Если вы вообще не сталкивались с Rayls и даже с такими словами, как «кошелёк» и «мост», не очень знакомы — значит, эта статья написана именно для вас. Каждое профессиональное название я сразу же коротко объясню.