Binance Square
某咯的健康
68 Publicações

某咯的健康

5 A seguir
36 Seguidores
26 Gostaram
Publicações
·
--
Ver tradução
机构钱包不是一个更大的个人钱包 个人可以用一把私钥决定所有操作,机构却有董事、交易员、合规、财务和审计等不同角色。谁能发起交易,谁能批准,谁只能查看,往往还要根据金额和资产类型变化。把个人钱包放大,并不能解决公司治理。 Dusk想承载受监管资产,隐私与选择性披露最终都要进入这种多人权限结构。DuskEVM上的应用不仅要连接钱包,还要知道当前签名代表什么组织角色,以及这项权限是否仍然有效。 如果交易员换岗,旧权限要撤销;大额交易可能需要多人确认;审计者可以查看证据,却不应拥有转移资产的权力。每项能力必须被拆开。 我会用一项可观察结果检验它“机构钱包不是一个更大的个人钱包”时,我会特别核对:我也会观察升级是否破坏旧合约和旧权限。熟悉工具降低的是进入成本,长期兼容与可审计变更才决定机构敢不敢把持续业务放上去。,最终看它是否真正改变用户决策。 因此我认为 @Dusk_Foundation 的机构采用,不能只看有多少钱包地址。$DUSK #dusk 更关键的指标是,一家公司能否把现实中的职责分离安全映射到链上。个人钱包解决“是不是我”,机构钱包还要解决“我代表谁、此刻能做什么”。
机构钱包不是一个更大的个人钱包

个人可以用一把私钥决定所有操作,机构却有董事、交易员、合规、财务和审计等不同角色。谁能发起交易,谁能批准,谁只能查看,往往还要根据金额和资产类型变化。把个人钱包放大,并不能解决公司治理。

Dusk想承载受监管资产,隐私与选择性披露最终都要进入这种多人权限结构。DuskEVM上的应用不仅要连接钱包,还要知道当前签名代表什么组织角色,以及这项权限是否仍然有效。

如果交易员换岗,旧权限要撤销;大额交易可能需要多人确认;审计者可以查看证据,却不应拥有转移资产的权力。每项能力必须被拆开。

我会用一项可观察结果检验它“机构钱包不是一个更大的个人钱包”时,我会特别核对:我也会观察升级是否破坏旧合约和旧权限。熟悉工具降低的是进入成本,长期兼容与可审计变更才决定机构敢不敢把持续业务放上去。,最终看它是否真正改变用户决策。

因此我认为 @Dusk 的机构采用,不能只看有多少钱包地址。$DUSK #dusk 更关键的指标是,一家公司能否把现实中的职责分离安全映射到链上。个人钱包解决“是不是我”,机构钱包还要解决“我代表谁、此刻能做什么”。
Ver tradução
节点看到的mempool,不是全网待处理交易清单 Dusk HTTP API文档特别说明,`mempoolTxs`返回的是当前节点本地内存池,并按Gas价格排序;它不是全网视图,也不包含暂存在prequeue里的未来nonce交易。这个边界会直接影响监控工具对“交易消失”的判断。 应用查询一个节点没有看到交易,可能是尚未传播、被另一节点接收,或因nonce较未来暂存在预队列。若立即提示用户重发,可能制造替换与重复意图。更稳妥的做法是结合交易哈希、发送节点、账户nonce与最终区块状态,给出带来源的判断。 对交易场所,内存池数据还不能直接当作全网拥堵或费用依据。一个节点的排序只说明其本地候选集,采样节点、时间窗口和prequeue排除都要写进指标定义。统计口径不清,仪表盘越精确越容易误导。 我看 @Dusk_Foundation 的开发文档,最喜欢这种主动限制API含义的句子。$DUSK #dusk 可靠的数据产品应先说自己看不见什么,再告诉用户它看见了什么,尤其不能用单节点缺失直接判断全网丢弃。
节点看到的mempool,不是全网待处理交易清单

Dusk HTTP API文档特别说明,`mempoolTxs`返回的是当前节点本地内存池,并按Gas价格排序;它不是全网视图,也不包含暂存在prequeue里的未来nonce交易。这个边界会直接影响监控工具对“交易消失”的判断。

应用查询一个节点没有看到交易,可能是尚未传播、被另一节点接收,或因nonce较未来暂存在预队列。若立即提示用户重发,可能制造替换与重复意图。更稳妥的做法是结合交易哈希、发送节点、账户nonce与最终区块状态,给出带来源的判断。

对交易场所,内存池数据还不能直接当作全网拥堵或费用依据。一个节点的排序只说明其本地候选集,采样节点、时间窗口和prequeue排除都要写进指标定义。统计口径不清,仪表盘越精确越容易误导。

我看 @Dusk 的开发文档,最喜欢这种主动限制API含义的句子。$DUSK #dusk 可靠的数据产品应先说自己看不见什么,再告诉用户它看见了什么,尤其不能用单节点缺失直接判断全网丢弃。
A mempool que o nó vê, não é uma lista completa de transações pendentes de toda a rede Aviso especial na documentação da API HTTP do Dusk: o `mempoolTxs` retorna a pool de memória local do nó atual, ordenada por preço de gás; não é uma visão de toda a rede e também não inclui transações futuras de nonce que estejam temporariamente na prequeue. Esse limite afeta diretamente a forma como as ferramentas de monitoramento julgam um “desaparecimento” de transações. Quando um aplicativo consulta um nó e não vê uma transação, pode ser porque ainda não foi propagada, porque foi recebida por outro nó, ou porque a transação com nonce mais à frente está temporariamente na fila de pré-processamento. Se você avisar o usuário para reenviar imediatamente, isso pode gerar intenção de substituição e duplicação. Uma abordagem mais segura é combinar hash da transação, nó de envio, nonce da conta e o estado final no bloco para fornecer uma avaliação com base em evidências. Quanto ao “mercado” de transações, os dados da mempool ainda não podem ser usados diretamente como base para determinar congestionamento ou taxas em toda a rede. A ordenação de um único nó apenas indica seu conjunto local de candidatos; deve-se incluir na definição das métricas a exclusão do prequeue, o nó amostrado e a janela de tempo. Se o critério estatístico não ficar claro, quanto mais “preciso” o painel parecer, mais fácil fica induzir o usuário ao erro. Eu li a documentação do desenvolvimento de @Dusk_Foundation e gostei especialmente dessas frases que limitam proativamente o significado da API. $DUSK #DUSKARMY. , produtos de dados confiáveis devem primeiro dizer o que não conseguem ver e só depois dizer o que eles conseguem ver — especialmente sem usar a ausência em um único nó para concluir que a rede inteira descartou.
A mempool que o nó vê, não é uma lista completa de transações pendentes de toda a rede

