AlexGo AuditLaunchpad, Cofre de rendimento e pool de reequilíbrio de garantia – CoinFabrik Blog

Introdução

A CoinFabrik foi solicitada a auditar os contratos do projeto AlexGo. Primeiro vamos
fornecer um resumo de nossas descobertas e, em seguida, mostraremos os detalhes de nossas
descobertas.

Alcance

Os contratos auditados são do https://github.com/alexgo-io/alex-v1 git
repositório. A auditoria é baseada no commit
e268fd53370be3a271625bd45523ae07cb1239ac.

Os contratos auditados são:

● clarity/contracts/pool/alex-launchpad-v1-1.clar: Plataforma de lançamento
contrato para criação de IDO.
● clarity/contracts/pool/collateral-rebalancing-pool.clar:
Contrato para criação de pool de tokens de garantia.
● clarity/contracts/pool/yield-vault-alex.clar: Cofre para rendimento
fichas.

O escopo da auditoria é limitado a esses arquivos. Nenhum outro arquivo neste repositório foi
auditado. Supõe-se que suas dependências funcionem de acordo com sua documentação.
Além disso, nenhum teste foi revisado para esta auditoria.

Análises

Sem se limitar a eles, o processo de auditoria incluiu as seguintes análises:

● Erros aritméticos
● Condições de corrida
● Uso indevido de carimbos de data/hora de bloqueio
● Ataques de negação de serviço
● Uso excessivo de gás
● Código desnecessariamente complexo e interações de contrato
● Tratamento de erros deficiente ou inexistente
● Validação insuficiente dos parâmetros de entrada
● Centralização e capacidade de atualização
● Autenticação fraca

Resumo das Constatações

Encontramos um problema médio e um problema menor. Além disso, duas melhorias foram
proposto.
Os dois problemas foram reconhecidos.

Problemas de segurança

Funções privilegiadas

Essas são as funções privilegiadas que identificamos em cada um dos contratos auditados.

alex-launchpad-v1-1

Proprietário

O proprietário é a única função que pode criar pools de tickets, necessários para iniciar um IDO. Isto
também é capaz de fornecer bilhetes para uma piscina, ligando para o reclamante e reembolsando
funcionar sem esperar o término do período de carência e transferir todo o
saldo de um token específico para o proprietário.

Operador Aprovado

Essa função também pode fornecer ingressos para um pool e ligar para a reivindicação e o reembolso
funções sem esperar que o período de carência termine.

Proprietário IDO

Os proprietários de IDO podem adicionar ingressos ao seu pool e ligar para a reivindicação e reembolso
funções sem esperar que o período de carência termine.

Problemas de segurança encontrados

Classificação de gravidade

Os riscos de segurança são classificados da seguinte forma:

● Críticos: são problemas que conseguimos explorar. Eles comprometem a
sistema a sério. Eles devem ser corrigidos imediatamente.
● Médio: esses são problemas potencialmente exploráveis. Mesmo que não tivéssemos
conseguem explorá-los ou seu impacto não é claro, eles podem representar um
risco de segurança em um futuro próximo. Sugerimos corrigi-los o mais rápido possível.
● Menor: esses problemas representam problemas relativamente pequenos ou difíceis
aproveitar, mas pode ser explorado em combinação com outras questões.
Esses tipos de problemas não bloqueiam implantações em ambientes de produção.
Eles devem ser levados em consideração e corrigidos sempre que possível.

Status dos problemas

Um problema detectado por esta auditoria pode ter quatro status distintos:

● Não resolvido: O problema não foi resolvido.
● Reconhecido: o problema permanece no código, mas é resultado de uma ação intencional
decisão.
● Resolvido: Implementação ajustada do programa para eliminar o risco.
● Parcialmente resolvido: Implementação ajustada do programa para eliminar parte do
risco. A outra parte permanece no código, mas é resultado de uma ação intencional
decisão.
● Mitigado: Ações implementadas para minimizar o impacto ou a probabilidade do
risco.

Problemas críticos de gravidade

Nenhum problema encontrado.

Problemas de gravidade média

ME-01 Launchpad: Distribuição total não garantida

Localização:

● clarity/contracts/pool/alex-launchpad-v1-1.clar:258-287

A aleatoriedade do Launchpad depende da movimentação de posições ao longo de uma cadeia de tickets, onde
a distância de cada passo é determinada por um gerador de números aleatórios, e para
cada posição em que parar, esse bilhete é determinado como vencedor. Cada aleatório
número é o resultado de um módulo de número maior um max_step predefinido. Esse
valor predefinido é geral para cada IDO e sua fórmula (simplificada para este
explicação) é:

