Análise de Dados On-Chain com Dune SQL: Comportamento Web3

Growth marketers e analistas de produto vivem caindo no mesmo erro: avaliar a base de usuários de um dApp pelo saldo das carteiras (olhando só para TVL ou Balance). Dá de cara com um endereço com 50 ETH e já joga o cara no segmento de usuário de alto valor. Isso é um erro sistêmico de análise.

Em analytics Web3, o saldo atual é secundário. O que manda é a fonte de financiamento inicial (Funding Source). Uma análise de comportamento de verdade (User Behavior Analytics) só começa mapeando e quebrando o anonimato das conexões entre as carteiras. Se o seu protocolo teve um pico do nada de 1.000 novos endereços, e o tracking mostra que todos eles ganharam o primeiro gás da mesma subconta de uma grande corretora ou via smart contract de mixer, tudo isso dentro de uma janela minúscula de tempo, esquece. Não é crescimento orgânico. É uma fazenda de Sybil (sybil farm) industrial sugando liquidez ou farmando atividade para um airdrop futuro.

Para pegar esses padrões, a gente analisa o "gênesis" da wallet: o timestamp da primeiríssima transação, a carteira que mandou os fundos e o rastro dos transfers seguintes.

Query SQL prática para o Dune (Dune SQL)

Este script isola as wallets que interagiram com o seu smart contract e busca a primeira transação da história de cada uma delas na rede. Com isso, dá para agrupar os usuários na hora pelo tipo de "doador".

-- Rastreia a fonte original de gás das carteiras que interagiram com o contrato
WITH target_users AS (
    SELECT DISTINCT "from" AS user_address
    FROM ethereum.transactions
    WHERE "to" = c'0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640' -- Exemplo: pool da Uniswap v3 USDC/WETH
    LIMIT 500
),
genesis_transactions AS (
    SELECT 
        t."to" AS user_address,
        t."from" AS funder,
        t.block_time,
        ROW_NUMBER() OVER (PARTITION BY t."to" ORDER BY t.block_time ASC) as rank_index
    FROM ethereum.transactions t
    JOIN target_users u ON t."to" = u.user_address
)
-- Mata todas as transações, deixando só a primeira da história de cada wallet
SELECT 
    g.user_address,
    g.funder AS parent_address,
    g.block_time AS creation_timestamp,
    -- Flagga funders suspeitos. Os endereços abaixo são exemplos de grandes mixers/bridges
    CASE 
        WHEN g.funder = c'0x12d66748a9176f0af33dfc592215a425441047f1' THEN 'Tornado.Cash (0.1 ETH)'
        WHEN g.funder = c'0x47ce0c6ed5b0ce3d3a51fdb1c52dc66a7c3c2936' THEN 'Tornado.Cash (1.0 ETH)'
        ELSE 'CEX Sub-account / Standard EOA'
    END AS funder_classification
FROM genesis_transactions g
WHERE g.rank_index = 1
ORDER BY g.block_time DESC;
-- Query pesada devido ao JOIN na tabela cheia de transactions. Para datasets gigantes, use partições por block_date.

Segmentação de base: Janela de decisão e dinâmica de gás

A análise comportamental divide os usuários em categorias claras com base na disciplina deles on-chain. Fazer pesquisa ou survey direto aqui não roda. Usuários mentem, a chain não.

Uma das métricas mais ignoradas, mas que mais dão insights para segmentação, é o Approve-to-Swap Latency (o delay entre dar o approve do token e rodar o swap de fato).

O usuário retail comum opera via interfaces padrão (MetaMask, Rabby). Entre a chamada da função approve() e o envio do swap(), ele gasta de 15 segundos a alguns minutos. Ele olha o slippage, pensa na vida ou se distrai. Já scripts automatizados e bots de MEV assinam essas transações de forma atômica. Elas entram ou no mesmo bloco ou dentro do mesmo bundle do Flashbots. Se o delta de tempo entre o approve e o transfer zerar, pode marcar a carteira como bot.

Análise comparativa de padrões on-chain

Análise de retenção por coorte (Cohort Retention) via Dune SQL

Para descobrir se o seu produto tem Product-Market Fit (PMF) real ou se você está só queimando verba de marketing trazendo usuário que interage uma vez e some, a saída é o cohort analysis. Precisamos rastrear o comportamento de quem converteu em um mês específico ao longo dos períodos seguintes.

No Dune SQL, fazemos isso usando window functions e calculando o intervalo de datas via DATE_DIFF.