Aviso especial na documentação da API HTTP do Dusk: o `mempoolTxs` retorna a pool de memória local do nó atual, ordenada por preço de gás; não é uma visão de toda a rede e também não inclui transações futuras de nonce que estejam temporariamente na prequeue. Esse limite afeta diretamente a forma como as ferramentas de monitoramento julgam um “desaparecimento” de transações.

Quando um aplicativo consulta um nó e não vê uma transação, pode ser porque ainda não foi propagada, porque foi recebida por outro nó, ou porque a transação com nonce mais à frente está temporariamente na fila de pré-processamento. Se você avisar o usuário para reenviar imediatamente, isso pode gerar intenção de substituição e duplicação. Uma abordagem mais segura é combinar hash da transação, nó de envio, nonce da conta e o estado final no bloco para fornecer uma avaliação com base em evidências.

Quanto ao “mercado” de transações, os dados da mempool ainda não podem ser usados diretamente como base para determinar congestionamento ou taxas em toda a rede. A ordenação de um único nó apenas indica seu conjunto local de candidatos; deve-se incluir na definição das métricas a exclusão do prequeue, o nó amostrado e a janela de tempo. Se o critério estatístico não ficar claro, quanto mais “preciso” o painel parecer, mais fácil fica induzir o usuário ao erro.

Eu li a documentação do desenvolvimento de @Dusk e gostei especialmente dessas frases que limitam proativamente o significado da API. $DUSK #DUSKARMY. , produtos de dados confiáveis devem primeiro dizer o que não conseguem ver e só depois dizer o que eles conseguem ver — especialmente sem usar a ausência em um único nó para concluir que a rede inteira descartou.
Quando o usuário seleciona a rede errada, o produto deve bloqueá-la o quanto antes, e não esperar para só então exibir o erro depois de ele ter assinado O DuskEVM tem uma identidade de rede bem definida: a testnet tem o Chain ID 745, e outros ambientes têm IDs diferentes. Para desenvolvedores, isso é apenas um item de configuração; para usuários comuns, porém, é uma fonte de erro frequente. Ele pode estar, no segundo anterior, em outra cadeia EVM e, no segundo seguinte, clicar em Enviar dentro do app Dusk. A aparência do pop-up da carteira é quase a mesma. Um bom produto deve, ao ler a carteira, comparar o Chain ID imediatamente, colocar a página em um estado não interativo e informar claramente para qual rede o usuário será direcionado. Ele não deve primeiro deixar o usuário preencher o formulário, aprovar Token, assinar uma sequência de mensagens, e só no final usar “RPC Error” para dizer “a rede está incorreta”. Quanto mais cedo o erro for interrompido, menor é o custo. Testes mais detalhados incluem: o usuário recusar a troca de rede, a carteira não reconhecer a rede, alterar a conta durante a troca e a página ter em cache o saldo da conta anterior. O aplicativo precisa responder às mudanças de Network e Account da carteira, limpando de forma imediata cotações e credenciais antigas. Caso contrário, a página parece continuar, mas o negócio já trocou de pessoa. A Dusk Connect de @Dusk_Foundation vai encontrar carteiras compatíveis e perceber as mudanças de estado. $DUSK #dusk : no nível da aplicação, o que deve ser feito é transformar esses sinais em uma interação segura. Eu avalio se um produto Web3 é maduro, muitas vezes, observando como ele lida com situações em que o usuário não segue o script padrão.
Quando o usuário seleciona a rede errada, o produto deve bloqueá-la o quanto antes, e não esperar para só então exibir o erro depois de ele ter assinado

O DuskEVM tem uma identidade de rede bem definida: a testnet tem o Chain ID 745, e outros ambientes têm IDs diferentes. Para desenvolvedores, isso é apenas um item de configuração; para usuários comuns, porém, é uma fonte de erro frequente. Ele pode estar, no segundo anterior, em outra cadeia EVM e, no segundo seguinte, clicar em Enviar dentro do app Dusk. A aparência do pop-up da carteira é quase a mesma.

Um bom produto deve, ao ler a carteira, comparar o Chain ID imediatamente, colocar a página em um estado não interativo e informar claramente para qual rede o usuário será direcionado. Ele não deve primeiro deixar o usuário preencher o formulário, aprovar Token, assinar uma sequência de mensagens, e só no final usar “RPC Error” para dizer “a rede está incorreta”. Quanto mais cedo o erro for interrompido, menor é o custo.

Testes mais detalhados incluem: o usuário recusar a troca de rede, a carteira não reconhecer a rede, alterar a conta durante a troca e a página ter em cache o saldo da conta anterior. O aplicativo precisa responder às mudanças de Network e Account da carteira, limpando de forma imediata cotações e credenciais antigas. Caso contrário, a página parece continuar, mas o negócio já trocou de pessoa.

A Dusk Connect de @Dusk vai encontrar carteiras compatíveis e perceber as mudanças de estado. $DUSK #dusk : no nível da aplicação, o que deve ser feito é transformar esses sinais em uma interação segura. Eu avalio se um produto Web3 é maduro, muitas vezes, observando como ele lida com situações em que o usuário não segue o script padrão.
Ver tradução
套利者按先到先得购买Vault 对我来说,“套利者按先到先得购买Vault”不是一句标题,而是一道必须回答的产品题。Trustless Bitcoin Vaults (TBV) 给出的条件是:注册套利者通过swapWbtcForVault支付上限内WBTC,Ethereum侧采用先到先得。围绕“套利者按先到先得购买Vault”,我会把判断落到可复核的交易或状态,而不是沿用旧分类。 容易被忽略的是,拥有更好报价就一定获得Vault。真实后果则是排序机制会影响参与动力和抢跑成本。若“套利者按先到先得购买Vault”不能改变实际操作顺序,这段分析就还没有完成。 我的做法会是观察成交失败率与实际参与者数量,并把失败时停在哪一步一并记录。“套利者按先到先得购买Vault”的结论必须说明谁行动、何时生效,以及失败后停在哪里。@babylonlabs_io $BABY #baby ,不讨论价格,只讨论TBV。 我会特别保留“套利者按先到先得购买Vault”对应的原始状态和交易证据,因为排序机制会影响参与动力和抢跑成本,这正是结论能否成立的分水岭。
套利者按先到先得购买Vault

