DeepBook Token (DEEP)

A promessa em questão

Este dossiê examina uma única questão: o que o registro documental de fato estabelece sobre o DeepBook Token, aqui identificado como DEEP na rede Sui, antes que qualquer pontuação possa ser atribuída. O objeto está fixado a uma única string de contrato documental, 0xdeeb7a4662eec9f2f3def03fb937a663dddaa2e215b8078a284d026b7946c270::deep::DEEP, e à identidade deep-wallet-sui. Essa string identifica apenas o objeto documentado. Ela não confirma que o programa correspondente esteja atualmente implantado, quem o controla, ou como a rede opera atualmente.

O propósito declarado deste teste de estresse é restrito. Examinamos o que os resumos originais fornecidos descrevem, nomeamos as versões exatas e os limites históricos desses resumos, e separamos alegações documentais de observação operacional. Tudo abaixo é ou um fato baseado em fonte, uma incógnita declarada, ou uma interpretação editorial, e cada seção marca qual é qual.

O que os documentos estabelecem

Um registro é um catálogo informacional, não uma sondagem ao vivo de uma blockchain. O README do Trust Wallet Assets descreve um registro de informações e logotipos de tokens mantido pela comunidade em diversas blockchains, usado por essa carteira e por outros projetos. Ele afirma que informações adicionais de tokens são opcionais e indisponíveis on-chain, que qualquer pessoa pode enviar ativos, e que a inclusão não implica uma parceria direta com os projetos listados. Ele também exclui explicitamente tokens recém-criados dos envios, de modo que o registro não pode servir como inventário exaustivo de lançamentos recentes. Seus scripts e documentação usam a licença MIT. Este é o registro de integração do próprio projeto da carteira, preenchido por envios da comunidade, portanto suas descrições são alegações documentais e não declarações de emissor verificadas de forma independente nem observações operacionais.

Dentro desse registro, o registro de integração Sui fixado nomeia DeepBook com o símbolo DEEP, o identificador documental 0xdeeb7a4662eec9f2f3def03fb937a663dddaa2e215b8078a284d026b7946c270::deep::DEEP, e 6 casas decimais. Casas decimais descrevem como os valores são representados e não estabelecem nada sobre oferta ou valor atuais. A entrada está rotulada como SUI e ativa, onde ativa é um rótulo de status de metadados e não uma validação de rede ao vivo. O contexto de diretório Sui que hospeda esse registro nomeia Sui, o que estabelece apenas contexto de diretório documental.

O mesmo registro fixado carrega uma descrição mantida pela comunidade: DeepBook é apresentado como um livro de ofertas centralizado descentralizado, ou CLOB, construído sobre Sui. Um CLOB é um modelo de exchange em que ordens de compra e venda são registradas em uma lista ordenada e casadas por prioridade de preço e tempo, em oposição a um pool que precifica negociações por uma fórmula. A descrição ainda alega que o projeto aproveita a execução paralela da Sui e taxas de transação baixas para trazer uma exchange de alto desempenho e baixa latência on-chain. Cada elemento de projeto, parceria, subsídio, economia, desempenho, oferta, data e adoção dessa descrição é uma alegação de registro atribuída, e nada disso foi verificado com um emissor ou por meio de operação. O rótulo de diretório não estabelece uma implantação em mainnet, uma implementação funcional, ou direitos presentes do token.

O que permanece desconhecido

Nenhuma observação de rede ao vivo foi realizada para este dossiê. A correspondência documental de endereço não estabelece comportamento atual do programa, controle implantado ou segurança. Os critérios avaliados de identidade, uso, papel do token, oferta, concentração, captura de valor, controle, segurança, governança, responsabilidade, incidentes, continuidade e execução permanecem todos desconhecidos, sem nenhuma observação independente admitida de critério neste lote documental. Controle independente presente, propriedade beneficiária, uso, adoção por clientes, oferta, concentração, liquidez e histórico completo de incidentes permanecem, portanto, não verificados.

Este registro também reflete um projeto com 0% de cobertura de pontuação e um status calculado não avaliado; não há admissão pública de qualquer deficiência, e nenhuma é implicada. Cobertura é uma medida de quanto de evidência aplicável foi admitida e revisada de forma independente. Em 0%, uma pontuação não pode ser calculada. Os critérios essenciais ausentes de identidade, oferta e controle impedem um total mesmo se houvesse evidência parcial, o que não é o caso.

Por que isso importa

A distinção entre um registro documental e um fato operacional não é pedantismo. Uma entrada de registro pode ser precisa como metadado e ainda assim não dizer nada sobre se um contrato executa como descrito, quem detém autoridade de atualização ou emissão, ou se o token tem algum papel econômico ao vivo. Tratar uma correspondência documental como prova de comportamento implantado importaria alegações que as fontes nunca fizeram. Assim, a consequência prática é que um leitor não pode partir deste dossiê para qualquer conclusão sobre comportamento real da rede ou resultados de investimento, porque nenhuma fonte aqui sustenta esse passo.

A nota de escopo do Trust Wallet é clara ao afirmar que a inclusão não implica parceria, que informações de tokens são opcionais e indisponíveis on-chain, e que descrições são alegações documentais da comunidade. Somado a um registro fixado mas datado, isso significa que até mesmo a promessa básica de uma exchange on-chain é atualmente uma alegação que aguarda reprodução independente, não um fato estabelecido.

Veredito

O DeepBook Token permanece não avaliado com 0% de cobertura de pontuação, com base apenas em material documental. A pilha documental é real e internamente atribuída, mas a força operacional do objeto é não comprovada. Esta é uma afirmação honesta sobre o lote de evidências presente, não um julgamento da qualidade do projeto. Nenhuma alegação de incidente, auditoria, propriedade ou desempenho é feita aqui, e nenhuma deve ser lida nas entrelinhas.

O que mudaria isso

Três passos concretos moveriam este dossiê além da camada documental. Primeiro, reproduzir as verificações de identidade: confirmar de forma independente a string de contrato contra o bytecode implantado e os endereços de controle atuais em sui:mainnet, e registrar observações datadas. Segundo, reunir evidência específica de critério para os essenciais ausentes, a saber, identidade, oferta e controle, além dos demais critérios desconhecidos, como governança, incidentes e continuidade. Terceiro, submeter a evidência resultante à calibração e revisão editorial para que qualquer pontuação seja calculada, versionada e defensável.

Questões privadas de pesquisa de catálogo decorrem disso: quem controla atualmente o programa documentado; se a implementação de CLOB referenciada está ao vivo e em uso; quais são os direitos reais do token, se houver; e o que contém um registro de incidentes completo e datado. Até que essas questões sejam respondidas com evidência admissível, o status não avaliado permanece.