有人能帮助解释以下顺序散列的小remainingFillableTakerAmount:0x886618b8da6aa22193ddffc6cfc7d89782a16a7dea9cd698dacb82b8b7e430f9:
0x8836a16db8db1cba0890f0ee97a9926cb47b41010x134e62bd2ee247d4186a1fdbaa9e076cb26c1355522700000000000000000000 (按小数计算为522‘700)分为三个数量级(参见https://ropsten.api.0x.org/orderbook/v1/orders?maker=0x8836a16db8db1cba0890f0ee97a9926cb47b4101和{"total":3,"page":1,"perPage":20,"records":[{"order":{"signature":{"signatureType":2,"r":"0x09f8e3298f92644bc7f855d7b6daad5e9908cf22f26f14dbca03e801f45ac698","s":"0x7b0a88e939f443c63d73cf168502246a412e8086f96e44253803119defcba29c","v":27},"sender":"0x0000000000000000000000000000000000000000","maker":"0x8836a16db8db1cba0890f0ee97a9926cb47b4101","taker":"0x0000000000000000000000000000000000000000","takerTokenFeeAmount":"900000000000000000","makerAmount":"429300000000000000000000","takerAmount":"90000000000000000000","makerToken":"0x134e62bd2ee247d4186a1fdbaa9e076cb26c1355","takerToken":"0x03582cb41f2fd982e1b531d633b6de049d56f2a0","salt":"1657610336337","verifyingContract":"0xdef1c0ded9bec7f1a1670819833240f027b25eff","feeRecipient":"0xbb0f479895915f80f6feb5babcb0ad39a0d7ef4e","expiry":"1658215136","chainId":3,"pool":"0x0000000000000000000000000000000000000000000000000000000000000000"},"metaData":{"orderHash":"0x886618b8da6aa22193ddffc6cfc7d89782a16a7dea9cd698dacb82b8b7e430f9","remainingFillableTakerAmount":"176236897062360417","createdAt":"2022-07-12T07:19:13.028Z"}},{"order":{"signature":{"signatureType":2,"r":"0x623dd23a16b8fef784bbfafe6ed194be70bee3220106da0fa9c91b0095590c1f","s":"0x673678d92ace80dc8f22ad215bf9c03c22c9f14978daf82e2e8baa75292d2123","v":28},"sender":"0x0000000000000000000000000000000000000000","maker":"0x8836a16db8db1cba0890f0ee97a9926cb47b4101","taker":"0x0000000000000000000000000000000000000000","takerTokenFeeAmount":"100000000000000000","makerAmount":"46700000000000000000000","takerAmount":"10000000000000000000","makerToken":"0x134e62bd2ee247d4186a1fdbaa9e076cb26c1355","takerToken":"0x03582cb41f2fd982e1b531d633b6de049d56f2a0","salt":"1657609823092","verifyingContract":"0xdef1c0ded9bec7f1a1670819833240f027b25eff","feeRecipient":"0xbb0f479895915f80f6feb5babcb0ad39a0d7ef4e","expiry":"1658214623","chainId":3,"pool":"0x0000000000000000000000000000000000000000000000000000000000000000"},"metaData":{"orderHash":"0x9b65e4a1c24908d5e30373e643a3bfd1950754f1d4f477b3204b894c78b564f2","remainingFillableTakerAmount":"180010706421297471","createdAt":"2022-07-12T07:11:46.504Z"}},{"order":{"signature":{"signatureType":2,"r":"0xbe508aa9893f73c2e95e7fe8d22d2424b003550f3c884a8d7c547be6935d4e1a","s":"0x5e1c28ec5341bde124c5f55197b4d2801fa469e56fa8b4dd116d5cc0e2cb6c88","v":27},"sender":"0x0000000000000000000000000000000000000000","maker":"0x8836a16db8db1cba0890f0ee97a9926cb47b4101","taker":"0x0000000000000000000000000000000000000000","takerTokenFeeAmount":"100000000000000000","makerAmount":"46700000000000000000000","takerAmount":"10000000000000000000","makerToken":"0x134e62bd2ee247d4186a1fdbaa9e076cb26c1355","takerToken":"0x03582cb41f2fd982e1b531d633b6de049d56f2a0","salt":"1657609825510","verifyingContract":"0xdef1c0ded9bec7f1a1670819833240f027b25eff","feeRecipient":"0xbb0f479895915f80f6feb5babcb0ad39a0d7ef4e","expiry":"1658214625","chainId":3,"pool":"0x0000000000000000000000000000000000000000000000000000000000000000"},"metaData":{"orderHash":"0xeb2680de5b1d40f9ff0ef6e7ed41692d86f66150e877939508e161600e22d1f7","remainingFillableTakerAmount":"180010706421297471","createdAt":"2022-07-12T07:11:48.716Z"}}]}462616904978989909186790 (462'616.90497898990918679小数点)1500000000000000003 (小数点1.5000.03)88499999999999999997 (按十进制计算,c. 88.5 ),根据我的计算,假设有足够的制造商津贴,我认为这里就是这样的情况。remainingTakerFillableAmount:176236897062360417 (0.176.(以十进制计算)结果是,我只能填写第一个订单,而不能使用batchFillLimitOrders填写其他两个订单。
有人能解释为什么remainingTakerFillableAmount这么低吗?通常,当制造商津贴太低时,就会发生这种情况,但在这种情况下,显然有足够的制造商备抵。我是不是漏掉了什么,还是这是个窃听器?
我还在0xAPIGitHub回购中创建了一个问题:https://github.com/0xProject/0x-api/issues/885
发布于 2022-07-19 13:40:38
好的,我可以自己回答这个问题。remainingFillableTakerAmount显示低于预期的原因是用户在创建订单后花费了一些制造商令牌。也就是说,仅仅检查制造者备用金是不够的。还需要检查制造商的权杖余额。
当一些读者计划使用0x的orderbook api端点来构建订单簿(就像我们为app.diva.finance所做的那样)时,您必须考虑以下事实:如果用户创建了多个订单,并且在订单被创建并张贴到api服务器后制造商令牌余额或备抵量减少,0x将返回所有订单,但其中只有一个子集实际上是可填充的。或者换个说法,如果您尝试这样做,返回的订单将无法相互填充,从而导致错误。
为了克服这个问题,我们在前端实现了额外的逻辑,通过将remainingFillableMakerAmount (必须从remainingFillableTakerAmount、takerAmount和makerAmount派生)与制造商令牌允许/余额的最小值进行比较,筛选出不可填充的订单。查询给定一组制造商地址的最小允许/余额的最有效方法是使用平衡检查器合同 getMinOfBalancesOrAllowances函数。请注意,您可以传递给该函数的最大地址数是400-500。为了说明这个事实,建议实现一些批处理逻辑,以防ned有更多的maker地址。
希望这个花了我几天时间才弄明白的洞察力会对未来的读者有所帮助。
https://ethereum.stackexchange.com/questions/131989
复制相似问题