Stellar stealth-announcer

[gloskull]

Motivation

• Provide a v2 Stellar stealth-announcer event schema that lets wallets/indexers pre-filter by scheme and an indexed view-tag bucket before cryptographic validation.
• Define a stable derivation rule for the view-tag bucket and a simple initial metadata_kind convention to future-proof metadata encoding evolution.
• Preserve historical v1 semantics by requiring scheme_id = 2 for v2 and documenting the v1→v2 migration expectations in contract comments.

Description

• Add STELLAR_V2_SCHEME_ID = 2, METADATA_KIND_VIEW_TAG = 1, and view_tag_bucket(metadata) -> metadata[0] as u32 to stellar/stealth-announcer/src/lib.rs.
• Change announce to assert scheme_id == 2, publish topics as ("announce", scheme_id, view_tag_bucket, metadata_kind), and publish data as (stealth_address, ephemeral_pub_key, metadata).
• Document the v1 layout and the migration path in code comments so historical events are not reinterpreted as v2.
• Update unit/audit tests and event snapshot fixtures to exercise and reflect the new topic layout and bucket derivation.

Testing

• Ran cargo fmt --all successfully.
• Ran git diff --check with no issues reported.
• Ran cargo test -p stealth-announcer and all tests passed (unit + audit tests for the crate).

---

Closes #24

[drips-wave]

@gloskull Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[truthixify]

The v2 implementation is exactly what the design doc in #26 prescribed: STELLAR_V2_SCHEME_ID = 2, the four-topic shape (announce, scheme_id, view_tag_bucket, metadata_kind), stable view_tag_bucket derivation from metadata[0], and the strict assert_eq!(scheme_id, STELLAR_V2_SCHEME_ID) guard. The doc comments calling out the migration path (deploy a new announcer, do not reinterpret v1 events) are great.

Blocker is conflicts. Your earlier audit PR #34 landed first and the audit doc and tests/audit.rs files now exist on develop with different content than this PR expects. Could you rebase?

git fetch origin
git rebase origin/develop
# resolve in stellar/stealth-announcer/tests/audit.rs and audits/2026-05-gpt-5-3-codex.md
# keep #34's v1 audit content AND your new v2 entries side by side
git push --force-with-lease

After the rebase, the audit doc should have both: the four v1 findings (WA-ANN-01 through WA-ANN-04 documenting the historical contract) and a new section documenting the v2 redesign.

Thanks @gloskull, this is a meaningful piece of the rollout.

[gloskull]

Description of Changes

• Add a V2 redesign section to stellar/stealth-announcer/audits/2026-05-gpt-5-3-codex.md documenting STELLAR_V2_SCHEME_ID = 2, the four-topic shape (announce, scheme_id, view_tag_bucket, metadata_kind), METADATA_KIND_VIEW_TAG = 1, and the metadata[0] bucket derivation.
• Update stellar/stealth-announcer/tests/audit.rs to keep the WA-ANN categories but assert the new v2 data tuple (stealth_address, ephemeral_pub_key, metadata) and v2 topics including view_tag_bucket and metadata_kind.
• Update stellar/stealth-announcer/tests/properties.rs to target v2-only behaviors (require non-empty metadata, enforce v2 scheme id in tests, cover stable bucket derivation and caller-free payload round-trips).
• Run code formatting on the crate and adjust tests to match the contract's v2 guard and topic/layout semantics.

[gloskull]

@truthixify please review and merge

[truthixify]

Verified locally that the merge keeps #46's reproducible build pipeline and #13's property tests intact. The v2 announcer schema (STELLAR_V2_SCHEME_ID = 2, 4-topic indexed layout, view_tag_bucket from metadata[0], the strict scheme_id assertion) plus the audit-doc append for v2 are exactly what #26's design called for. Merging. Thanks @gloskull.