对我来说,“套利者按先到先得购买Vault”不是一句标题,而是一道必须回答的产品题。Trustless Bitcoin Vaults (TBV) 给出的条件是:注册套利者通过swapWbtcForVault支付上限内WBTC,Ethereum侧采用先到先得。围绕“套利者按先到先得购买Vault”,我会把判断落到可复核的交易或状态,而不是沿用旧分类。

容易被忽略的是,拥有更好报价就一定获得Vault。真实后果则是排序机制会影响参与动力和抢跑成本。若“套利者按先到先得购买Vault”不能改变实际操作顺序,这段分析就还没有完成。

我的做法会是观察成交失败率与实际参与者数量,并把失败时停在哪一步一并记录。“套利者按先到先得购买Vault”的结论必须说明谁行动、何时生效,以及失败后停在哪里。@BabylonLabs_io $BABY #baby ,不讨论价格,只讨论TBV。

我会特别保留“套利者按先到先得购买Vault”对应的原始状态和交易证据,因为排序机制会影响参与动力和抢跑成本,这正是结论能否成立的分水岭。
Ver tradução
Repay交易成功,只证明这次支付执行,不证明Position已经可退出 Ethereum返回Repay成功时,用户自然会认为债务阶段已经结束。Trustless Bitcoin Vaults (TBV) 仍需重新计算剩余本金、利息和健康状态;如果还款金额小于实际欠款,交易完全可能成功,同时Position继续保留债务。 成功回执回答的是“合约接受了这笔钱”,不是“全部债务已经关闭”。把交易状态当成业务状态,是跨链退出最常见的提前庆祝。 所以我会在每次Repay后读取新债务,而不是只保存绿色对勾。只有所有Reserve归零并允许withdraw,才进入下一阶段。应用成功事件必须与用户目标状态对应,关注 @babylonlabs_io ,$BABY ,#baby ;本文不讨论价格。 业务完成状态最好由合约读取,而不是前端根据本次支付金额推测。用户需要看到“剩余债务为零”这一结果,而非仅看到交易哈希。 同样,借款与清算后的状态也应重新读取。交易成功是技术事实,仓位达到目标才是用户事实。 这项确认应成为退出按钮前的硬门槛。
Repay交易成功,只证明这次支付执行,不证明Position已经可退出

Ethereum返回Repay成功时,用户自然会认为债务阶段已经结束。Trustless Bitcoin Vaults (TBV) 仍需重新计算剩余本金、利息和健康状态;如果还款金额小于实际欠款,交易完全可能成功,同时Position继续保留债务。

成功回执回答的是“合约接受了这笔钱”,不是“全部债务已经关闭”。把交易状态当成业务状态,是跨链退出最常见的提前庆祝。

所以我会在每次Repay后读取新债务,而不是只保存绿色对勾。只有所有Reserve归零并允许withdraw,才进入下一阶段。应用成功事件必须与用户目标状态对应,关注 @BabylonLabs_io $BABY #baby ;本文不讨论价格。

业务完成状态最好由合约读取,而不是前端根据本次支付金额推测。用户需要看到“剩余债务为零”这一结果,而非仅看到交易哈希。

同样,借款与清算后的状态也应重新读取。交易成功是技术事实,仓位达到目标才是用户事实。

这项确认应成为退出按钮前的硬门槛。
Ver tradução
BTCVaultSwap拥有独立WBTC Spoke 对长期持币者来说,BTCVaultSwap拥有独立WBTC Spoke不是技术炫技,而是能否安心退出的条件。在 Trustless Bitcoin Vaults (TBV) 中,“BTCVaultSwap拥有独立WBTC Spoke”决定的是一项具体权利。 问题不再是机制有没有,而是同一Hub下仍存在不同负债与风险边界;缺少执行数据,代码权限只能证明可能性。此外,即时结算需要LLP或AVK真实垫付资产与工作,函数入口不会创造流动性;本篇的核对点是“默认LLP不是Babylon Core Spoke里的普通余额”。 白纸黑字能确认的是默认LLP不是Babylon Core Spoke里的普通余额,它与它作为自己的Aave Hub Spoke调用WBTC流动性共同构成完整路径;单独截取一段会过度乐观。 结论不是谁绝对安全,而是执行上应做到:分别观察两个Spoke的利用率;把条件写进清单,才算读懂TBV;关注 @babylonlabs_io ,$BABY #baby 。
BTCVaultSwap拥有独立WBTC Spoke

对长期持币者来说,BTCVaultSwap拥有独立WBTC Spoke不是技术炫技,而是能否安心退出的条件。在 Trustless Bitcoin Vaults (TBV) 中,“BTCVaultSwap拥有独立WBTC Spoke”决定的是一项具体权利。

问题不再是机制有没有,而是同一Hub下仍存在不同负债与风险边界;缺少执行数据,代码权限只能证明可能性。此外,即时结算需要LLP或AVK真实垫付资产与工作,函数入口不会创造流动性;本篇的核对点是“默认LLP不是Babylon Core Spoke里的普通余额”。

白纸黑字能确认的是默认LLP不是Babylon Core Spoke里的普通余额,它与它作为自己的Aave Hub Spoke调用WBTC流动性共同构成完整路径;单独截取一段会过度乐观。

结论不是谁绝对安全,而是执行上应做到:分别观察两个Spoke的利用率;把条件写进清单,才算读懂TBV;关注 @BabylonLabs_io $BABY #baby
Ver tradução
还款授权留缓冲,不等于合约会多扣走那部分资产 Aave债务在交易等待确认时持续计息,官方流程建议授权略高于页面显示余额。Trustless Bitcoin Vaults (TBV) 用户可能担心多授权就会多支付,实际上应区分ERC-20 spending cap与最终合约实际扣款:缓冲用于覆盖新增利息,未使用部分仍留在钱包。 这里的产品风险是界面把“授权上限”和“预计支付”混成一个数字。授权太低会留下债务尘埃,授权过大又增加长期approve暴露。最合理的设计应在还款完成后提示剩余授权并允许撤销。 把宣传数字改成链上状态后,BTC抵押成立后,借款仍受Hub资产、Spoke额度、Oracle和利率曲线约束,不能用锁仓量代替可借深度。容量使用率必须配合独立主体和地址集中度,否则压力测试与广泛采用会被写成同一个结论。 对此可以核对交易前债务、实际扣款、交易后余额和剩余allowance。完整还款不仅要债务归零,也要让用户知道还留下什么权限。关注 @babylonlabs_io ,项目代币 $BABY ;本文不谈价格。#baby
还款授权留缓冲,不等于合约会多扣走那部分资产

