Na mais recente tabela de parâmetros da rede de testes pública, vi três valores iguais de 0,4 BTC. Ao comparar, descobri que os objetos por eles limitados não são os mesmos. Um cofre individual, no máximo, 0,4 BTC; dentro de uma única posição de empréstimo, a soma de todos os cofres também, no máximo, 0,4 BTC; e o limite de exposição do Aave para o mesmo endereço continua sendo 0,4 BTC. Números iguais, mas três regras que não podem se substituir entre si.
Um nível acima, o CapPolicy define um limite total de 10 BTC para o aplicativo do Aave e faz uma verificação quando um cofre é ativado. Dividindo 10 por 0,4, teoricamente dá para acomodar até 25 endereços “com o limite individual cheio”. Esses 25 são apenas uma conversão de capacidade, não uma estimativa do número de usuários; alguém pode colocar apenas 0,1 BTC, permitindo mais endereços, mas o total ativado acumulado ainda não pode ultrapassar 10 BTC.
Fácil de entender errado é interpretar “meu limite não foi excedido” como “desta vez certamente dá para ativar”. Suponha que o aplicativo já tenha 9,8 BTC; um novo usuário pretende ativar 0,4 BTC. O limite individual estaria dentro do adequado, mas o total do aplicativo passaria para 10,2 BTC, não passando na verificação de capacidade. Da mesma forma, mesmo que o aplicativo ainda tenha espaço, se um endereço já tiver 0,3 BTC, ele não pode adicionar mais 0,2 BTC. O limite individual e o limite global precisam ser atendidos ao mesmo tempo. Por isso, como o front-end avisa sobre insuficiência de capacidade é, por si só, parte do controle de risco; caso contrário, é muito fácil para o usuário interpretar indevidamente a interrupção das regras como falha da carteira ou da rede.
@BabylonLabs_io atualmente lista isso como configuração de Bitcoin Signet e rede de testes de Ethereum, não devendo ser extrapolado como parâmetro permanente da mainnet. Acho que o foco não é “quanto dá para travar”, e sim controlar separadamente a exposição de cada usuário e o risco total do aplicativo. Usuários comuns na sequência devem observar se o front-end exibe, ao mesmo tempo, (1) o saldo restante do usuário individual, (2) a capacidade restante do aplicativo, e (3) o caminho de reembolso quando a ativação não for concluída.$BABY a infraestrutura relacionada precisa ser ampliada; antes disso, é necessário evitar que os usuários interpretem “a conta tem limite” como “o aplicativo ainda tem capacidade”.
#baby
Um nível acima, o CapPolicy define um limite total de 10 BTC para o aplicativo do Aave e faz uma verificação quando um cofre é ativado. Dividindo 10 por 0,4, teoricamente dá para acomodar até 25 endereços “com o limite individual cheio”. Esses 25 são apenas uma conversão de capacidade, não uma estimativa do número de usuários; alguém pode colocar apenas 0,1 BTC, permitindo mais endereços, mas o total ativado acumulado ainda não pode ultrapassar 10 BTC.
Fácil de entender errado é interpretar “meu limite não foi excedido” como “desta vez certamente dá para ativar”. Suponha que o aplicativo já tenha 9,8 BTC; um novo usuário pretende ativar 0,4 BTC. O limite individual estaria dentro do adequado, mas o total do aplicativo passaria para 10,2 BTC, não passando na verificação de capacidade. Da mesma forma, mesmo que o aplicativo ainda tenha espaço, se um endereço já tiver 0,3 BTC, ele não pode adicionar mais 0,2 BTC. O limite individual e o limite global precisam ser atendidos ao mesmo tempo. Por isso, como o front-end avisa sobre insuficiência de capacidade é, por si só, parte do controle de risco; caso contrário, é muito fácil para o usuário interpretar indevidamente a interrupção das regras como falha da carteira ou da rede.
@BabylonLabs_io atualmente lista isso como configuração de Bitcoin Signet e rede de testes de Ethereum, não devendo ser extrapolado como parâmetro permanente da mainnet. Acho que o foco não é “quanto dá para travar”, e sim controlar separadamente a exposição de cada usuário e o risco total do aplicativo. Usuários comuns na sequência devem observar se o front-end exibe, ao mesmo tempo, (1) o saldo restante do usuário individual, (2) a capacidade restante do aplicativo, e (3) o caminho de reembolso quando a ativação não for concluída.$BABY a infraestrutura relacionada precisa ser ampliada; antes disso, é necessário evitar que os usuários interpretem “a conta tem limite” como “o aplicativo ainda tem capacidade”.
#baby