我把@TermMax 官方Borrower示例里两行数字重新对了一遍：借款人钱包最后拿到1,530 USDC，GT里记录的债务却是1,600 USDC。这个差额很值得单独看。示例设定是一年到期、MLTV 80%，借款人锁入2 ETH；在示例价格下，最多可以发行1,600个FT，对应到期需要处理的1,600 USDC债务。
接下来的动作才是固定借款成本形成的关键。1,600个FT被拆成1,530个本金部分和70个利息部分；那70个FT与Lending Range Order交互换回XT，再由1,530个XT和1,530个本金FT组合赎回1,530 USDC。结果就是：现在可用的现金是1,530，GT记的是完整到期义务1,600。用实际收到的资金作分母，70÷1,530≈4.58%，与官方示例给出的约4.6%匹配。$ETH
这里最容易误读的是MLTV。80%约束的是这套示例里能够形成的债务上限，不等于“抵押价值的80%一定原样进钱包”。固定成本在成交结构里已经被前置，不能再拿钱包到账额直接当成GT债务额。对借款成本的判断，至少要把实际得到的本金、到期义务和剩余期限放在一起看；只拿GT债务除以抵押价值，更接近仓位约束，不是融资价格。反过来，只盯70这个利息数字也不够，因为它绑定的是这一年期限的示例，不能直接套到更短或更长的市场。即便只是借用BTC长期持有者“不想卖资产、但希望获得流动性”的直觉来理解抵押融资，也应该把“今天拿到多少”和“到期要解决多少”分成两张账。$BTC
所以我看TermMax借款页面时，会更希望确认页把三个数字并排展示：实际到账、GT总债务、到期日。只盯一个“固定利率”很容易低估名义债务与可用资金之间的差。还要强调，这组1,530/1,600是官方机制示例，不是今天某个市场的实时报价。接下来我更想观察实际界面在成交前能不能把这层差额解释得足够清楚，因为用户真正需要核算的是自己拿到的流动性，和到期前必须管理的完整债务。
#TermMax
接下来的动作才是固定借款成本形成的关键。1,600个FT被拆成1,530个本金部分和70个利息部分；那70个FT与Lending Range Order交互换回XT，再由1,530个XT和1,530个本金FT组合赎回1,530 USDC。结果就是：现在可用的现金是1,530，GT记的是完整到期义务1,600。用实际收到的资金作分母，70÷1,530≈4.58%，与官方示例给出的约4.6%匹配。$ETH
这里最容易误读的是MLTV。80%约束的是这套示例里能够形成的债务上限，不等于“抵押价值的80%一定原样进钱包”。固定成本在成交结构里已经被前置，不能再拿钱包到账额直接当成GT债务额。对借款成本的判断，至少要把实际得到的本金、到期义务和剩余期限放在一起看；只拿GT债务除以抵押价值，更接近仓位约束，不是融资价格。反过来，只盯70这个利息数字也不够，因为它绑定的是这一年期限的示例，不能直接套到更短或更长的市场。即便只是借用BTC长期持有者“不想卖资产、但希望获得流动性”的直觉来理解抵押融资，也应该把“今天拿到多少”和“到期要解决多少”分成两张账。$BTC
所以我看TermMax借款页面时，会更希望确认页把三个数字并排展示：实际到账、GT总债务、到期日。只盯一个“固定利率”很容易低估名义债务与可用资金之间的差。还要强调，这组1,530/1,600是官方机制示例，不是今天某个市场的实时报价。接下来我更想观察实际界面在成交前能不能把这层差额解释得足够清楚，因为用户真正需要核算的是自己拿到的流动性，和到期前必须管理的完整债务。
#TermMax