-- Calcula a retenção mensal de usuários para um smart contract específico
WITH user_activity AS (
    SELECT 
        "from" AS user_address,
        DATE_TRUNC('month', block_time) AS tx_month,
        MIN(DATE_TRUNC('month', block_time)) OVER (PARTITION BY "from") AS cohort_month
    FROM ethereum.transactions
    WHERE "to" = c'0xdac17f958d2ee523a2206206994597c13d831ec7' -- Exemplo: contrato da USDT
),
cohort_volumes AS (
    -- Trava o tamanho inicial de cada coorte
    SELECT 
        cohort_month,
        COUNT(DISTINCT user_address) AS cohort_size
    FROM user_activity
    GROUP BY 1
),
retention_summary AS (
    -- Conta os usuários únicos que voltaram por mês
    SELECT 
        a.cohort_month,
        DATE_DIFF('month', a.cohort_month, a.tx_month) AS period_index,
        COUNT(DISTINCT a.user_address) AS active_users_count
    FROM user_activity a
    GROUP BY 1, 2
)
-- Monta a matriz final de resultados
SELECT 
    r.cohort_month,
    c.cohort_size,
    r.period_index AS months_after_first_tx,
    r.active_users_count,
    ROUND(CAST(r.active_users_count AS DOUBLE) / c.cohort_size * 100, 2) AS retention_percentage
FROM retention_summary r
JOIN cohort_volumes c ON r.cohort_month = c.cohort_month
WHERE r.period_index >= 0
ORDER BY r.cohort_month ASC, r.period_index ASC;
-- Alerta vermelho: se a retention_percentage no segundo mês (period_index = 1) ficar abaixo de 7%, seu produto tem um problema sério para reter a base.

Só um ponto de atenção aqui. Se o contrato for de infraestrutura core (tipo a USDT do exemplo), as coortes ficam brutas. A query pode estourar o timeout nos tiers gratuitos do Dune. Para um dApp normal, o código roda em segundos.

Eventos ocultos: Como extrair gatilhos profundos dos logs do sistema

A maioria dos analistas se limita a destrinchar as tabelas transactions ou traces. Isso deixa um oceano de dados de fora. Análise profissional exige mergulhar direto nos logs do sistema (ethereum.logs).

Por que isso importa? Vários protocolos atuais rodam com meta-transactions e Account Abstraction (ERC-4337). Nessa arquitetura, o campo tx.from vai apontar sempre para o endereço do relayer (o bundler que empacota as transações), e nunca para o usuário final. Se tentar analisar pelas transações comuns, você vai ver o rastro de três ou quatro contratos gigantes em vez de milhares de usuários únicos.

A saída é extrair as infos direto dos Events. Dá para parsear, por exemplo, o Topic 0 filtrando pelo hash do UserOperationEvent. Com isso, você descobre se o cara usa uma smart contract wallet (Safe, Argent), se assina as transações via hardware wallet ou se interage com o dApp usando as embedded wallets de bots do Telegram. Entender a arquitetura das wallets da sua base muda o jogo do UX: para o varejo que usa smart accounts, você não precisa explicar o que é gás. É só subir contratos de paymaster e deixar eles pagarem as taxas direto em stablecoins.

Tracking de liquidez ponta a ponta: identificando padrões de LP Drain

Sempre que um projeto lança uma campanha de liquidez (Liquidity Mining), chove provedor de liquidez (LP). O problema é que a maior parte dessa TVL é capital mercenário. Os yield farmers mofam no pool só enquanto o APY turbinado estiver rendendo. Assim que os incentivos caem, eles sacam tudo instantaneamente, derretendo a profundidade de mercado.

Para estruturar um sistema de alerta precoce, não basta monitorar o saque da liquidez em si. É preciso rastrear para onde esses fundos vão na sequência. Dinheiro inteligente (smart money) e varejo se comportam de formas completamente diferentes na hora de realizar lucro.

• Endereços de Varejo: Sacam os tokens de LP -> Swappam para stablecoins ou gas nativo (ETH) -> Enviam para exchanges centralizadas (CEX) usando endereços de depósito padrão.
• Arbitradores e Bots de MEV: Removem a liquidez -> Rotacionam na mesma hora para um pool similar de outro protocolo para cavar 0.5% a mais de APY -> Executam tudo em um ou dois blocos.
• Pools Institucionais: Movem os fundos para contratos multisig ou protocolos de lending não custodial (Aave, Maker). Em vez de vender direto, usam os ativos como colateral em loops de empréstimo.

Escrevendo uma query SQL avançada para trackear a migração de LPs

Abaixo, uma query para isolar carteiras que removeram liquidez do pool (evento Burn) e verificar onde esses tokens bateram nas 24 horas seguintes.