Aave债务在交易等待确认时持续计息,官方流程建议授权略高于页面显示余额。Trustless Bitcoin Vaults (TBV) 用户可能担心多授权就会多支付,实际上应区分ERC-20 spending cap与最终合约实际扣款:缓冲用于覆盖新增利息,未使用部分仍留在钱包。

这里的产品风险是界面把“授权上限”和“预计支付”混成一个数字。授权太低会留下债务尘埃,授权过大又增加长期approve暴露。最合理的设计应在还款完成后提示剩余授权并允许撤销。

把宣传数字改成链上状态后,BTC抵押成立后,借款仍受Hub资产、Spoke额度、Oracle和利率曲线约束,不能用锁仓量代替可借深度。容量使用率必须配合独立主体和地址集中度,否则压力测试与广泛采用会被写成同一个结论。

对此可以核对交易前债务、实际扣款、交易后余额和剩余allowance。完整还款不仅要债务归零,也要让用户知道还留下什么权限。关注 @BabylonLabs_io ,项目代币 $BABY ;本文不谈价格。#baby
Ver tradução
12个区块只是第一段等待:执行账 重新整理Babylon资料后,我更相信细节而不是口号。 Trustless Bitcoin Vaults (TBV) 让原生BTC无需包装、跨桥或托管即可抵押。普通用户更需要知道下一步怎么做:统计单位是一笔Pre-PegIn交易从广播到激活的状态迁移。 机制显示,当前测试网要求12个signet确认,ACK约24小时超时,激活约48小时超时,之后还有3天退款时间锁。确认、参与者ACK、用户揭示秘密和最终PegIn广播是不同状态;某一步成功不能替代下一步。我会把机制翻译成创建、持仓和退出三次检查。 我认为最需要警惕的是:用户把链上确认当激活完成,可能错过揭示窗口或误判资金卡住。因此,与其只看浏览量、创建数或某个醒目的总额,不如要求一个能改变决策的指标——分别记录确认耗时、ACK耗时、激活成功率与Expired占比。能减少一次操作误判,比热闹叙事更有用。 从执行账落实到行动,我会按状态名排查问题,并在创建前确认退款地址和恢复方式。债务归零、异常自救与原生BTC到账才是闭环。关注 @babylonlabs_io ,项目代币为 $BABY ;只讨论TBV机制,不讨论价格。#baby
12个区块只是第一段等待:执行账

重新整理Babylon资料后,我更相信细节而不是口号。 Trustless Bitcoin Vaults (TBV) 让原生BTC无需包装、跨桥或托管即可抵押。普通用户更需要知道下一步怎么做:统计单位是一笔Pre-PegIn交易从广播到激活的状态迁移。

机制显示,当前测试网要求12个signet确认,ACK约24小时超时,激活约48小时超时,之后还有3天退款时间锁。确认、参与者ACK、用户揭示秘密和最终PegIn广播是不同状态;某一步成功不能替代下一步。我会把机制翻译成创建、持仓和退出三次检查。

我认为最需要警惕的是:用户把链上确认当激活完成,可能错过揭示窗口或误判资金卡住。因此,与其只看浏览量、创建数或某个醒目的总额,不如要求一个能改变决策的指标——分别记录确认耗时、ACK耗时、激活成功率与Expired占比。能减少一次操作误判,比热闹叙事更有用。

从执行账落实到行动,我会按状态名排查问题,并在创建前确认退款地址和恢复方式。债务归零、异常自救与原生BTC到账才是闭环。关注 @BabylonLabs_io ,项目代币为 $BABY ;只讨论TBV机制,不讨论价格。#baby
Os arquivos WOTS pertencem ao direito de resgate (exit right), não a um anexo comum para download Após criar Trustless Bitcoin Vaults (TBV), o usuário pode obter o par de chaves WOTS e os artefatos do claimer. Muitas pessoas tratam esses itens como “anexos” que podem ser ignorados depois do download, mas se o Provider ficar inacessível, esses materiais podem ser a chave para o usuário fazer a retirada por conta própria. Assim, a gestão de arquivos afeta diretamente os direitos patrimoniais. Ter apenas um único computador aumenta o risco de perda; misturar vários arquivos de Vault pode causar erros correspondentes; e deixar textos em claro em armazenamento na nuvem pode expor conteúdos sensíveis. Vou criar um índice offline, registrando o Vault ID, a data de criação, o endereço de destino e a localização do backup. Manter pelo menos cópias criptografadas, e verificar a recuperação em um ambiente de testes de ativos. Backup não é “quanto mais, melhor”, e sim: o suficiente para encontrar, conseguir descriptografar e usar corretamente. O protocolo entrega o direito de resgate ao usuário e também atribui ao usuário a responsabilidade pela recuperação. @babylonlabs_io $BABY #baby No que diz respeito aos “arquivos WOTS”, os direitos que o usuário realmente possui devem ser demonstráveis pelo estado on-chain e por transações executáveis; apenas promessas documentais sem uma porta de operação ainda não são suficientes para eu ficar tranquilo. A minimização de permissões também precisa equilibrar a capacidade de recuperação: ninguém deve conseguir mover BTC sem autorização, e também não se pode permitir que a saída legítima fique permanentemente travada apenas porque todos não têm permissão para tratar. Por fim, eu aceito essa fronteira testando o caminho de resgate no pior cenário: um depósito bem-sucedido não prova que os ativos estarão sempre sob controle do usuário.
Os arquivos WOTS pertencem ao direito de resgate (exit right), não a um anexo comum para download

Após criar Trustless Bitcoin Vaults (TBV), o usuário pode obter o par de chaves WOTS e os artefatos do claimer. Muitas pessoas tratam esses itens como “anexos” que podem ser ignorados depois do download, mas se o Provider ficar inacessível, esses materiais podem ser a chave para o usuário fazer a retirada por conta própria.

Assim, a gestão de arquivos afeta diretamente os direitos patrimoniais. Ter apenas um único computador aumenta o risco de perda; misturar vários arquivos de Vault pode causar erros correspondentes; e deixar textos em claro em armazenamento na nuvem pode expor conteúdos sensíveis.

Vou criar um índice offline, registrando o Vault ID, a data de criação, o endereço de destino e a localização do backup. Manter pelo menos cópias criptografadas, e verificar a recuperação em um ambiente de testes de ativos. Backup não é “quanto mais, melhor”, e sim: o suficiente para encontrar, conseguir descriptografar e usar corretamente.

O protocolo entrega o direito de resgate ao usuário e também atribui ao usuário a responsabilidade pela recuperação. @BabylonLabs_io $BABY #baby

