Files: frontend/lib/stellar.ts lines 870 to 890 (TRACKED_EVENT_TOPICS); frontend/hooks/useContractEvents.ts line 20; contracts/vesting/src/lib.rs publish sites at 95, 108, 121, 189, 279, 288, 332, 400, 438, 469, 476, 563
Issue: #336 fixed the topic list properly. It now contains the token contract's 19 topics and they match the contract's emitted set exactly, and the duplicate list in useContractEvents.ts was replaced with an import. That part is done well.
It covers only the token contract. The vesting contract emits eleven distinct topics and the list contains none of them: create, batch, release, revoke, clf_ext, prune, prop_adm, acc_adm, plus init, pause and unpause.
So no vesting activity is ever visible: not a schedule being created, not a recipient claiming, not an admin revoking a grant, not a cliff being extended. For a product whose headline feature is vesting, and where revocation is the action a recipient most needs to see, the activity feed is silent on all of it. Recipients have no audit trail for the contract that holds their tokens.
There is a complication worth designing around rather than discovering later: init, pause and unpause are emitted by both contracts with identical topic tuples. Topic-only filtering cannot tell them apart, so the decoder has to disambiguate on the emitting contract ID.
Fix: Add a TRACKED_VESTING_EVENT_TOPICS export beside the existing one, subscribe to it against the vesting contract's address, and key the decode on (contractId, topic) rather than topic alone so the three shared names resolve correctly. Extend TokenActivityType with the vesting cases and give each an icon and label in ActivityFeed.tsx, following the pattern #305 established. The vesting contract already has a checked-in topic fixture and a drift test (see #414), so the list has a source of truth to derive from.
Files:
frontend/lib/stellar.tslines 870 to 890 (TRACKED_EVENT_TOPICS);frontend/hooks/useContractEvents.tsline 20;contracts/vesting/src/lib.rspublish sites at 95, 108, 121, 189, 279, 288, 332, 400, 438, 469, 476, 563Issue: #336 fixed the topic list properly. It now contains the token contract's 19 topics and they match the contract's emitted set exactly, and the duplicate list in
useContractEvents.tswas replaced with an import. That part is done well.It covers only the token contract. The vesting contract emits eleven distinct topics and the list contains none of them:
create,batch,release,revoke,clf_ext,prune,prop_adm,acc_adm, plusinit,pauseandunpause.So no vesting activity is ever visible: not a schedule being created, not a recipient claiming, not an admin revoking a grant, not a cliff being extended. For a product whose headline feature is vesting, and where revocation is the action a recipient most needs to see, the activity feed is silent on all of it. Recipients have no audit trail for the contract that holds their tokens.
There is a complication worth designing around rather than discovering later:
init,pauseandunpauseare emitted by both contracts with identical topic tuples. Topic-only filtering cannot tell them apart, so the decoder has to disambiguate on the emitting contract ID.Fix: Add a
TRACKED_VESTING_EVENT_TOPICSexport beside the existing one, subscribe to it against the vesting contract's address, and key the decode on(contractId, topic)rather than topic alone so the three shared names resolve correctly. ExtendTokenActivityTypewith the vesting cases and give each an icon and label inActivityFeed.tsx, following the pattern #305 established. The vesting contract already has a checked-in topic fixture and a drift test (see #414), so the list has a source of truth to derive from.