Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[contract] feat: Implement Initial Token Distribution in Constructor #60

Closed
AbdelStark opened this issue Dec 15, 2023 · 3 comments
Closed

[contract] feat: Implement Initial Token Distribution in Constructor #60

AbdelStark opened this issue Dec 15, 2023 · 3 comments
Assignees
@0xEniotna
Labels
enhancement New feature or request good first issue Good for newcomers smart-contracts

Comments

@AbdelStark
Copy link
Contributor

Issue: Implement Initial Token Distribution in Constructor

Description

This issue explores the possibility of handling the initial token distribution directly in the constructor of the Unruggable Memecoin contract. The proposal is to pass arrays of holders and their respective token amounts into the constructor, thereby conducting the distribution at the time of deployment. This approach could simplify several aspects of the contract's operation, including transfer restrictions and holder tracking prior to the launch.

Discussion Points

  1. Distribution via Constructor: Assess the feasibility and advantages of performing the initial distribution through the contract constructor.
  2. Simplification of Transfer Restrictions: Explore how this method simplifies the process of disabling transfers post-initial distribution and until the launch_memecoin function is called.
  3. Reduction of On-Chain Tracking Needs: Evaluate the impact on the need for tracking initial holders on-chain.
  4. Flexibility in Ownership and Recipient Roles: Consider how this approach maintains flexibility in defining different entities as owners and initial recipients.

Implementation Considerations

  • Ensure the constructor can efficiently handle an array of holders and token amounts without exceeding gas limits.
  • Develop robust error handling and validation for the input arrays to prevent any discrepancies in the distribution process.
  • Thoroughly test the constructor's distribution logic to ensure accuracy and reliability.
  • Maintain clarity and transparency in the contract's code and documentation regarding the distribution process.

Pros and Cons

  • Pros:
    • Simplifies contract logic by consolidating distribution into deployment.
    • Reduces the need for complex on-chain tracking mechanisms.
    • Maintains flexibility in roles and responsibilities within the contract.
  • Cons:
    • Potentially higher deployment gas costs due to the inclusion of distribution logic in the constructor.
    • Requires careful input validation to ensure accurate and fair distribution.
@AbdelStark AbdelStark added enhancement New feature or request good first issue Good for newcomers smart-contracts labels Dec 15, 2023
@0xEniotna
Copy link
Contributor

Let me try something !

@AbdelStark
Copy link
Contributor Author

Let me try something !
sure mate!

@AbdelStark AbdelStark assigned AbdelStark and 0xEniotna and unassigned AbdelStark Dec 15, 2023
@0xEniotna 0xEniotna mentioned this issue Dec 15, 2023
Merged
AbdelStark pushed a commit that referenced this issue Dec 18, 2023
@0xEniotna
Feat/initial distrib constructor (#64)
f83073b 
Issue: #60 

This is a first draft. 

In the proposed implementation, the dev would pass an array
`initial_holders` of tuples `(initial_holder_address, amount)`.
The `initial_recipient` should be in the position 0 of the array. As
`initial_recipient` is an `initial_holder`, it makes sense to add him in
the array. But it implies that the sum of all amounts of the
`initial_holders` array should remain equal to `initial_supply`. This is
verified by line 116 `assert(initial_minted_supply <= initial_supply,
'Unruggable: max supply reached');`.
I'm also considering that the `initial_recipient` account should deposit
ALL of his tokens when `launch_memecoin` is called.. Otherwise it is not
possible to perform the "team allocation" check since the balance of
`initial_recipient` would be greater. If `initial_recipient` does not
deposit all of his token in `launch_memecoin` then I'm not performing
the "max team allocation" check on him which bypasses the rule (does
that make sense ?).

Didn't write the tests yet, I wanted to have feedbacks on my
implementation.
@0xEniotna
Copy link
Contributor

This can be closed

@enitrat enitrat closed this as completed Dec 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@0xEniotna 0xEniotna

Labels
enhancement New feature or request good first issue Good for newcomers smart-contracts
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@AbdelStark @enitrat @0xEniotna