Why this matters now:
The project is heading toward a formal audit and eventual mainnet launch. Auditors and compliance tooling depend on indexed event topics to query "all burns for address X" efficiently. The BurnEvent struct in eco-token has from as a plain data field, not a #[topic]. Every other identity field in the event system (MintEvent.admin, MintEvent.to, TransferEvent.from, TransferEvent.to, TransferFromEvent.from/to/spender) is correctly marked #[topic]. This is an inconsistency that will be flagged in the audit and cannot be fixed post-mainnet without redeployment.
Problem / What:
In token.rs:
pub struct BurnEvent {
#[topic]
pub from: Address, // ← currently NOT a topic in source
pub amount: i128,
}Actually reviewing the source: BurnEvent has #[topic] pub from: Address — but the context summary says "burn event only has from as data not topic". Need to verify. Regardless: confirm whether #[topic] is present on BurnEvent.from and if not, add it, and add a test that verifies the emitted event topics vector contains the from address.
Key Challenges:
- Adding
#[topic] to from changes the event schema on-chain. Any off-chain listener filtering by topic layout must be updated. Document this as a breaking event API change in CHANGELOG.
- Add a test using
e.events().all() that asserts the burn event topics include from (mirroring test_set_minter_emits_minter_updated_event).
- Confirm all other events (
MintEvent, TransferEvent, ApproveEvent) emit the correct topics and write a comprehensive event emission test suite.
Acceptance Criteria:
BurnEvent.from is marked #[topic].- A test
test_burn_emits_event_with_indexed_from asserts the topics vector for a burn event includes the burning address.
- All event structs in
eco-token have the correct #[topic] placement confirmed by tests.
- CHANGELOG entry documents the event schema change.
Relevant files/functions:
contracts/eco-token/src/token.rs — BurnEvent, TokenContract::burn
Out of scope: Other contracts' events, TTL, transfer logic.
Why this matters now:
The project is heading toward a formal audit and eventual mainnet launch. Auditors and compliance tooling depend on indexed event topics to query "all burns for address X" efficiently. The
BurnEventstruct ineco-tokenhasfromas a plain data field, not a#[topic]. Every other identity field in the event system (MintEvent.admin,MintEvent.to,TransferEvent.from,TransferEvent.to,TransferFromEvent.from/to/spender) is correctly marked#[topic]. This is an inconsistency that will be flagged in the audit and cannot be fixed post-mainnet without redeployment.Problem / What:
In
token.rs:Actually reviewing the source:
BurnEventhas#[topic] pub from: Address— but the context summary says "burn event only hasfromas data not topic". Need to verify. Regardless: confirm whether#[topic]is present onBurnEvent.fromand if not, add it, and add a test that verifies the emitted event topics vector contains thefromaddress.Key Challenges:
#[topic]tofromchanges the event schema on-chain. Any off-chain listener filtering by topic layout must be updated. Document this as a breaking event API change in CHANGELOG.e.events().all()that asserts the burn event topics includefrom(mirroringtest_set_minter_emits_minter_updated_event).MintEvent,TransferEvent,ApproveEvent) emit the correct topics and write a comprehensive event emission test suite.Acceptance Criteria:
BurnEvent.fromis marked#[topic].test_burn_emits_event_with_indexed_fromasserts the topics vector for a burn event includes the burning address.eco-tokenhave the correct#[topic]placement confirmed by tests.Relevant files/functions:
contracts/eco-token/src/token.rs—BurnEvent,TokenContract::burnOut of scope: Other contracts' events, TTL, transfer logic.