Create: DNFactory

[QuitCrypto]

Description

Creates a DN Factory for easy deployments of DN404 Clones. Includes ability to customize name and symbol, and lock liquidity for an arbitrary number of seconds from deploy.

Checklist

Ensure you completed all of the steps below before submitting your pull request:

• [✅] Ran forge fmt?
• [✅] Ran forge snapshot?
• [✅] Ran forge test?

[rookmate]

Checks failed because solc version is 0.8.4 vs the contracts had 0.8.24 @QuitCrypto

[codebuster22]

my opinion: DN404 is a standard and multiple use cases can be created out of it. This repository should act more like a library repository rather than maintain the deployments of factory along with the core DN404 code. Hence, rather than having the factory in the core repository, it can be added to a new repository specifically created for use-cases or can be added to example directory.

[ghost]

@QuitCrypto I suggest if we could have event like DN404Created emitted would be great to track tokens on subgraph, etc.

[pop-punk]

my opinion: DN404 is a standard and multiple use cases can be created out of it. This repository should act more like a library repository rather than maintain the deployments of factory along with the core DN404 code. Hence, rather than having the factory in the core repository, it can be added to a new repository specifically created for use-cases or can be added to example directory.

@codebuster22 Where this factory lives isn't SUPER important. But the reasoning behind having a factory contract is it will be tied to a dapp where people can easily deploy verified DN404 implementations (there will likely be more than just the Cloneable example included here). A lot of people that may want to deploy tokens aren't on the most technical side, so giving them an easy way to approach the deployment of the contract is important.

Yes, this does increase the chances of more projects that may not succeed, but the pros outweigh that here to be honest in order to give people easy access to safe and verified DN404 implementations.

The goals for this is so you can easily fact check if a contract you're about to interact with is truly using unmodified DN404 base smart contracts, since there are so many fake ones out there.

[codebuster22]

my opinion: DN404 is a standard and multiple use cases can be created out of it. This repository should act more like a library repository rather than maintain the deployments of factory along with the core DN404 code. Hence, rather than having the factory in the core repository, it can be added to a new repository specifically created for use-cases or can be added to example directory.

@codebuster22 Where this factory lives isn't SUPER important. But the reasoning behind having a factory contract is it will be tied to a dapp where people can easily deploy verified DN404 implementations (there will likely be more than just the Cloneable example included here). A lot of people that may want to deploy tokens aren't on the most technical side, so giving them an easy way to approach the deployment of the contract is important.

Yes, this does increase the chances of more projects that may not succeed, but the pros outweigh that here to be honest in order to give people easy access to safe and verified DN404 implementations.

The goals for this is so you can easily fact check if a contract you're about to interact with is truly using unmodified DN404 base smart contracts, since there are so many fake ones out there.

@pop-punk I Acknowledge the utility of a factory contract for easy deployment of verified DN404 implementations, especially important for non-technical users, I suggest to handle this aspect separately. This ensures the main repository remains clean and focused.

I believe the DN404 repository should primarily serve as a library, focusing on the core DN404 code. This approach will keep the repository streamlined and dedicated to standard implementations and examples, avoiding the complexities associated with deployment management.

Managing deployment scripts, factory contract addresses, and various factory versions within the DN404 repository shifts its purpose from a library to more of a project management hub, potentially complicating management and deterring community contributions.

My Suggestion:

1. Keep the DN404 repository as the primary library for standard implementation and examples.
2. Create a new repository (e.g., DN404-factory or awesome-DN404) dedicated to building DN404 use cases and relevant factories. This separation allows the community to contribute their implementations without the risk of inadvertently altering the core DN404 logic.

Benefits of This Approach:

1. Community Contributions: This separation makes it easier for the community to contribute, enhancing engagement.
2. Simplified Review Process: Pull requests to the new repository won't risk altering the core DN404 logic, streamlining the review process.
3. Clear Organizational Structure: This maintains a clean separation between the standard implementation and its applications, improving both clarity and management.

I believe adopting this structured approach will not only foster greater community involvement but also ensure the integrity of the DN404 core code, all while providing a clear framework for the development and application of DN404 standards.

Though the final decision lies with the core contributors and you. Anyways, I'm always happy to contribute.

[ghost]

@codebuster22 Awesome-DN404 sounds good, just like https://github.com/mudgen/awesome-diamonds.