Um leitor vê no site da Dusk Trade um portfólio de ativos bem organizado e as taxas de retorno e pensa que isso é um acesso pronto para abrir conta e comprar diretamente; então prepara o capital para esperar a abertura. Quando, no site, aparecem waitlist e Launching soon, só então percebe que confundiu a prévia da interface com uma porta de entrada comercial. Este é um caso bem típico de leitura errada: os nomes dos ativos e os números de retorno exibidos na página do produto são apenas uma prévia e não representam ativos reais compráveis nem retornos realizados. A regra é distinguir duas coisas: a tabela de funcionalidades definida pela documentação e a entrada que está disponível atualmente na página. A documentação da Dusk Trade a define como uma camada de aplicação para um sistema de ativos financeiros tokenizados, abrangendo descoberta de ativos, elegibilidade do investidor, conexão da carteira, coordenação de pagamentos, ações de compra e venda e liquidação — ou seja, descreve o que ela planeja fazer. Já a página do produto, no momento, está parada em PRE-LAUNCH; a principal entrada é o waitlist — ela indica o que é possível fazer agora. O fato de o protocolo já estar em funcionamento não significa que cada camada do produto já esteja aberta: a rede subjacente é a rede subjacente, a entrada da aplicação é a entrada da aplicação, e a tabela de funcionalidades é um roadmap; o tipo de entrada é a situação atual.
O contraexemplo nos ensina: ao avaliar um produto que ainda está em construção, olhe primeiro o tipo de entrada e depois o escopo da tabela de funcionalidades; quando as duas colunas não se conectam, vale a entrada. Para o usuário, separar a avaliação entre a tabela de funcionalidades do produto e as entradas que realmente estão disponíveis — e então decidir se entra no waitlist — é muito mais confiável do que ficar adivinhando o momento apenas pelos números exibidos na prévia. Ainda mais: separar a tabela de funcionalidades do tipo de entrada ajuda o time a planejar o caminho de uso. O que dá para fazer agora depende de até que etapa a entrada esteja liberada; o que vai dar para fazer no futuro depende de até que etapa a tabela de funcionalidades avance. Assim, são duas linhas do tempo independentes, e não uma mistura dos números da página de prévia. Para determinar o timing de entrada, confie na mudança do tipo de entrada, mais do que em mirar na decoração da página.
@Dusk $DUSK #dusk
O contraexemplo nos ensina: ao avaliar um produto que ainda está em construção, olhe primeiro o tipo de entrada e depois o escopo da tabela de funcionalidades; quando as duas colunas não se conectam, vale a entrada. Para o usuário, separar a avaliação entre a tabela de funcionalidades do produto e as entradas que realmente estão disponíveis — e então decidir se entra no waitlist — é muito mais confiável do que ficar adivinhando o momento apenas pelos números exibidos na prévia. Ainda mais: separar a tabela de funcionalidades do tipo de entrada ajuda o time a planejar o caminho de uso. O que dá para fazer agora depende de até que etapa a entrada esteja liberada; o que vai dar para fazer no futuro depende de até que etapa a tabela de funcionalidades avance. Assim, são duas linhas do tempo independentes, e não uma mistura dos números da página de prévia. Para determinar o timing de entrada, confie na mudança do tipo de entrada, mais do que em mirar na decoração da página.
@Dusk $DUSK #dusk