No que diz respeito aos “arquivos WOTS”, os direitos que o usuário realmente possui devem ser demonstráveis pelo estado on-chain e por transações executáveis; apenas promessas documentais sem uma porta de operação ainda não são suficientes para eu ficar tranquilo. A minimização de permissões também precisa equilibrar a capacidade de recuperação: ninguém deve conseguir mover BTC sem autorização, e também não se pode permitir que a saída legítima fique permanentemente travada apenas porque todos não têm permissão para tratar. Por fim, eu aceito essa fronteira testando o caminho de resgate no pior cenário: um depósito bem-sucedido não prova que os ativos estarão sempre sob controle do usuário.
Ver tradução
合作预告不是产品入口 Aegis固定利率、GoMining BTC来源和Ledger设备集成,为Trustless Bitcoin Vaults (TBV) 提供了不同方向。但“计划合作”与“用户今天可以点击使用”必须分开。 一项合作至少要经过接口开发、测试、风险配置、正式部署和用户转化。若官方明确写着预计时间或受测试影响,文章就不能省略这些限定。 我会在标题里直接写清“计划”“测试”或“已开放”,不靠结尾补免责声明。状态词放得越早,读者越不容易把路线图当成交付。 判断合作是否落地,我会寻找可点击入口、正式文档、合约地址与第一批完成数据。没有用户路径的新闻稿只能进入观察清单,不能进入现成功能清单。 所以我的行动仍然是小额测试、完整退出、保存证据,再决定是否提高信任。任何缺少退出验证的成功截图,都只是半条链路。 这项结论还要用公开交易、页面状态和官方文档交叉验证。任意一处无法对应,我都会把它降级为待确认问题,而不是用确定语气补齐证据。 @babylonlabs_io $BABY #baby
合作预告不是产品入口

Aegis固定利率、GoMining BTC来源和Ledger设备集成,为Trustless Bitcoin Vaults (TBV) 提供了不同方向。但“计划合作”与“用户今天可以点击使用”必须分开。

一项合作至少要经过接口开发、测试、风险配置、正式部署和用户转化。若官方明确写着预计时间或受测试影响,文章就不能省略这些限定。

我会在标题里直接写清“计划”“测试”或“已开放”,不靠结尾补免责声明。状态词放得越早,读者越不容易把路线图当成交付。

判断合作是否落地,我会寻找可点击入口、正式文档、合约地址与第一批完成数据。没有用户路径的新闻稿只能进入观察清单,不能进入现成功能清单。

所以我的行动仍然是小额测试、完整退出、保存证据,再决定是否提高信任。任何缺少退出验证的成功截图,都只是半条链路。

这项结论还要用公开交易、页面状态和官方文档交叉验证。任意一处无法对应,我都会把它降级为待确认问题,而不是用确定语气补齐证据。

@BabylonLabs_io $BABY #baby
Ver tradução
Aave Position Proxy:我原先理解错了什么 围绕“Aave Position Proxy”,有两句话看起来都对:TBV确实提供了新能力;但“每个用户独立代理就能隔离所有风险”并不能由此推出。 官方流程显示,@babylonlabs_io $BABY #baby 的 Trustless Bitcoin Vaults (TBV) 采用的办法是:首次存入会为地址部署独立Position Proxy,多个金库可共同支持该头寸。落到用户身上,结果是个人会计被隔离,但适配器、Spoke、预言机和治理仍共享。 所以我不会把能力写成保证。账户隔离不等于系统风险隔离,仍然是使用前必须接受的条件。 这直接改变我的选择:我会分开评估个人状态与公共组件。能把优势和限制同时变成行动,才算真正读懂“Aave Position Proxy”。 谈到“Aave Position Proxy”,我也不会把测试成功理解为主网保证,真正要复核的是压力环境下“Aave Position Proxy”是否仍按同一规则执行。 这也是我判断TBV是否成熟的一条小标准:优势可以一句话讲完,限制也必须让用户在操作前看见。
Aave Position Proxy:我原先理解错了什么

围绕“Aave Position Proxy”,有两句话看起来都对:TBV确实提供了新能力;但“每个用户独立代理就能隔离所有风险”并不能由此推出。

官方流程显示,@BabylonLabs_io $BABY #baby 的 Trustless Bitcoin Vaults (TBV) 采用的办法是:首次存入会为地址部署独立Position Proxy,多个金库可共同支持该头寸。落到用户身上,结果是个人会计被隔离,但适配器、Spoke、预言机和治理仍共享。

所以我不会把能力写成保证。账户隔离不等于系统风险隔离,仍然是使用前必须接受的条件。

这直接改变我的选择:我会分开评估个人状态与公共组件。能把优势和限制同时变成行动,才算真正读懂“Aave Position Proxy”。

谈到“Aave Position Proxy”,我也不会把测试成功理解为主网保证,真正要复核的是压力环境下“Aave Position Proxy”是否仍按同一规则执行。 这也是我判断TBV是否成熟的一条小标准:优势可以一句话讲完,限制也必须让用户在操作前看见。
Simular o USDC com o mesmo nome do USDC real; a identidade do contrato é mais importante do que o símbolo O USDC, USDT e WBTC da testnet não têm valor real; com nomes idênticos, é fácil levar os usuários a confundi-los. Os Trustless Bitcoin Vaults (TBV) associados a @babylonlabs_io $BABY #baby devem verificar os ativos pelo protocolo de rede e pelo endereço do contrato, e não apenas pelo símbolo. Tokens de terceiros com o mesmo nome, saldos em rede incorreta e carteiras que não exibem ativos personalizados podem causar interpretações erradas como “já caiu” ou “o saldo sumiu”. Produtos de testnet devem destacar claramente as características: fora da rede principal, por meio do contrato e sem valor. Vou usar a taxa de seleção de ativos incorretos como um indicador de qualidade de entrada, porque, na mainnet, uma confusão semelhante uma vez pode se transformar em uma perda real. Para entender “Simular o USDC com o mesmo nome do USDC real; a identidade do contrato é mais importante do que o símbolo”, é preciso enxergar tanto do lado do protocolo quanto do lado do usuário: o protocolo se preocupa com se o estado é válido; o usuário se preocupa se o próprio BTC ainda está sob controle. Se eu fosse fazer testes públicos, eu recomendaria registrar de forma consistente os preços dos ativos de dívida, a liquidez de mercado, os canais de reembolso, mudanças de taxa de juros e cenários de desancoragem — assim os resultados de usuários diferentes podem ser comparados, em vez de ficar apenas “deu certo” ou “travou”. Os resultados em testnet são mais adequados para descobrir problemas de fluxo; não substituem auditoria, implementação de governança e validação sob pressão de participantes reais da economia. Eu prefiro tirar menos um grande veredito e manter mais uma evidência verificável. Para garantias cross-chain, verificabilidade é mais importante do que “barulho”. Em torno de “Simular o USDC com o mesmo nome do USDC real; a identidade do contrato é mais importante do que o símbolo”, eu também dividirei as conclusões em três camadas: já verificadas, inferíveis de forma razoável e ainda a confirmar com dados oficiais ou on-chain, evitando que leitores confundam um resultado de teste com uma garantia de longo prazo. Essa distinção parece cautelosa, mas preserva valor para revisão mesmo quando os parâmetros forem atualizados.
Simular o USDC com o mesmo nome do USDC real; a identidade do contrato é mais importante do que o símbolo

