[Epic] Protocol 26 - Data Team

[chowbao]

Background

Protocol 26 includes 6 CAPs that introduce new ledger behavior, host functions, and network config changes. This epic tracks work needed to ensure Hubble captures the new data correctly and existing models don't silently break.

XDR changes
XDR changes applied in go-stellar-sdk

CAPs in scope:

• CAP-73 — SAC can now create trustlines and G-accounts via XLM transfer
• CAP-77 — Validator vote can freeze specific ledger keys
• CAP-78 — Contracts can cap their own TTL extension limit
• CAP-79 — New host functions to convert strkey strings ↔ Address/MuxedAddress objects
• CAP-80 — BN254 MSM + modular arithmetic host functions (ZK prover building blocks)
• CAP-82 — Checked (overflow-safe) variants of 256-bit integer arithmetic host functions

---

CAP-73 — SAC G-account & trustline creation

SAC can now create classic accounts and trustlines entries as a side effect of a contract transfer, not just via create_account / change_trust ops. Existing processors may silently miss these or misattribute them.

account and trustline entries from SACs are the same as existing account and trustline entires (in theory)

In theory there won't be any code changes for this CAP

In testnet/mainnet, confirm the above is true

• Audit TransformAccount: verify it ingests ledger_entry_change = 0 (Created) entries regardless of originating op type
• Same audit for TransformSigners
• Same audit for TransformTrustline
• Validate that accounts and trustlines rows created this way have correct ledger_entry_change, last_modified_ledger, and sponsor values populated
• Check history_contract_events — confirm SAC transfer events that spawn classic entries are captured and the causal chain is intact (note only transfer events emit events. Trustline creation does not emit an event)
• Add similar Horizon changes for effects to stellar-etl export_effects for the history_effects table
• In stellar-dbt: audit any model that counts account or trustline creation by operation type (e.g. models joining on create_account op or change_trust op)

---

CAP-77 — Frozen ledger keys (code changes to config_settings)

Frozen keys are distinct from evicted keys — they're inaccessible by validator governance, not TTL expiry. Need to make sure we don't conflate them in the data model.

There are new result codes/errors for when a frozen entry accessed.
The list of frozen keys will be held within config_settings as seen in the XDR changes. The generated xdr changes can be seen in go-stellar-sdk protocol-next branch

• Update config_settings to handle new frozen keys within the ConfigSettingEntry struct
  • CONFIG_SETTING_FROZEN_LEDGER_KEYS
  • CONFIG_SETTING_FROZEN_LEDGER_KEYS_DELTA
  • CONFIG_SETTING_FREEZE_BYPASS_TXS
  • CONFIG_SETTING_FREEZE_BYPASS_TXS_DELTA
• In stellar-dbt: update the config_settings_current model (and any other models using config_settings) to handle the above changes
• In stellar-dbt (optional/can defer): create a new model to create a table that lists the frozen ledger entries

---

CAP-78 — Max TTL extension cap

Low-risk but affects TTL analytics semantics. In theory there is no code change needed for this

• Verify nothing changes. TTL still looks like TTL in stellar-etl
• We should see the new host functions in the parameters column in history_operations as seen in the operations transform code

---

CAP-79 — Strkey host functions

Mostly a dev ergonomics change. Low data risk but decoded fields may look different.

New host functions added. Can be checked the same way as in CAP-78 above

• Spot-check topics_decoded and data_decoded in history_contract_events post-upgrade — addresses may now appear as G.../M.../C... strings rather than raw bytes in contracts using these host functions
• Same check for key_decoded / value_decoded in contract_data
• Confirm ETL XDR decoder handles the MuxedAddressObject host object type introduced alongside this
• It's unclear if this can be applied retroactively. Need to check if any code change/backfill needs to be done
  • In any case, we probably don't want to backfill and make the M string changes unless we need to as we already have the logic in place for handling strkeys

---

CAP-80 — BN254 MSM + modular arithmetic

No new ledger entry types. Mainly a cost model and volume watch item.

No code changes. No downstream impact in dbt/omni

---

CAP-82 — Checked 256-bit arithmetic

Minimal impact. New error codes may appear in failed transactions.

No code changes

New host functions added. Can be checked the same way as in CAP-78 above. I doubt we'd need to check these host functions though

---

Upgrade checklist

• Deploy protocol 26 on Testnet and run stellar-etl and stellar-dbt against it — validate no processor crashes or silent data drops
• Deploy to Mainnet and validate

[sydneynotthecity]

Since we have to make changes to the XDR anyway.....can we also pick up some of the missed XDR changes from P23? #364