拆读Bebop多代币RFQ：篮子金额与结算对象
链小知 · 进阶 · 核验 · 依官方文档整理
用当前EVM规范或已有脱敏篮子报价，把资产顺序、整数金额、做市商组合、授权对象、费用和期限对齐；同时区分JAM路线的最低输出。只形成核对表。
开始前准备
- 准备目标EVM链、卖入/买入资产的合约与decimals，或已有脱敏quote记录
- 记录材料的接口路径、版本和时间；没有当前报价或allowance材料时保留未知，不把示例当实际结果
1. 先固定RFQ篮子形状与接口
当前RFQ接口路径为/pmm/{network}/v3/quote，多代币交易表列121一对一、M21多对一、12M一对多。先将需求画成一组卖入资产和一组买入资产；多对多不在本次已读支持表内，不能自行拼成一种已支持模式。EVM多代币与Solana一对一范围不同。
Aggregation接口为/jam/{network}/v2/quote，依solver和滑点限制执行；它不是RFQ篮子的别名。链可用性表与RFQ schema枚举不完全一致，对实际network/chainId及模式逐项留待核，不能用首页多链宣传补齐。
检查结果：材料已标RFQ或JAM、版本与链；篮子属于121/M21/12M之一，未推定多对多或Solana多代币可执行。
2. 把每种资产与其整数金额逐位对应
M21请求样例用逗号分隔sell_tokens和sell_amounts，顺序必须一致。Ethereum示例的100 USDC是100000000，100 DAI是100000000000000000000；不能因为显示数量同为100就复用整数或按名称识币。逐项记录链、合约、decimals、显示金额和原整数。
12M样例用一项sell_tokens与多项buy_tokens，并用buy_amounts代替sell_amounts来指定各买入数量；不要把两种定额方式同时照抄。将buyTokens返回对象按合约键逐一核对，不能依JSON对象显示顺序配金额。示例不是当前余额、稳定币等价或可用报价证明。
检查结果：每个合约都有独立decimals及整数金额；请求数组顺序对应，响应按合约键对应，卖入定额与买入定额未混用。
3. 区分多代币、多做市商与多步交易
RFQ多代币返回onchainOrderType：单做市商为MultiOrder，多做市商为AggregateOrder。AggregateOrder仍是RFQ做市商组合，不表示已切到Aggregation/JAM，也不是要求用户分别执行多个swap。type的M21/12M描述资产形状，onchainOrderType描述订单/做市商组合，两者不要互换。
官方方法要求使用返回的完整tx；篮子在一笔结算交易中原子处理，条件失败会整笔回滚。此前独立发送的ERC-20授权交易不属于这笔篮子回滚范围，不能把原子结算写成授权也已撤销。已有tx对象或SIG_SUCCESS示例只说明报价/交易材料，不是已广播或已结算。
检查结果：type与onchainOrderType分别记录；AggregateOrder未误作JAM，原子范围限定为结算交易，未把报价当成交回执。
4. 分别核授权对象、交易目标和收款对象
记录approvalTarget、settlementAddress、tx.to、taker、receiver及chainId，不要求这几种地址都相同。RFQ一对一可经Router或直接Settlement，approval规范还提示部分流程可返回Permit2；Aggregation则授权Balance Manager，JamSettlement执行结算，不能把后者当授权目标。
对每个sellTokens项核已有allowance材料中的owner、spender、币种和数量；当前approval示例取第一个卖币，不能据此省略篮子其余卖币。缺allowance或交易目标记录就保留待核。地址应以该报价为准，静态部署表的zkSync Era例外也不能用默认地址替代。
检查结果：各卖币的授权核对均覆盖，approvalTarget与settlement/tx.to/receiver角色明确；缺权限证据未写成已可执行。
5. 区分固定输出、最低输出和报价期限
对既有记录逐币记buyTokens.amount、minimumAmount及expiry。RFQ Best Practices把固定价限定到报价有效期；不要缓存旧报价等有利时再用，也不要把同一意图切成多份独立报价同时执行，因为做市商库存可能已被第一份消耗。此处只判断材料是否过时，不重新请求报价。
JAM的amount是预期输出，minimumAmount是滑点后的最低输出；不能满足最低额则回滚，高于最低额的输出归taker。没有当前报价或无法判定有效期时写未知，而不是零滑点保证。RFQ schema只展示200成功和422参数校验分支，不能据此编出所有无流动性/过期错误码；保留原status、warnings及错误原文。
检查结果：预期/最低输出与有效期已分列；旧记录、缺报价、参数错误或未知状态没有写成保证成交，未编造完整错误码表。
6. 核买入侧费用和额外网络成本
fee以bps计，25表示0.25%，从买入侧扣，sell amount不变，buyTokens.amount已反映扣费，不再减一次。flat fee可依约自动加，不能因请求没有fee就断言零费用。partnerFee/protocolFee及金额币种应按原记录核，priceBeforeFee/amountBeforeFee为空也不代表费用为零。
RFQ合作方费用在链外归集、按月结算；Aggregation使用fee与fee_recipient并在交易中支付，不能因有partnerFee记录就说合作方钱包已收到。当前公开API由客户端发送交易并付网络费，gasFee字段为零不免实际gas，首次授权gas另计；最终成果是篮子/费用/权限核对表，不将文档或报价状态当资产已收。
检查结果：费用单位、买入净额和收取方式已对应；未重复扣费、未忽略发送方/授权gas，也未把费用归集记录或quote当实收。
怎样确认完成
- 形成按链和合约键对应的篮子金额、订单类型与权限表
- 形成预期/最低输出、费用及有效期对照；未核状态单列，按文档整理而未实际执行
常见错误与边界
- 把RFQ的AggregateOrder误当JAM API或多次单独交易。
- 将USDC与DAI的显示数量直接当同一整数单位，或只核第一个卖币的授权。
- 把固定RFQ、JAM最低输出与首页gasless宣传套成所有路线零滑点、零gas。
- 把结算原子回滚扩展到此前授权，或把partnerFee报价记录当已到账收入。