O USDC, USDT e WBTC da testnet não têm valor real; com nomes idênticos, é fácil levar os usuários a confundi-los.

Os Trustless Bitcoin Vaults (TBV) associados a @BabylonLabs_io $BABY #baby devem verificar os ativos pelo protocolo de rede e pelo endereço do contrato, e não apenas pelo símbolo. Tokens de terceiros com o mesmo nome, saldos em rede incorreta e carteiras que não exibem ativos personalizados podem causar interpretações erradas como “já caiu” ou “o saldo sumiu”.

Produtos de testnet devem destacar claramente as características: fora da rede principal, por meio do contrato e sem valor. Vou usar a taxa de seleção de ativos incorretos como um indicador de qualidade de entrada, porque, na mainnet, uma confusão semelhante uma vez pode se transformar em uma perda real.

Para entender “Simular o USDC com o mesmo nome do USDC real; a identidade do contrato é mais importante do que o símbolo”, é preciso enxergar tanto do lado do protocolo quanto do lado do usuário: o protocolo se preocupa com se o estado é válido; o usuário se preocupa se o próprio BTC ainda está sob controle. Se eu fosse fazer testes públicos, eu recomendaria registrar de forma consistente os preços dos ativos de dívida, a liquidez de mercado, os canais de reembolso, mudanças de taxa de juros e cenários de desancoragem — assim os resultados de usuários diferentes podem ser comparados, em vez de ficar apenas “deu certo” ou “travou”. Os resultados em testnet são mais adequados para descobrir problemas de fluxo; não substituem auditoria, implementação de governança e validação sob pressão de participantes reais da economia. Eu prefiro tirar menos um grande veredito e manter mais uma evidência verificável. Para garantias cross-chain, verificabilidade é mais importante do que “barulho”.

Em torno de “Simular o USDC com o mesmo nome do USDC real; a identidade do contrato é mais importante do que o símbolo”, eu também dividirei as conclusões em três camadas: já verificadas, inferíveis de forma razoável e ainda a confirmar com dados oficiais ou on-chain, evitando que leitores confundam um resultado de teste com uma garantia de longo prazo. Essa distinção parece cautelosa, mas preserva valor para revisão mesmo quando os parâmetros forem atualizados.
Se você olhar apenas o TVL, pode haver uma interpretação equivocada do TBV Quanto BTC é “travado” é o dado mais intuitivo, mas isso não consegue, por si só, comprovar que os produtos de empréstimo são úteis. O Trustless Bitcoin Vaults (TBV) de @babylonlabs_io inclui tanto um cofre de Bitcoin quanto se conecta a empréstimos do Aave v4. Um TVL alto pode vir de poucos grandes investidores fazendo depósitos iniciais; o uso real do produto precisa ser avaliado pelo valor emprestado, pela taxa de utilização, pela taxa de “repagamento/renovação” (repborrow), pela taxa de resgate regular e pela concentração. O TVL também pode ser ampliado por alguns endereços de grande porte. Com o total sendo o mesmo, a diferença de risco e significado do produto entre cem usuários independentes e uma única instituição parceira é completamente diferente; o primeiro prova a existência de entrada e demanda, enquanto o segundo prova mais a capacidade do sistema. A concentração precisa ser observada junto com o total. Eu prefiro construir um funil: quantas pessoas criam, ativam, tomam empréstimos, pagam de volta, resgatam e voltam a usar—e então complementar com a concentração dos cofres e a retenção no período sem incentivos. O TVL é o “estoque”; o ciclo completo de comportamentos é a “demanda”. Se houver apenas travamento sem empréstimo e sem reutilização, o protocolo ainda não prova que a eficiência de capital, de fato, é necessária pelos usuários. $BABY #baby
Se você olhar apenas o TVL, pode haver uma interpretação equivocada do TBV

Quanto BTC é “travado” é o dado mais intuitivo, mas isso não consegue, por si só, comprovar que os produtos de empréstimo são úteis.

O Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io inclui tanto um cofre de Bitcoin quanto se conecta a empréstimos do Aave v4. Um TVL alto pode vir de poucos grandes investidores fazendo depósitos iniciais; o uso real do produto precisa ser avaliado pelo valor emprestado, pela taxa de utilização, pela taxa de “repagamento/renovação” (repborrow), pela taxa de resgate regular e pela concentração.

O TVL também pode ser ampliado por alguns endereços de grande porte. Com o total sendo o mesmo, a diferença de risco e significado do produto entre cem usuários independentes e uma única instituição parceira é completamente diferente; o primeiro prova a existência de entrada e demanda, enquanto o segundo prova mais a capacidade do sistema. A concentração precisa ser observada junto com o total.

Eu prefiro construir um funil: quantas pessoas criam, ativam, tomam empréstimos, pagam de volta, resgatam e voltam a usar—e então complementar com a concentração dos cofres e a retenção no período sem incentivos. O TVL é o “estoque”; o ciclo completo de comportamentos é a “demanda”. Se houver apenas travamento sem empréstimo e sem reutilização, o protocolo ainda não prova que a eficiência de capital, de fato, é necessária pelos usuários. $BABY #baby
Eu usei um Comitê de Segurança 3/5 apenas como apoio temporário e recalculei as contas do TBV O Comitê de Segurança 3/5, embora pareça apenas um parâmetro, altera diretamente o cronograma, os custos ou o método de saída de um empréstimo. Nas Trustless Bitcoin Vaults (TBV) <t-2/> @babylonlabs_io $BABY #baby , o comitê de segurança na rede de testes tem 5 chaves, e 3 assinaturas já permitem uma interrupção de emergência ou uma pausa. Isso significa que o comitê não consegue transferir BTC para qualquer endereço, mas consegue impedir pagamentos específicos. O valor aqui não está no tamanho do número, e sim no fato de que, após uma falha, ainda existe um estado claramente definido. Para o tomador do empréstimo, esse desenho acaba se refletindo no limite, no tempo de espera ou na forma de lidar com o principal. Ao calcular o valor do produto, não basta colocar no lado dos benefícios “sem taxa de empacotamento, sem custódia centralizada”; é preciso também colocar no lado dos custos a granularidade de espera, reconstrução e liquidação, além da responsabilidade pela recuperação. O maior desconto que eu apliquei a essa conta é: ele reduz perdas em falhas extremas e, ao mesmo tempo, preserva a dependência de governança necessária para sair. Quanto mais suave for o caminho normal, menos é possível pular a ordem de tratamento em um estado de pressão. Eu listei as contagens de ações do comitê, as razões e os marcos de aposentadoria como o primeiro item para a próxima revisão. Portanto, minha escolha agora é posicionar primeiro com base nesse desenho de limites, em vez de operar pela capacidade máxima indicada na página.
Eu usei um Comitê de Segurança 3/5 apenas como apoio temporário e recalculei as contas do TBV

