Gnosis App (heuristic sector)¶

What this is¶

Gnosis App is the consumer wallet experience at app.gnosis.io — a Safe-backed smart account that uses Cometh ERC-4337 bundlers as the relayer layer and integrates Circles V2 for social-recovery-style onboarding. There is no single "Gnosis App contract"; the app is a collection of frontend flows that orchestrate Safes, Zodiac modules, the Circles InvitationModule, and the Cometh relayers into a coherent product.

Because there is no contract to query, there is no authoritative on-chain label list of Gnosis App users. Cerebro's other product sectors all have a clean discovery source — Gnosis Pay reads int_crawlers_data_labels WHERE project = 'gpay', lending positions are pulled from explicit deposit/borrow events, and so on. Gnosis App is the first sector where we have to derive membership from heuristics instead.

The good news: those heuristics are reliable. Every Gnosis App action funnels through the same chokepoint — a Cometh ERC-4337 bundler relays a userOp into the canonical EntryPoint. If the outer transaction's from_address is one of the three known Cometh v4 bundlers and its to_address is the EntryPoint v0.7, then any account that appears as an event parameter inside that transaction is, by construction, a Gnosis App user for that action. Six rule variants on top of this chokepoint cover the distinct user-facing flows.

Mixpanel is the check, not the ground truth¶

This is the key design constraint. Mixpanel's instrumentation does not capture every Gnosis App user — some users never log in to anything that fires an identify(...) call, some cohorts predate the current tracking, some flows happen exclusively on mobile where Mixpanel is sparser. Mixpanel coverage is incomplete by definition, so it cannot be used to gate sector membership.

Instead:

• The heuristic set is authoritative. If an address appears as the avatar in a Cometh-relayed RegisterHuman event, it is a Gnosis App user. Period.
• The Mixpanel match is diagnostic. We compute it as a matched_mp boolean on every row of the per-user fact, and we report the fraction as a coverage metric. A user being missing from Mixpanel is information about Mixpanel, not about the user's sector membership.

The bridge model fct_mixpanel_ga_gnosis_app_users reflects this directly: every row in int_execution_gnosis_app_user_identities appears in the fact table regardless of whether it has a matching Mixpanel row. matched_mp is just a column.

This is the opposite of the Gnosis Pay bridge, where membership comes from a clean upstream label list and Mixpanel is queried with INNER JOIN. The two patterns coexist in the repo by design.

The chokepoint¶

Every Gnosis App on-chain action passes through these two known addresses:

The Cometh bundler set is the v4 generation, which went live on 2025-11-12. Cerebro's heuristic is scoped to that date and later — earlier Cometh generations are explicitly out of scope.

The bundler addresses are stored in seeds/gnosis_app_relayers.csv so they can be rotated without touching SQL. The seed schema:

address,label,is_active,since_date
0x79c02f38dba39da361b4a0484c40351d50d55a94,Bundler1,1,2025-11-12
0xf03ddbe5b9b4ddec66009d94dc5d33dd719f34e1,Bundler2,1,2025-11-12
0xf0f772fa5f01bc19064a8ba323a4f53505586ce1,Bundler3,1,2025-11-12

The heuristic rules¶

Six rules, each independent. An address that triggers any rule is a Gnosis App user; an address that triggers multiple rules has higher confidence.

All six rules are derived from a Dune spell that the Gnosis Analytics team already runs in production. The Cerebro implementation reproduces them on top of the already-decoded Circles V2 events, so we don't repeat any ABI decoding — the existing contracts_circles_v2_Hub_events and contracts_circles_v2_NameRegistry_events models are the source of truth for the per-event data.

Pipeline¶

graph TD
    R[seeds/gnosis_app_relayers.csv] --> CT[cometh_txs CTE]
    T[execution.transactions] --> CT
    CT --> R1[rule_safe_invitation]
    CT --> R2[rule_metri_fee]
    CT --> R3[rule_register_human]
    CT --> R4[rule_invite_human]
    CT --> R5[rule_trust]
    CT --> R6[rule_profile]
    IES[int_execution_safes] --> R1
    SME[int_execution_safes_module_events] --> R1
    HUB[contracts_circles_v2_Hub_events] --> R2
    HUB --> R3
    HUB --> R4
    HUB --> R5
    NR[contracts_circles_v2_NameRegistry_events] --> R6
    R1 --> UE[int_execution_gnosis_app_user_events]
    R2 --> UE
    R3 --> UE
    R4 --> UE
    R5 --> UE
    R6 --> UE
    UE --> CUR[int_execution_gnosis_app_users_current]
    CUR --> ID["int_execution_gnosis_app_user_identities<br/>(pseudonymized)"]
    ID --> FU[fct_mixpanel_ga_gnosis_app_users]
    SMP[stg_mixpanel_ga__events] -. "LEFT JOIN" .-> FU
    UE --> FD[fct_mixpanel_ga_gnosis_app_daily]
    FU --> FD

