Discuss and Design Contract Configuration for AMM Integration

[AbdelStark]

Description

We need to discuss and design the approach for handling contract configurations, specifically concerning the integration with Automated Market Makers (AMMs) like factory and router contracts. The key consideration is balancing flexibility with the integrity of the Unruggable Memecoin's promise of safety and reliability.

Discussion Points

1. Constructor Arguments vs. Hardcoding: Assess the trade-offs between using constructor arguments for AMM addresses (which offers flexibility) and hardcoding these addresses (which may better align with the project's promise of safety).
2. Potential Risks of Flexible Configurations: Consider the risks associated with allowing deployments with potentially malicious AMM addresses, undermining the project's safety assurances.
3. Hardcoding with Compile-Time Extensions: Explore the feasibility and implications of hardcoding certain configurations, possibly using compile-time extensions similar to what is done in Dojo.
4. Environment Management: Deliberate on strategies for managing different environments (development, testing, production) while ensuring the integrity and security of the contract.
5. Using Canonical Factories for Network-Specific Deployments: Discuss the use of UnruggableMemecoinFactory for different networks, each deploying UnruggableMemecoin contracts with a preconfigured set of addresses suitable for those networks (e.g., JediSwap router and factory addresses on the Sepolia Testnet). (shout out to @tarrencev for the idea)

Alternatives and Tradeoffs

• Constructor Arguments:
  • Pros: Greater flexibility, easier to manage different environments.
  • Cons: Increased risk of misuse or deployment with malicious configurations.
• Hardcoding (possibly with compile-time extensions):
  • Pros: Enhances security and adheres to the project's safety promise.
  • Cons: Less flexibility, potentially more challenging to manage across different environments.
• Canonical Factories for Network-Specific Deployments:
  • Pros: Streamlines deployment across different networks with preconfigured, trusted AMM addresses, ensuring consistency and reducing the risk of malicious configurations.
  • Cons: Potentially less flexibility for custom deployments; requires maintenance and updates for each network-specific factory.

Implementation Notes

• Ensure thorough documentation of the chosen approach and its rationale.
• Prioritize security and adherence to the project's core principles in the decision-making process.
• Consider community feedback and insights from similar projects, especially regarding network-specific deployments.

[enitrat]

Using Canonical Factories for Network-Specific Deployments sounds like the best approach to me. We can use onchain events to have access to useful logs, and we have better control over the deployment pipeline to ensure that a contract is flagged as "unruggable"

[AbdelStark]

I agree with you, it's my preferred approach too.

[dubzn]

Hey hi guys, do you know any examples to look at to understand this solution? Or any type of documentation? This should be included in this PR?

edit: I hadn't noticed that the issue had been updated. I understood the idea, it seems like the right approach to solve the problem, but I'm not 100% sure how to implement it. I would like to check @tarrencev solution.

[rcatalan98]

I agree this should be the final solution. Does it make sense to have this for the MVP? I think we could start with having jediswap's address hardcoded and then build the canonical factory. What do you guys think?

[AbdelStark]

It wont impact your PR, you can proceed with hardcoded values and we will add factories later