Remaining tasks of the GnoSwap realms before launching

[dongwon8247]

This issue shares the remaining tasks of GnoSwap realms before launching. With the help of the gno.land core team, the goal is to enhance the maintainability, modularity, and security of the GnoSwap codebase to prepare for launch.

1. Expected Code Changes

1.1 Emergency Withdrawal (Halt)

• When halt is turned to true by the governance or admin, all GnoSwap contracts will halt. In this case, we should still allow users to withdraw their assets.
• The ultimate solution would be to figure out how to bring the upgradability of reams to Gno so that we will be able to make an upgrade and unhalt the contract in emergency situations.
• For now, to implement a function that can only be executed by the users to withdraw their assets when an emergency halt is set true.

1.2 Code Organization & Refactoring

• Extract redundant code into a common package (excluding prevRealm usage).
• Each function should focus on a single responsibility.
• Use intuitive and self-explanatory naming. (e.g. tokenId -> positionId)
• Prioritize cleanup of functions that act as transaction entry points.

1.3 Event Organization

• GnoSwap contracts should emit all event data necessary for the backend to deliver accurate data to the frontend, minimizing unnecessary on-chain computation overhead.
• This work will be continued from refactor: event message #458.

1.4 Referral Contract Integration

• GnoSwap has an on-chain referral system (doc.gno, GnoSwap docs)
• The initial implementation has been completed, but it needs to be integrated with other realms, defined here.

1.5 Apply Upgradable Realm Pattern (Unconfirmed) - Dedicated issue: #471

• This has been our biggest struggle and concern working on the GnoSwap contracts, and this agenda is where we need ideas and help the most.
• The current structure of the contracts is highly interdependent, as contracts import each other to stay connected, requiring updates to all contracts even when only one needs to be modified.
• This is particularly problematic for the gns contract. Currently, the gns, emission, and staker contracts are tightly coupled, and gns must remain unaffected by changes to the others (since token reissuance is not an option).
• Whether the contracts are upgradable or versioned, the structure of a Gno dapp must follow an upgradable pattern once it is introduced in Gno.
• This is our attempt (by @mconcat) to introduce an upgradable pattern. We tried to apply it to GnoSwap's codebase, but the required changes were too large. Additionally, we were unsure if we could implement it before the launch, especially since it is not actively being discussed by the core team at this time. We'd like to dig more into this with the core team, as this will be an essential pattern for all Gno builders.

---

2. Documentation

2.1 Add README and doc.gno for all contracts

• staker README example.
• referral doc.gno example.

2.2 Error Code Update

• Update error.gno from each contract, and apply changes to GnoSwap docs.

3. Final Review

3.1 Edge Test Cases

• Protocol fee distribution tests.
  • Protocol fee contract gets fees from four sources: Swap Fee, Pool Creation Fee, Withdrawal Fee, and Unstaking Fee (details: here).
  • Protocol fee contract distributes fees to xGNS holders, a non-transferable governance token issued by locking GNS tokens with a 1:1 ratio (details: here).
• Add additional reward distribution tests for launchpad.
• Simulate malicious third-party actions (e.g., transferring tokens to contracts) and verify pool, staker, protocol fees, and launchpad contracts if all reward ledgers (avl.Tree) ensure completeness distributing tokens. Specifically for pool, we need to ensure that the current Uniswap's V4-style single pool contract does not interact with unrelated balances in the pool.

3.2 Final Code Inspection

• Review vulnerabilities in gns and emission logic.
• Improve readability and add comments for position and router.
• Check unnecessarily public functions in staker, launchpad, and governance.