-- Comportamento dos LPs pós-saque de fundos
WITH lp_burns AS (
    SELECT 
        evt_tx_hash,
        evt_block_time AS burn_time,
        provider AS user_address,
        amount0 / 1e6 AS amount_usdc, -- Token0 considerado como USDC
        amount1 / 1e18 AS amount_weth  -- Token1 considerado como WETH
    FROM uniswap_v3_ethereum.Pair_evt_Burn
    WHERE contract_address = c'0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640' -- Pool alvo
      AND evt_block_time > CURRENT_DATE - INTERVAL '30' DAY
),
subsequent_txs AS (
    SELECT 
        b.user_address,
        b.burn_time,
        t.block_time AS tx_time,
        t."to" AS destination_address,
        ROW_NUMBER() OVER (PARTITION BY b.user_address, b.evt_tx_hash ORDER BY t.block_time ASC) as tx_order
    FROM lp_burns b
    JOIN ethereum.transactions t 
        ON t."from" = b.user_address 
        AND t.block_time > b.burn_time 
        AND t.block_time <= b.burn_time + INTERVAL '24' HOUR
)
-- Pega a primeiríssima ação do user após sair do pool
SELECT 
    s.user_address,
    s.burn_time,
    s.tx_time,
    s.destination_address,
    -- Tentando identificar o destino do fluxo
    CASE 
        WHEN s.destination_address = c'0x3cd751e6b0078be393132286c442345e5dc49699' THEN 'Binance Deposit'
        WHEN s.destination_address = c'0x4675c7e5baafbfc4687441c22105873cd246be3a' THEN 'Hop Protocol Bridge'
        WHEN s.destination_address = c'0x7a250d5630b4cf539739df2c5dacb4c659f2488d' THEN 'Uniswap V2 Router'
        ELSE 'Unknown EOA / Other Protocol'
    END AS next_action_destination
FROM subsequent_txs s
WHERE s.tx_order = 1
ORDER BY s.burn_time DESC;
-- Olho no edge case: se o user mandou várias txs no mesmo segundo (bundle), o particionamento por tx_order pode dar ruim.

Análise de "Fluxo Tóxico" (Toxic Flow) e o impacto nas métricas de produto

Para uma DEX ou protocolo DeFi, auditar a qualidade do volume de negociação é questão de sobrevivência. O fluxo on-chain se divide em volume orgânico (usuários reais trocando ativos por utilidade própria) e fluxo tóxico (arbitragem, LVR - Loss Versus Rebalancing).

O volume tóxico vem de bots que rapelam o valor dos LPs passivos quando rola uma oscilação forte de preço em ambientes externos (como na Binance). Se o analista bate o olho no pico de volume do dApp e corre reportar tração e crescimento orgânico, grandes chances de estar moscando. Muitas vezes, o oráculo do protocolo só está defasado, e os arbitradores estão ordenhando os pools.

Como caçar um endereço tóxico via SQL?

Monitoramos o PnL das transações em uma janela de 5 blocos após a execução. Se um endereço faz um swap e, nos próximos 5 blocos, o preço do ativo varia contra o pool e a favor da carteira que operou, é arbitragem pura.

Carteiras com mais de 80% do seu volume total atrelados a esse tipo de fluxo devem ser marcadas como Arbitrage_Bot no banco de dados analítico. Na hora de calcular a retenção real (Retention), esse volume precisa ser totalmente expurgado das estatísticas. Caso contrário, as métricas de engajamento do produto vão ficar completamente distorcidas.

Arquitetura de dashboard analítico: dos logs brutos aos insights de produto

Análise on-chain profissional em ambiente de produção não vive de queries ad-hoc rodadas na mão. Na prática, dados brutos são agregados em tabelas customizadas (as chamadas Spells na nomenclatura do Dune), atualizadas via cron de forma automatizada.

Abaixo está o desenho de uma pipeline de dados validada para análise de produto Web3:

[Dados Brutos On-Chain (Blocks, Transactions, Logs)]
                      │
                      ▼
[Contratos Decodificados (Events & Calls)] ──► Limpeza de ruído do sistema e txs crashadas (reverted)
                      │
                      ▼
[Lógica de Negócio (Tabelas Spells: Swaps, Deposits)] ──► Filtragem por latência de Approve-to-Swap
                      │
                      ▼
[Coortes Comportamentais (Dashboard Final)] ──► Métricas de Produto (LTV, CAC, Retention)

Diretriz final para o analista

Esqueça frameworks Web2 para avaliar produtos Web3. Wallets ativas exclusivas (UAW) e volume bruto de transações são métricas triviais de inflar via ataques Sybil gastando merrecas de gas. A análise comportamental real mora na genealogia financeira das carteiras (origem do gas), no delta de tempo entre chamadas de baixo nível do sistema e no rastro do fluxo de capital após a interação com seus smart contracts. A blockchain não mente, você só precisa aprender a perguntar direito.