O Comitê de Segurança 3/5, embora pareça apenas um parâmetro, altera diretamente o cronograma, os custos ou o método de saída de um empréstimo.

Nas Trustless Bitcoin Vaults (TBV) <t-2/> @BabylonLabs_io $BABY #baby , o comitê de segurança na rede de testes tem 5 chaves, e 3 assinaturas já permitem uma interrupção de emergência ou uma pausa. Isso significa que o comitê não consegue transferir BTC para qualquer endereço, mas consegue impedir pagamentos específicos. O valor aqui não está no tamanho do número, e sim no fato de que, após uma falha, ainda existe um estado claramente definido. Para o tomador do empréstimo, esse desenho acaba se refletindo no limite, no tempo de espera ou na forma de lidar com o principal.

Ao calcular o valor do produto, não basta colocar no lado dos benefícios “sem taxa de empacotamento, sem custódia centralizada”; é preciso também colocar no lado dos custos a granularidade de espera, reconstrução e liquidação, além da responsabilidade pela recuperação.

O maior desconto que eu apliquei a essa conta é: ele reduz perdas em falhas extremas e, ao mesmo tempo, preserva a dependência de governança necessária para sair. Quanto mais suave for o caminho normal, menos é possível pular a ordem de tratamento em um estado de pressão. Eu listei as contagens de ações do comitê, as razões e os marcos de aposentadoria como o primeiro item para a próxima revisão.

Portanto, minha escolha agora é posicionar primeiro com base nesse desenho de limites, em vez de operar pela capacidade máxima indicada na página.
Traduza o status do link externo para Bitcoin; só verifico esta cadeia de causalidade Ao estudar as Trustless Bitcoin Vaults (TBV) do bloco @babylonlabs_io , eu tenho gostado cada vez menos de uma página inteira listando jargões técnicos. Para decidir se faz sentido traduzir o status do link externo para Bitcoin, na verdade basta seguir uma cadeia de causalidade: onde os ativos estão, como o estado é reconhecido por aplicações externas, quais condições mudam o controle e, por fim, como o usuário sai. Nessa cadeia, o fato-chave já divulgado é: o TBV usa provas criptográficas para converter o estado de contratos inteligentes externos em condições que podem ser verificadas por um script do Bitcoin. Portanto, o ponto não é fazer o Bitcoin executar contratos Ethereum, mas fazê-lo aceitar apenas resultados que tenham sido provados. Não é transferir BTC secretamente para outra cadeia, nem é fazer com que o Ethereum, de repente, tenha controle sobre Bitcoin; é conectar estados verificáveis a condições de execução previamente acordadas. O limite que realmente precisa de auditoria é: o sistema de provas, a sincronização do estado e a latência de verificação ainda são dependências que precisam ser observadas. Se essa parte ficar ambígua, então nem mesmo uma descrição cheia de “sem custódia” adiantará. Pelo contrário, enquanto o limite estiver bem definido, as exceções puderem ser reproduzidas e a saída puder ser verificada, até mecanismos complexos podem ser entendidos por usuários comuns. A partir de agora, vou acompanhar apenas a taxa de falha das provas, a latência do estado e o tempo para tratamento de exceções. Um artigo que explica um objeto de verificação com clareza vale mais do que repetir dez vezes “infraestrutura BTCFi”. $BABY #baby
Traduza o status do link externo para Bitcoin; só verifico esta cadeia de causalidade

Ao estudar as Trustless Bitcoin Vaults (TBV) do bloco @BabylonLabs_io , eu tenho gostado cada vez menos de uma página inteira listando jargões técnicos. Para decidir se faz sentido traduzir o status do link externo para Bitcoin, na verdade basta seguir uma cadeia de causalidade: onde os ativos estão, como o estado é reconhecido por aplicações externas, quais condições mudam o controle e, por fim, como o usuário sai.

Nessa cadeia, o fato-chave já divulgado é: o TBV usa provas criptográficas para converter o estado de contratos inteligentes externos em condições que podem ser verificadas por um script do Bitcoin. Portanto, o ponto não é fazer o Bitcoin executar contratos Ethereum, mas fazê-lo aceitar apenas resultados que tenham sido provados. Não é transferir BTC secretamente para outra cadeia, nem é fazer com que o Ethereum, de repente, tenha controle sobre Bitcoin; é conectar estados verificáveis a condições de execução previamente acordadas.

O limite que realmente precisa de auditoria é: o sistema de provas, a sincronização do estado e a latência de verificação ainda são dependências que precisam ser observadas. Se essa parte ficar ambígua, então nem mesmo uma descrição cheia de “sem custódia” adiantará. Pelo contrário, enquanto o limite estiver bem definido, as exceções puderem ser reproduzidas e a saída puder ser verificada, até mecanismos complexos podem ser entendidos por usuários comuns.

