[Contracts] Add Notification Priority Levels

[Abd-Standard]

Description

Enable smart contracts to classify notifications by priority.

Tasks
Add priority enum.
Store priority metadata.
Emit priority-related events.
Update integration tests.

Acceptance Criteria
Priority is stored correctly.
Events include priority data.
Existing functionality remains intact.

[Clement-coder]

Hi,

I'm a full-stack software and blockchain engineer with experience delivering production-grade solutions across frontend, backend, infrastructure, analytics, and blockchain systems.

I'd like to take ownership of this issue. I've reviewed the requirements and have a clear approach for implementing a robust, scalable, and maintainable solution that satisfies all acceptance criteria. I'll ensure the implementation follows project conventions, includes comprehensive testing, and is properly documented.

I can start immediately and will provide consistent updates throughout development. Looking forward to contributing to the project.

[Damidesign]

I am highly interested in applying for this issue to implement Notification Priority Levels within the Notify-Chain smart contracts.

Differentiating alerts by priority (e.g., Critical, High, Standard, Low) is essential for any robust decentralized notification protocol to ensure users can filter noise and react immediately to high-stakes events. I am well-prepared to execute these contract upgrades efficiently and securely:

Smart Contract Engineering: I have strong, hands-on experience building and testing smart contracts, particularly writing secure, optimized Rust code for Soroban environments. I understand how to manage on-chain state safely.

Data Structure Optimization: Adding priority levels requires careful modification of existing contract data structures (such as structs or enums) and storage schemas. I am adept at structuring on-chain data to minimize computational overhead and ensure efficient querying.

State Migration & Compatibility: I understand the importance of safely handling existing state when upgrading contracts to introduce new fields like priority tiers, ensuring the new logic integrates flawlessly without disrupting previously stored notifications.

I am ready to review the current Notify-Chain contract architecture, define the new priority enums, and update the emission logic to support these levels. I would appreciate being assigned to this issue

[CleanDev-Fix]

Hi, I would like to work on this.

My planned approach:

1. Review the email notification template, versioning, and preference flow against the existing repo patterns and acceptance criteria.
2. Implement the smallest focused change needed for TypeScript implementation without broad refactors.
3. Verify with the package test/build command documented by the repo and include the results in the PR.

One trade-off I will keep in mind: I will avoid expanding the scope beyond this issue unless you prefer a broader fix.

Does this approach line up with what you want for this issue?

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@CleanDev-Fix's PR #146 was approved and merged by @Abd-Standard.

🏆 @CleanDev-Fix: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (258 total points). Track your full progress on GrantFox.

👏 Great work, @CleanDev-Fix! Keep contributing to Core-Foundry.