Bundle Detection: Membangun Entity Resolution Agent untuk Analisis On-Chain yang Lebih Andal

28 Jul, 2026

Kalau target akhirnya memang ingin membangun sistem yang benar-benar production-grade, saya justru tidak akan membuat bundle detector sebagai komponen utama.

Bundle detection tetap berguna, terutama untuk membaca aktivitas pada menit-menit awal sebuah token diluncurkan. Namun, menurut saya itu hanya salah satu feature, bukan inti dari keseluruhan sistem.

Yang jauh lebih menarik adalah membangun sebuah Entity Resolution Agent.

Tujuannya bukan sekadar menjawab:

"Apakah token ini bundled?"

melainkan menjawab pertanyaan yang jauh lebih penting:

"Apakah wallet-wallet ini sebenarnya dikendalikan oleh entity yang sama?"

Perbedaannya cukup besar.

Pola bundling bisa berubah seiring berkembangnya teknik launch token. Orang bisa mengacak waktu transaksi, memecah pembelian ke banyak wallet, atau menggunakan beberapa hop funding agar terlihat berbeda.

Sebaliknya, hubungan antarwallet, pola pendanaan, histori perilaku, hingga kemunculan berulang di berbagai token jauh lebih sulit dipalsukan.

Itulah alasan kenapa menurut saya Entity Resolution adalah fondasi yang jauh lebih kuat dibanding sekadar bundle detection.

Dari Bundle Detection ke Entity Resolution

Kalau disederhanakan, arsitekturnya kurang lebih seperti ini.

RPC
                   │
      ┌────────────┴────────────┐
      │                         │
 Solana Pipeline          EVM Pipeline
      │                         │
      └────────────┬────────────┘
                   │
         Wallet Graph Builder
                   │
         Entity Resolution Engine
                   │
        Historical Behavior DB
                   │
      Cluster Risk Scoring Engine
                   │
          Decision / Alert Agent

Yang menarik, sebagian besar pipeline ini bisa dipakai baik di Solana maupun EVM. Yang berubah hanya cara mengambil datanya.

Layer 1 — Launch Reconstruction

Langkah pertama adalah membangun ulang menit-menit awal sebuah token diluncurkan.

Agent mencoba merekam berbagai informasi seperti:

deployer
LP creator
first buyers
first transfers
bundle ID (khusus Solana)
slot atau block launch

Contoh struktur datanya:

launch = {
    "slot": slot,
    "buyers": first_buyers,
    "first_lp": lp_creator,
    "first_transfers": transfers,
    "bundle_ids": jito_bundle_ids,
    "deployer": deployer
}

Semakin lengkap data pada tahap ini, semakin mudah proses analisis berikutnya.

Data Source

Solana

Helius
Solana Tracker API
Jito Block Engine
Custom RPC

EVM

Alchemy
QuickNode
Tenderly
Erigon Archive Node

Layer 2 — Funding Graph

Kalau harus memilih satu layer yang paling penting, menurut saya inilah jawabannya.

Agent tidak lagi melihat siapa yang membeli token.

Agent mulai bertanya:

"Uang mereka berasal dari mana?"

Contoh sederhana:

def funding_graph(wallet):

    parents = trace_funding(
        wallet,
        depth=4
    )

    return parents

Misalnya hasilnya menjadi seperti ini.

CEX
 ↓
Wallet A
 ↓
Wallet B
 ↓
Wallet C
 ↓
Buyer Wallet

Kalau ternyata ada 20 wallet berbeda yang semuanya bermuara ke Wallet A, maka kemungkinan besar mereka bukan wallet independen.

Hubungan seperti ini biasanya jauh lebih kuat dibanding sekadar membeli pada waktu yang sama.

Layer 3 — Entity Resolution

Setelah graph pendanaan terbentuk, agent mulai mengelompokkan wallet.

Misalnya:

