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

[0xdevcollins]

Summary

Connect Dune Analytics to the Boundless escrow contract so we get public, SQL-driven on-chain analytics and a transparency dashboard with zero indexer infrastructure to run. Dune has indexed Stellar (including Soroban) since Meridian 2024, so our contract's events are queryable once it is live on mainnet (pubnet).

This issue lives in the contract repo because the main prerequisite is contract-side: the events we emit must carry enough structured, decodable data for analytics to be meaningful. The Dune dashboard work is downstream and easy once the event schema is confirmed.

Why (what it does for us)

• Public transparency dashboard — TVL in escrow, bounties funded/completed, total paid out to builders. High-signal for community trust, marketing, and Stellar ecosystem / grant 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.
• Independent source of truth — reconcile on-chain reality (Dune) against our off-chain DB (boundless-nestjs bounty/escrow rows) to catch drift.
• No infra — Dune indexes Stellar for us; we just write SQL. Complements our internal escrow-contract subscriber / stellar/indexers (which exist to drive app state, not analytics).

Background: how Dune sees us

Our escrow contract's activity lands in Dune's Stellar tables:

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

We filter history_contract_events to BOUNDLESS_EVENTS_CONTRACT_ADDRESS and build queries → charts → dashboard.

What the contract emits today

From the flow boundless-nestjs already consumes (escrow-contract subscriber + client), these Soroban events fire:

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

(Confirm the full set, including any withdraw / refund / cancel / explicit payout.)

The two real gotchas (please confirm)

1. Mainnet only. Dune indexes Stellar pubnet (mainnet). The contract is on testnet today, so meaningful analytics begin at mainnet deployment. We need the deployed mainnet contract address(es) for BOUNDLESS_EVENTS_CONTRACT_ADDRESS (and profile contract if relevant).
2. Soroban event decoding. Soroban events are XDR / ScVal-encoded (topics + data), so getting clean numbers out (amounts, bounty id, winner address, asset) requires decoding those topics/data in SQL. The friction here is proportional to how well-structured our emitted events are. We need each analytics-relevant event to carry, in decodable form:
   • a stable event/bounty id,
   • the amount and asset,
   • the relevant address(es) (funder, applicant, winner),
   • and a clear topic naming the event.

Scope / tasks

Contract-side (this repo)

• Audit the emitted events against the analytics needs above; list every event, its topics, and its data ScVal shape.
• Confirm each analytics-relevant event carries id + amount + asset + address in a decodable form; 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 README/docs so Dune SQL authors can decode reliably.
• Provide the mainnet contract address(es) once deployed.

Analytics-side (follow-up, likely tracked in platform/infra)

• Dune queries decoding history_contract_events for our contract into: TVL, bounties funded, total payouts, participant counts.
• A public "Boundless On-chain" Dune dashboard (TVL, bounties funded, payouts over time, by asset).
• (Optional) reconciliation query comparing on-chain payouts vs. our DB.

Acceptance criteria

• The contract's event schema is documented and every analytics-relevant event is confirmed decodable (id, amount, asset, address, topic).
• Mainnet contract address(es) are recorded here.
• A Dune query successfully decodes at least one real event type (e.g. create_event) filtered to our contract id and returns correct values.
• A first dashboard renders TVL + total payouts + bounties funded from live mainnet data.

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

---

Note: this depends on the mainnet-deployment / env-hardening work (escrow contract addresses + STELLAR_NETWORK=mainnet + STELLAR_RPC_URL) already flagged in the production-readiness review.

[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.