The cometh_txs CTE is the key shared optimization: it filters execution.transactions to the few thousand Cometh-relayed transactions per month once, then every per-rule sub-query joins to it instead of re-scanning the transactions table six times.

Data models¶

int_execution_gnosis_app_user_events¶

Long-form heuristic event log. One row per (address, heuristic_kind, transaction_hash). An address that fires three rules across two transactions produces six rows; aggregation happens in the snapshot model below.

Materialized as incremental, partitioned monthly, batched 3 months at a time. meta.full_refresh.start_date: '2025-11-12'.

int_execution_gnosis_app_users_current¶

Snapshot of the sector — one row per address, regardless of how many rules / how many times they triggered.

Materialized as a table, rebuilt every run.

int_execution_gnosis_app_user_identities¶

The pseudonymization boundary. Every column derived from a wallet address is hashed via pseudonymize_address before it can flow into a marts model.

If holding raw_address_internal here turns out to be too risky for any reason, the model can be split into two siblings — one with the raw column for internal joins, one with only the pseudonymized identity for external consumption.

fct_mixpanel_ga_gnosis_app_users¶

The per-user fact. Every row from int_execution_gnosis_app_user_identities appears here — matched_mp is a column, not a join filter. Mixpanel is the check, not the source of truth.

fct_mixpanel_ga_gnosis_app_daily¶

Daily-cumulative sector size. Each row is "as of this date, here's the cumulative number of distinct users who have triggered any heuristic, and here's how many of them are visible in Mixpanel".

Key invariants¶

• Cometh relayer + EntryPoint filter is applied to every rule. No rule is allowed to read directly from a Circles or Safe events model without the join to cometh_txs. If you add a 7th rule, follow this pattern.
• Mixpanel never gates membership. All bridge joins are LEFT JOINs from the identities side to the Mixpanel side. The identities model is the authoritative input.
• Per-user fact has one row per user_pseudonym, regardless of matched_mp. Treat matched_mp = false as "not yet visible in Mixpanel", not as "not a user".
• raw_address_internal is the only raw column anywhere downstream of int_execution_gnosis_app_user_events. If you need raw addresses in a marts model, you're doing something wrong — pseudonymize at the boundary.
• Heuristic backfill is shallow. Only ~5 months of data exist (from 2025-11-12 to today), so the refresh wrapper finishes in a handful of batches. If the relayer set is rotated, the new bundler addresses go in the seed and the model is full-refreshed from the since_date column.

Cross-sector composition¶

Because Gnosis Pay and Gnosis App both pseudonymize through the same pseudonymize_address macro with the same salt, the two sector fact tables can be joined directly to find users active in both products:

SELECT
    count() AS users_in_both,
    avg(gp.daily_limit) AS avg_daily_limit_for_overlap
FROM dbt.fct_mixpanel_ga_gpay_users gp
INNER JOIN dbt.fct_mixpanel_ga_gnosis_app_users ga
    USING (user_pseudonym)
WHERE ga.matched_mp = true;

This is the kind of question the pseudonym pattern was built for: cross-product cohort analysis without ever materializing or joining on a raw address.

Gotchas¶

• Circles decoded_params key names must be confirmed first. The signature generator canonicalizes types but not argument names, so a parameter renamed in the deployed Circles ABI (e.g. truster vs canSendTo in old vs new Trust events) silently produces NULL lookups. Before committing each rule, run a one-row sample on the corresponding contracts_circles_v2_*_events model to confirm the keys.
• execution.transactions.from_address is stored without the 0x prefix. Same gotcha as the Safe traces convention. Strip from the seed when comparing.
• The Hub TransferSingle / TransferBatch decoded_params shape may differ from raw ERC-1155 transfers. Rule 2 (Metri fees) needs to verify the to and from keys against a sample row before assuming.
• new_users in the daily rollup is non-monotonic if you backfill. A late-arriving event for an address whose first_seen_at was in an earlier month will not change the historical new_users for that month — it's computed at insert time. If you need true "as-of" backfill, full-refresh the rollup after every backfill batch.
• The relayer set may rotate. If Cometh ships v5 bundlers, add them to the seed with a new since_date. The old v4 bundlers stay in the seed (with is_active=0) so historical heuristic hits are still recognized.

Related pages¶

• Gnosis Pay protocol — the parallel sector with a clean upstream label list, where Mixpanel is queried as a join and not as a check.
• Privacy & Pseudonyms — the pseudonymization pattern that makes the cross-sector composition query above possible.
• Safe protocol — the foundation for Rule 1.
• Circles V2 — the source of the decoded events feeding Rules 2–6.