Connect Dune Analytics to the escrow contract for on-chain analytics

[0xdevcollins]

Summary

Add on-chain analytics for the Boundless escrow contract using Dune Analytics — a public, SQL-driven dashboard (TVL, bounties funded, payouts) with no indexer infrastructure to run. Dune has indexed Stellar (including Soroban) since Meridian 2024, so the contract's emitted events are queryable directly.

Why (what it gives us)

• Public transparency dashboard — TVL in escrow, bounties funded/completed, total paid out to builders. High-signal for community trust, marketing, and Stellar ecosystem reporting.
• Product / treasury metrics — funded vs. completed bounties, average bounty size, time-to-payout, unique participant/organizer wallets, payout volume by asset (USDC…), over time.
• No infra to run — Dune indexes Stellar for us; this is pure SQL + a dashboard.

How Dune sees the contract

Contract activity lands in Dune's Stellar tables:

Table	Use
history_contract_events	Soroban contract events + traces — the escrow events land here, filterable by contract address
contract_data	Contract state/storage (escrow balances, TTL)
history_transactions / history_operations / history_effects	Tx-level detail, actors, fees
history_ledgers	Ledger metadata, timing

Filter history_contract_events to the deployed contract address, then build queries → charts → dashboard.

Events to work with

The contract emits Soroban events such as:

• create_event — a bounty escrow is created / funded
• add_funds — additional funding to the pool
• apply / apply_to_bounty — a participant applies / claims
• submit — a submission is anchored on-chain
• select_winners — winners chosen; payout settles

See the contract source for the authoritative, complete list and each event's topic + data layout (including any withdraw / refund / cancel / explicit payout).

The real gotcha: Soroban event decoding

Soroban events are XDR / ScVal-encoded (topics + data), so getting clean numbers out (amounts, bounty id, addresses, asset) means decoding those topics/data in SQL. The friction is proportional to how well-structured the emitted events are. Each analytics-relevant event should carry, in a decodable form:

• a stable event / bounty id,
• the amount and asset,
• the relevant address(es) (funder, applicant, winner),
• a clear topic naming the event.

If any of these are missing or hard to decode, part of this task is improving / normalizing the event emissions (and documenting them) so analytics stays reliable.

Scope / tasks

• Audit the emitted events; list every event, its topics, and its data (ScVal) layout.
• Confirm each analytics-relevant event carries id + amount + asset + address decodably; add / normalize fields if any are missing (e.g. explicit payout / withdraw / refund events with amounts).
• Document the event schema (topic names + ScVal layout) in the repo docs so anyone can decode the events.
• Write Dune queries decoding history_contract_events for the contract into: TVL, bounties funded, total payouts, participant counts.
• Build a public "Boundless On-chain" Dune dashboard (TVL, bounties funded, payouts over time, by asset).

Acceptance criteria

• Event schema documented; every analytics-relevant event confirmed decodable (id, amount, asset, address, topic).
• A Dune query decodes at least one real event type (e.g. create_event) filtered to the contract address and returns correct values.
• A dashboard renders TVL + total payouts + bounties funded.

References

• Dune Stellar data catalog: https://docs.dune.com/data-catalog/stellar/overview
• Dune ↔ Stellar integration: https://crypto.news/dune-unlocks-stellar-insights/
• Example Soroban dashboard: https://dune.com/paltalabs/soroban-amms-on-stellar
• Stellar / Soroban: https://stellar.org/soroban

[coderabbitai]

🔗 Related PRs

#46 - test: hackathon pillar — select_winners distribution + claim [merged]
#47 - test(events): added bounty pillar — apply / withdraw_application + c… [merged]
#59 - docs: rewrite README with deployed addresses and versions [merged]
#60 - Revise README and CI workflows for 1.1.0 deployment update [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[axeroofficialtournament-del]

Well after reading the issue alongside the boundless-contract README. The core blocker isn't Dune,  it's that our Soroban events may not carry fully decodable, structured data (stable id, amount, asset, address, topic) for every analytics-relevant action. Likely gaps might be withdraw/refund/cancel events may be missing or under-specified, and ScVal topic/data shapes for apply, submit, and select_winners need auditing against what Dune's history_contract_events can decode cleanly.

I have hands-on Rust and Soroban contract experience plus SQL/on-chain data work so I can audit events.rs, document the schema, and normalize any missing fields, then hand off a clean spec for the Dune dashboard.

I take my time and my practices has always been Quality over speed while still delivering on time.

[LuixDev]

hoal yo te puedo ayudar