cluster = {
    "wallets": [...],
    "shared_funder": True,
    "same_deployer": False,
    "co_transfer": True,
    "shared_lp": True,
    "shared_claim": False
}

Lalu dihitung tingkat kemiripannya.

entity_score = (
    funding_similarity
    + transfer_similarity
    + deployer_similarity
    + lp_interaction
)

Jika:

entity_score > threshold

wallet tersebut dianggap bagian dari satu entity.

Pendekatan seperti ini jauh lebih fleksibel dibanding rule sederhana seperti "transaksi pada block yang sama".

Layer 4 — Historical Memory

Menurut saya ini salah satu bagian yang paling underrated.

Sebagian besar dashboard hanya melihat kondisi saat ini.

Padahal wallet memiliki sejarah.

Misalnya:

wallet_history = {

    wallet:

    {
        "launches": 42,
        "rugged": 18,
        "runner": 7,
        "avg_hold": 4.3,
        "avg_exit_delay": 11,
        "same_cluster": 31
    }

}

Sekarang agent tahu bahwa wallet tersebut:

sudah ikut 42 launch,
pernah muncul di banyak rug,
beberapa kali ikut runner,
rata-rata hanya hold beberapa menit atau jam,
sering muncul bersama cluster tertentu.

Artinya keputusan tidak lagi dibuat berdasarkan satu snapshot saja.

Layer 5 — Behavior Layer

Setelah mengetahui hubungan wallet, agent mulai memahami perilakunya.

Contohnya:

behavior = {

    "buy_window": 2.1,
    "sell_window": 1.4,
    "hold_time": 28,
    "reentry_count": 3,
    "profit_taken": True
}

Kemudian dihitung tingkat koordinasinya.

coordination = correlation(
    cluster.sell_times
)

Kalau seluruh wallet selalu menjual hampir bersamaan, kemungkinan memang ada koordinasi.

Belum tentu selalu berarti aktivitas yang buruk, tetapi jelas merupakan sinyal penting.

Layer 6 — Cross-Token Entity Memory

Kalau ditanya layer favorit saya, jawabannya ini.

Misalnya Wallet A selalu muncul bersama Wallet B, Wallet C, dan Wallet D.

Bukan cuma pada satu token.

Tetapi di:

TOKEN A
TOKEN B
TOKEN C
TOKEN D
TOKEN E

Agent menyimpan hubungan tersebut.

co_matrix[
    wallet_a
][wallet_b] += 1

Semakin sering pasangan wallet muncul bersama pada berbagai launch, semakin tinggi confidence bahwa mereka memang berada dalam satu jaringan.

Pendekatan lintas token seperti ini jauh lebih sulit dimanipulasi dibanding sekadar mengubah waktu pembelian.

Layer 7 — Remaining Supply

Kesalahan yang sering dilakukan adalah hanya melihat jumlah holder.

Padahal yang lebih penting adalah menghitung:

Berapa supply yang sebenarnya masih dikendalikan oleh satu entity?

Contohnya:

remaining_supply = sum(
    wallet.balance
    for wallet
    in entity
)

Outputnya bisa menjadi:

Entity A : 17.4%
Entity B : 11.2%
Entity C : 4.1%

Di dashboard mungkin terlihat ada ribuan holder.

Tetapi setelah wallet dikelompokkan, ternyata sebagian besar supply masih berada di tangan beberapa entity saja.

Layer 8 — Risk Engine

Daripada menghasilkan jawaban "Yes" atau "No", saya lebih suka menggunakan weighted score.

risk = (

0.30 * funding_cluster +

0.22 * historical_relation +

0.18 * remaining_supply +

0.15 * coordinated_exit +

0.10 * launch_bundle +

0.05 * holder_pattern

)

Output akhirnya menjadi:

Risk Score : 82 / 100

Model seperti ini jauh lebih mudah dikembangkan.

Bobot setiap feature bisa terus diperbaiki menggunakan hasil backtest.