A partir de agora, vou acompanhar apenas a taxa de falha das provas, a latência do estado e o tempo para tratamento de exceções. Um artigo que explica um objeto de verificação com clareza vale mais do que repetir dez vezes “infraestrutura BTCFi”. $BABY #baby
Eu vou interromper o processo de propósito uma vez Concluir o teste sem incidentes só valida o caminho ideal. Usuários reais podem fechar a página, trocar de dispositivo, desconectar a carteira ou até esquecer de continuar a operação dentro do prazo. Se o sistema consegue se recuperar a partir de um estado de interrupção muitas vezes é mais importante do que conseguir uma primeira vez. A criação de um cofre Trustless Bitcoin Vaults (TBV) envolve confirmação de Bitcoin, configuração dos participantes e ativação na Ethereum. Se o fluxo ficar parado antes da ativação, o design do protocolo inclui um mecanismo de timeout e um caminho de reembolso do lado do Bitcoin para evitar que o BTC fique preso permanentemente. Vou interromper de propósito uma vez na testnet: registrar em que estado o cofre está no momento da interrupção, verificar se, ao reconectar, a página consegue identificar isso e se, após o tempo excedido, a mensagem de reembolso fica clara. Os tokens de teste não têm valor, o que é perfeito para esse tipo de experimento que, na mainnet, ninguém faria com facilidade. A confiabilidade de um protocolo não se reflete apenas no botão de sucesso, mas também em saber se o usuário consegue voltar quando comete um erro. Você acha que o tutorial oficial deveria incluir exercícios de falha, ou é melhor manter o caminho mais curto para o sucesso? @babylonlabs_io $BABY #baby
Eu vou interromper o processo de propósito uma vez

Concluir o teste sem incidentes só valida o caminho ideal. Usuários reais podem fechar a página, trocar de dispositivo, desconectar a carteira ou até esquecer de continuar a operação dentro do prazo. Se o sistema consegue se recuperar a partir de um estado de interrupção muitas vezes é mais importante do que conseguir uma primeira vez.

A criação de um cofre Trustless Bitcoin Vaults (TBV) envolve confirmação de Bitcoin, configuração dos participantes e ativação na Ethereum. Se o fluxo ficar parado antes da ativação, o design do protocolo inclui um mecanismo de timeout e um caminho de reembolso do lado do Bitcoin para evitar que o BTC fique preso permanentemente.

Vou interromper de propósito uma vez na testnet: registrar em que estado o cofre está no momento da interrupção, verificar se, ao reconectar, a página consegue identificar isso e se, após o tempo excedido, a mensagem de reembolso fica clara. Os tokens de teste não têm valor, o que é perfeito para esse tipo de experimento que, na mainnet, ninguém faria com facilidade.

A confiabilidade de um protocolo não se reflete apenas no botão de sucesso, mas também em saber se o usuário consegue voltar quando comete um erro. Você acha que o tutorial oficial deveria incluir exercícios de falha, ou é melhor manter o caminho mais curto para o sucesso?

@BabylonLabs_io $BABY #baby
#grvt @grvt_io A transparência dos dados da GRVT merece elogios: a plataforma divulga de forma pública dados centrais do mercado, como negociações e profundidade. Assim, os traders podem analisar o cenário do mercado de maneira independente. Há muitos outros traders no setor cujas plataformas têm dados pouco claros e pouco transparentes; um ambiente de dados claro e verificável ajuda os traders a formularem de modo racional as próprias estratégias de negociação.#grvt
#grvt @grvt_io A transparência dos dados da GRVT merece elogios: a plataforma divulga de forma pública dados centrais do mercado, como negociações e profundidade. Assim, os traders podem analisar o cenário do mercado de maneira independente. Há muitos outros traders no setor cujas plataformas têm dados pouco claros e pouco transparentes; um ambiente de dados claro e verificável ajuda os traders a formularem de modo racional as próprias estratégias de negociação.#grvt
Ver tradução
#grvt GRVT积极参与全球各类加密行业峰会,项目代表时常出席海外金融论坛,@grvt_io 会同步分享参会带来的行业资源与合作动向。借助线下峰会的交流机会,团队可以接触传统金融行业的投资方、做市商以及金融科技企业,不断向外输出自身零信任衍生品的项目理念,让更多传统金融从业者了解区块链衍生品全新的发展模式,源源不断的外部资源持续赋能项目发展,#grvt 借助线下渠道拓宽自身行业影响力。
#grvt GRVT积极参与全球各类加密行业峰会,项目代表时常出席海外金融论坛,@grvt_io 会同步分享参会带来的行业资源与合作动向。借助线下峰会的交流机会,团队可以接触传统金融行业的投资方、做市商以及金融科技企业,不断向外输出自身零信任衍生品的项目理念,让更多传统金融从业者了解区块链衍生品全新的发展模式,源源不断的外部资源持续赋能项目发展,#grvt 借助线下渠道拓宽自身行业影响力。
#grvt Com o aumento cada vez mais acentuado da arbitragem maliciosa MEV, a privacidade das transações tornou-se uma necessidade imediata no mercado cripto. @grvt_io , apoiado na tecnologia de conhecimento zero, cria um ambiente nativo de privacidade para transações, no qual os dados de ordens e posições não são expostos no pool de memória público, eliminando desde a base as transações de corrida (front-running) e a arbitragem de liquidação maliciosa. #grvt mira este vasto mar de oportunidades de trilhões no setor financeiro on-chain orientado à privacidade, separa dois processos — correspondência de ordens e liquidação on-chain — e trata apenas as informações sensíveis da transação com criptografia off-chain. Por fim, apenas por meio de provas ZK, realiza-se o reconhecimento e a liquidação na rede principal Ethereum. Assim, mantém-se a transparência rastreável da blockchain, ao mesmo tempo que se protege a privacidade das estratégias dos traders, capturando com precisão a lacuna de mercado no segmento de DEX que ainda não foi suficientemente explorada. #grvt
#grvt Com o aumento cada vez mais acentuado da arbitragem maliciosa MEV, a privacidade das transações tornou-se uma necessidade imediata no mercado cripto. @grvt_io , apoiado na tecnologia de conhecimento zero, cria um ambiente nativo de privacidade para transações, no qual os dados de ordens e posições não são expostos no pool de memória público, eliminando desde a base as transações de corrida (front-running) e a arbitragem de liquidação maliciosa. #grvt mira este vasto mar de oportunidades de trilhões no setor financeiro on-chain orientado à privacidade, separa dois processos — correspondência de ordens e liquidação on-chain — e trata apenas as informações sensíveis da transação com criptografia off-chain. Por fim, apenas por meio de provas ZK, realiza-se o reconhecimento e a liquidação na rede principal Ethereum. Assim, mantém-se a transparência rastreável da blockchain, ao mesmo tempo que se protege a privacidade das estratégias dos traders, capturando com precisão a lacuna de mercado no segmento de DEX que ainda não foi suficientemente explorada. #grvt
Inicia sessão para explorar mais conteúdos
Junta-te a utilizadores de criptomoedas de todo o mundo na Binance Square
⚡️ Obtém informações úteis e recentes sobre criptomoedas.
💬 Com a confiança da maior exchange de criptomoedas do mundo.
👍 Descobre perspetivas reais de criadores verificados.
E-mail/Número de telefone
Mapa do sítio
Preferências de cookies
Termos e Condições da Plataforma