Onde registrado é o número de ingressos registrados no IDO pelos jogadores,
e vencedores é a quantidade de bilhetes vencedores que a distribuição pode ter.

Como consequência, a distribuição completa só é garantida quando

número de registro da fórmula

Porque max_step results em um ou menos de um e, portanto, todos os jogadores ganham.

Por outro lado, se essa relação não for satisfeita, menos tickets podem ser distribuídos.
Como um exemplo claro, se houvesse apenas um bilhete vencedor disponível e apenas um
ticket registrado, max_step seria igual a 1,5. O jogador ganharia se o
posição após o passo cair entre 0 e 1. Portanto, este jogador tem uma probabilidade
de ganhar de apenas 66,67% em um IDO single-player.

Recomendação

Se houver ingressos restantes, uma nova rodada precisa ser iniciada, com o max_step
valor ajustado a este valor.

Status

Reconhecido. A recomendação será incorporada nas seguintes IDOs.

Problemas de gravidade menores

MI-01 Launchpad: Tokens bloqueados devido à distribuição incompleta

Localização:

● clarity/contracts/pool/alex-launchpad-v1-1.clar:258-287

Caso os tokens não sejam distribuídos devido ao problema descrito na ME-01, eles serão
ser bloqueado no contrato, a menos que o proprietário do contrato ligue
transfer-all-to-owner(), que transferirá os tokens de volta para o proprietário.

Recomendação

Se o ME-01 permanecer sem solução, o proprietário da IDO poderá extrair esses tokens.

Status

Reconhecido. A equipe de desenvolvimento considerou as condições desta edição
dificilmente ficará satisfeito.

Melhorias

Esses itens não representam um risco de segurança. São as melhores práticas que nós
sugerir implementação.

Tabela

Detalhes

EN-01 Launchpad: Declarações desnecessárias

Localização:

● clarity/contracts/pool/alex-launchpad-v1-1.clar:269,353

A semente VRF de um bloco pode ser retirada de um bloco já minerado, um bloco passado. A semente
utilizado para os IDOs é do bloco após o término do registro. No entanto, o
asserções nas linhas 269 e 353 cheques
enquanto também pode falhar porque a semente não pode ser obtida se a altura atual do bloco estiver em
final do registro ou o bloco depois dele.

Além disso, a asserção em Claim-process() nunca falhará porque
get-last-claim-walk-position() é chamado antes e será revertido se a semente for
não disponível.

Status

Não implementado. As correções correspondentes estão planejadas para serem implementadas no
iterações seguintes.

EN-02 Yield Vault: Resposta enganosa

Localização:

● clarity/contracts/pool/yield-vault-alex.clar:161

Se ativado for igual a falso, a resposta será (ok verdadeiro), mesmo quando apenas o
as recompensas são reivindicadas e não são apostadas.

Status

Não implementado. As correções correspondentes estão planejadas para serem implementadas no
iterações seguintes.

outras considerações

As considerações apresentadas nesta seção não são certas ou erradas. não sugerimos
qualquer ação para corrigi-los. Mas consideramos que podem ser de interesse para outros
partes interessadas do projeto, incluindo usuários dos contratos auditados, proprietários ou
investidores do projeto.

Centralização

As funções de reivindicação e reembolso do Launchpad são públicas e não têm
restrições a serem acionadas pelos usuários, quando decorrido um período de carência. No entanto, o
funções de reivindicação requerem uma lista de vencedores ordenados em sequência como entrada. Como um
consequência, se a tarefa off-chain não puder ser executada, os usuários precisarão descobrir o
seqüência e pagar o custo de, pelo menos, a reclamação de cada usuário antes deles.
As funções de reembolso precisam que a função de reivindicação seja chamada antes porque
o reembolso só está disponível quando for confirmado na cadeia que o bilhete não é um vencedor
bilhete.
Além disso, o proprietário do contrato da plataforma de lançamento pode transferir todos os tokens no contrato
Saldo.

Registro de alterações

● 08-04-2022 – Relatório inicial baseado em confirmação
e268fd53370be3a271625bd45523ae07cb1239ac.
● 19-04-2022 – Relatório final com base no feedback fornecido pelo desenvolvimento
equipe.

Isenção de responsabilidade: Este relatório de auditoria não é uma garantia de segurança, conselho de investimento ou
aprovação do projeto AlexGo, pois a CoinFabrik não revisou sua plataforma.
Além disso, ele não fornece uma garantia de ausência de falhas de código de contrato inteligente.