refactor: replace env.events().publish() with #[contractevent] structs

[aguilar1x]

Context

Depends on #4 (trait-based architecture). The contract currently emits all events using the deprecated env.events().publish() pattern. Since soroban-sdk 23+ the standard is to define #[contractevent] structs and call .publish(e) on them. OZ v0.6.0 already ships typed event structs for all standard operations.

Current pattern (deprecated)

env.events().publish(
    (Symbol::new(&env, MINT_EVENT), &to),
    amount
);

env.events().publish(
    (Symbol::new(&env, TRANSFER_EVENT), &from, &to),
    amount
);

Target pattern (v0.6.0 / soroban-sdk 23+)

OZ already provides these events in stellar_tokens::fungible:

• stellar_tokens::fungible::emit_mint(e, &to, amount)
• stellar_tokens::fungible::emit_transfer(e, &from, &to, None, amount)
• stellar_tokens::fungible::emit_approve(e, &owner, &spender, amount, live_until_ledger)

And in stellar_contract_utils::pausable:

• stellar_contract_utils::pausable::emit_paused(e)
• stellar_contract_utils::pausable::emit_unpaused(e)

For any custom events (e.g., batch_mint) define them as:

#[contractevent]
#[derive(Clone, Debug, Eq, PartialEq)]
pub struct BatchMint {
    #[topic]
    pub to: Address,
    pub amount: i128,
}

// then emit with:
BatchMint { to: account.clone(), amount }.publish(e);

Files to update

• Contracts/stablecoin/src/contract.rs — replace all env.events().publish() calls
• Contracts/stablecoin/src/types.rs — remove MINT_EVENT, BURN_EVENT, TRANSFER_EVENT, PAUSE_EVENT, UNPAUSE_EVENT string constants (no longer needed)
• Add any custom event struct definitions (e.g., for batch_mint)

Acceptance criteria

• Zero uses of env.events().publish() in the codebase
• Standard OZ events (emit_mint, emit_transfer, etc.) are used for SEP-41 operations
• Custom events use #[contractevent] structs with #[topic] on address fields
• Event constants in types.rs are removed
• All existing tests pass (update event assertions to use new event types if needed)

[Joaco2603]

Hi! I’d like to take this issue. I’ve been working recently with Soroban SDK 23+, SEP-41 tokens, and OpenZeppelin Stellar v0.6.0, so migrating from the deprecated env.events().publish() pattern to typed #[contractevent] structs and OZ emit helpers is directly aligned with my experience. I can replace all legacy emissions with emit_mint, emit_transfer, emit_approve, and pausable events, define custom events like BatchMint with proper topics, remove obsolete constants in types.rs, and update tests to assert the new event types, ensuring the contract is fully compliant with the current event standard.

[devJaja]

Hello, I’m a smart contract and full-stack developer actively contributing to open-source ecosystems. I’ve worked on 30+ projects across the ecosystem, with hands-on experience in Solidity, Cairo, Soroban, JavaScript, TypeScript, Rust, and building on the Stellar ecosystem. I’m passionate about delivering secure and scalable blockchain systems and would love the opportunity to support and contribute to this issue.

[ryzen-xp]

Hi maintainers 👋
I’m a blockchain developer with strong expertise in Stellar, Rust,TS and Stellar SDK integrations. I’ve worked on multiple Stellar-based smart contract and backend systems.

I understand the scope of this issue and can deliver a reliable, production-quality solution with proper tests and documentation.
Plz assign me !!

ETA: 14 hours

[Kaylahray]

Hello 🙋‍♀️, I can do this and build successfully. Please assign.

[Chucks1093]

I will replace every env.events().publish() call with typed #[contractevent] structs and drop the string constants from types.rs so the contract is fully aligned with soroban-sdk 23+.

[Josue19-08]

Hello @aguilar1x 👋

My name is Josué, and I’m a dedicated open-source contributor with hands-on experience building and maintaining production-level applications across Web3 and full-stack ecosystems. My background includes working with Stellar-based infrastructure, Soroban smart contracts, backend services, and modern frontend development using React, with a strong focus on UI structure and user experience.

I’m comfortable navigating the full contribution lifecycle — from understanding the problem and proposing technical solutions, to delivering clean implementations, tests, and well-documented pull requests aligned with the repository’s standards.

This issue strongly matches my skill set, and I believe I can contribute an effective and maintainable solution within a reasonable timeframe. You’re welcome to review my GitHub profile to explore my previous contributions, ongoing open-source work, and technical background.

I care deeply about code quality, scalability, and clear collaboration, and I’m excited about the opportunity to help move this task forward and contribute value to the project.

Thank you for your consideration

[Mrwicks00]

Can I work on this issue, I will deliver this in few hours