Data Stack

Solana

Purpose	Stack
RPC	Helius Enhanced RPC, Triton, Custom Validator
Transaction Parsing	Helius Enhanced API
Wallet History	Solana Tracker API
Token Metadata	Birdeye, DexScreener
Liquidity	GeckoTerminal
Bundle Verification	Jito Block Engine, Jito Explorer
Storage	PostgreSQL + ClickHouse
Queue	Redis Streams atau NATS
Graph Analysis	Neo4j atau NetworkX

EVM

Pendekatannya sedikit berbeda karena tidak memiliki konsep Jito Bundle.

Sebagian besar analisis dilakukan melalui transaction trace dan event log.

Purpose	Stack
RPC	Erigon Archive, Reth, Alchemy, QuickNode
Internal Trace	trace_transaction, debug_traceTransaction
Logs	eth_getLogs
Labels	Arkham, Nansen (jika tersedia), atau label internal
Token & Liquidity	GeckoTerminal, DeFiLlama
Storage	PostgreSQL + ClickHouse
Graph Analysis	Neo4j atau NetworkX

Logic yang Paling Underrated

Kalau harus memilih satu snippet yang paling saya sukai, mungkin ini.

for token in launches:

    for wallet in token.first_buyers:

        history[wallet].launches += 1

        history[wallet].tokens.append(token)

for pair in combinations(first_buyers, 2):

    co_appearance[pair] += 1

Sekilas terlihat sederhana.

Tetapi setelah berjalan beberapa bulan, agent mulai mengingat siapa saja yang selalu muncul bersama.

Pada titik ini, agent tidak lagi mengenali transaksi.

Agent mulai mengenali identitas sebuah kelompok wallet.

Menurut saya, inilah bagian yang paling sulit dimanipulasi.

Arah Pengembangan Berikutnya

Tahap berikutnya adalah mengubah seluruh sistem menjadi graph-based AI agent.

Node dapat berupa:

Wallet
Deployer
LP
CEX
Token

Sedangkan edge dapat merepresentasikan:

Funding
Transfer
Swap
LP Interaction
Co-Appearance
Ownership

Di atas graph tersebut, agent bisa menjalankan berbagai algoritma modern seperti:

Community Detection untuk menemukan kelompok wallet yang saling berhubungan.
Link Prediction untuk memperkirakan hubungan yang belum terlihat secara eksplisit.
Temporal Anomaly Detection untuk menemukan koordinasi yang hanya muncul pada periode tertentu.
Centrality Analysis untuk mengidentifikasi wallet yang menjadi pusat distribusi dana atau pengendali aktivitas.

Pendekatan berbasis graph seperti ini semakin banyak digunakan dalam sistem analisis on-chain tingkat lanjut karena mampu menangkap pola yang tidak terlihat jika hanya melihat satu transaksi atau satu token secara terpisah.

Penutup

Pada akhirnya, saya melihat bundle detection hanyalah satu bagian kecil dari keseluruhan puzzle.

Kalau tujuan kita hanya ingin mengetahui apakah sebuah launch menggunakan bundle, maka bundle detector mungkin sudah cukup.

Namun kalau tujuannya adalah memahami siapa yang berada di balik aktivitas tersebut, bagaimana mereka bergerak dari satu token ke token lain, bagaimana hubungan antarwallet terbentuk, dan bagaimana pola koordinasinya berkembang dari waktu ke waktu, maka Entity Resolution Agent menawarkan pendekatan yang jauh lebih kuat.

Semakin lama sistem berjalan, semakin banyak histori yang terkumpul. Pada titik tertentu, agent tidak lagi sekadar membaca transaksi. Ia mulai membangun memori tentang perilaku sebuah jaringan wallet. Dan menurut saya, kemampuan mengenali jaringan seperti inilah yang menjadi fondasi utama untuk analisis on-chain generasi berikutnya.