质押引擎 白皮书 v1.0
BlazePhoenix 质押引擎是面向 BZPX 的单资产金库与信贷工具，全程不使用任何预言机，因为抵押品与债务是同一种代币。主守恒恒等式（Master Conservation Identity）由 conserves 修饰符在每一笔转移价值的交易上强制执行——任何会让账本主张的数额超过合约实际持有量的交易都会回滚。发行按区块时钟上的闭式表达，在八个两年期（eight two-year periods）内逐次减半；二次型加成对锁定承诺给予回报，在七年处最高达 2.75×；两个互不相交的累加器分别支付发行与借款人利息，不存在任何交叉补贴；维护搭乘普通交易顺带完成，并受 gas 上限约束；世界上任何人都可以凭链上的资不抵债证明触发熔断。整套设计立足于一条纪律，它与 BlazePhoenix 聚合器共享，并在此处施加于协议自身的资本：计算，而非信任。每一份收益、每一个利率、每一次偿付能力检查，都由读者可以自行重算的算术从链上状态推导而来——没有价格喂价，没有守护机器人集群，没有必须相信的仪表盘。三条边界在开篇即予言明，因为一项保证的诚实程度不会超过它边缘的诚实程度。引擎正在建设中——这是上方的告示，而不是脚注。管理角色确实存在，且每一个都与限定它的那条界线一并列出：一个其转移价值的权限无法触及质押者本金的管理员（§10.3），以及一个最强权限也不移动任何资金的守护者（§12）。而且锁定并非无条件：存在两条停机路径，二者被刻意设计得互不相同，各自都有完整规定，其来源被永久记录（§12）。读者需要评估的不是我们的诚实，而是我们的依据。
状态：引擎正在建设中
BlazePhoenix 流动性聚合器是已经交付的产品。质押引擎尚未交付：它正处于活跃的工程开发之中。本文规定质押引擎当前形态的设计——下文提到的每一个方程、每一条不变量、每一个常数与每一个入口点，都是实现必须遵守的规范——以便读者在引擎存在之前就能评估它。对不可修改的软件而言，先发布设计才是正确的操作顺序：一份无法打补丁的合约，应当在部署之前而非之后接受评判，而本文的构造正是为了让这种评判成为可能——每一个数字都可重新推导，每一项保证都与它的强制执行位置和它的边界写在同一段里。当引擎交付时，已部署的字节码将成为准绳，本文则成为它的记录；在那之前，本文是引擎关于自身将会是什么的公开且可证伪的主张。完整正文（英文）: https://blazephoenix.xyz/staking-whitepaper.md
§1 · 一条纪律，两台引擎
BlazePhoenix 是一套完整的链上金融协议，由两台相互咬合的引擎构成——一台流动性聚合器与一台质押引擎——它们共享同一条纪律：计算，而非信任。协议中的每一个价格、每一份收益、每一次偿付能力检查，都由读者可以自行重算的算术从链上状态推导而来。没有路由服务，没有价格预言机，没有守护机器人，没有升级通道：多数协议请求别人相信它，而这一套公开的是可供核查的手段。
§2 · 质押论题与主守恒恒等式
聚合器为他人的流动性寻路；协议还必须培育自己的流动性。BlazePhoenix 质押引擎把 BZPX 从静态余额变为生产性资本——一件收益工具，一条有抵押的信贷额度，以及把长期持有者与协议成败绑定在一起的对齐机制——并且这一切都在同一份合约中完成，由同一个方程统辖。
§3 · 代币与发行计划
十亿枚 BZPX，永久固定，形式是一枚朴素的 ERC-20：18 位小数，没有增发路径，没有转账费，没有 rebase，没有转账钩子，没有暂停也没有黑名单——这是记录在质押代码库中的六条部署不变量，在接线时对照代币字节码逐一核验。完全稀释供应量自创世起即为已知；稀缺性是合约的属性，而非一项政策。十亿枚在协议各项分配中的划分属于协议层面的记录，与配套论文以及代币自身的链上记录同在；本文承载的是引擎所强制的那一部分——发行预算
§4 · 强制锁定质押与加成曲线
直白地说：不存在流动性质押——每一笔存入都把它的资本承诺给一个选定的期限，而协议只是恪守这个期限。精确地说：
§5 · 双累加器主义（Dual-Accumulator Doctrine）
引擎从两个互不相交的来源支付两种不同的收益，质押者按是否借款获得其中之一或两者。这是整套设计中最微妙的部分，也是同一份合约能够同时服务储蓄者与借款人而互不补贴的原因。记账采用在整个 DeFi 中久经验证的累加器模式：每份额的全局指数随价值到来而推进，每个仓位保存其上次结算时的指数，待领收益即为该差值乘以仓位权重。两个累加器在同一个时钟上推进——_updateGlobal 在每个入口点中最先运行，
§6 · 信贷额度
借贷协议在预言机上折戟的次数，远多于在数学上折戟：被操纵的喂价会让稳健的抵押品显得一文不值——或让一文不值的抵押品显得稳健——而清算逻辑无论多么正确，都是在谎言之上执行。BlazePhoenix 并不去加固预言机，而是取消了这个类别。抵押资产与借入资产是同一种代币：质押者锁定 BZPX 并以此借出 BZPX，于是一个仓位的贷款价值比只是同一种代币两个数量之间的纯比值——债务比质押——评估时无需任何外部价格。没有可供操纵的喂价，也没有 TWAP 窗口
§7 · 清算
当累计利息把一个仓位的质押侵蚀到距其债务不足 5% 时，该仓位即可被清算——用一句话表述这项保证：当且仅当 debt × 100 ≥ stake × 95 时仓位可被清算，无许可路径与自主路径以完全相同的方式检查，并且不会提前哪怕一个区块。随后处置按固定的瀑布顺序执行：
§8 · 自主维护（Autonomous Maintenance）
清算必须及时，利息必须累计，过期的锁定加成必须释放——业界对这三件事的惯常答案，是一支盯着链的链下守护机器人队伍。机器人一停，账簿就发霉。那正是本协议在其他一切地方都拒绝的那类活性依赖，因此质押引擎把它取消了：账簿在普通使用的自然流量中自我清理。
§9 · 验证面
托管他人价值的协议，不应请求别人相信它；它应当公开可供核查的手段。质押引擎把自身的完整性变成一组公开、免费、链上的读取调用，使任何一方——质押者、审计者、竞争对手、怀疑者——都能在一次 eth_call 中确认合约持有它所声称欠下的数额。不需要仪表盘，不需要子图，不需要索引器，不需要信任。
§10 · 经济安全
引擎的安全性建立在对手无法弯折的算术之上，而不是建立在对手可以打破的假设之上。既无预言机，也无链下依赖，威胁模型因此异常之小，而剩下的每一项威胁，都由一条在每笔交易上强制执行的结构性性质来封堵，而非依靠运营者的警觉。
§11 · 一个仓位的生命周期
要理解前面各节的机制，最好的办法是带着具体数字，跟随一个仓位走完它的一生。这段演示中的全局数字只是示例——它们设定了计算该仓位份额时所用的分母——但每一个常数与每一条公式都出自合约本身，下面的每一个数字都由它们推出。
§12 · 紧急情况与熔断器
锁定并非无条件，若说不然便是曲解了这项保证。存在两条停机路径，而且它们被刻意设计得互不相同。
§13 · 结论
我们的出发点，是让偿付能力成为代码的属性，而不是关于代码的说法；本文所规定的引擎，正是这一意图贯彻到底的结果。一条守恒恒等式，作为回滚条件在每一笔转移价值的交易上强制执行，使得通过正常运作走向资不抵债成为不可达；单资产设计在预言机得以存在之前，就移除了这个让多数借贷方折戟的东西；维护搭乘普通使用顺带完成，受 gas 约束，任何地方都不需要守护机器人；而最后手段的停机，属于任何能够仅凭链上状态证明其必要性的人。
Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz