The Motoko Golden Brother DAO: Motoko Gold coming to NNS. Happening now

Welcome to the the Motoko Golden DAO foundation.

Our goal is to become the promised land for ICP early adopters where growth and value are the norm.
You may perceive this project as DAO-driven-investment-fund focus 100% on the Internet Computer Blockchain ecosystem.

The initial distribution will be as follows:

  •      2,600 MotokoGold will be available for the SNS Sale.
    
  •      6,000 MotokoGold will be locked in the DAO Controlled Treasury.
    
  •      1,400 MotokoGold will be allocated for the team.
    

Motoko Gold go to market plan:

  • Provide liquidity to MotokoGold/ICP pair to establish a strong liquidity pool on dexes like ICPSwap, Sonic.ooo or ICLight.
  • Stake 8-year neuron to leverage the unique ICP capabilities.
  • 1,000 Motoko GOLD 1:1 Motoko SNS swap (Ready after launch following day)
  • Only-Up secondary market treasury dao driven orderbook (Currently under development).

Depending on the adoption of this proposal we are planning to extend the roadmap of Motoko Gold DAO to CEX listing initiatives, paid media marketing, dpools, trading utilities and more, like:

  • Buy-backs MotokoGold tokens & burn.
  • ICP/MotokoGold airdrops.
  • Staking MotokoGold neurons with great reward-rate for the early MotokoGold adopters (90% to 0.25% in 4 years).
  • New NFT standard Golden Motoko Collection only possible to buy using motoko gold tokens.

Key Considerations:

  • This initiative, like everything built on the Internet Computer is very new and experimental. If you are unsure about risking your ICP, please refrain from participating. The team is NOT responsible for any losses incurred if things do not go as planned.
  • We are a 100% engineering high-commited team. We will do our best to increase value of this community. Our main focus is building.
  • Community support and self-organization to spread the word about the project are encouraged.
  • We love ICP and we’re here to stay. Will be developments and surprises. Happy 3erd ICP Anniversary and enjoy catching a golden Motoko.

Best of luck to all of you ICP family.

MotokoGold Team.

1 Like

meme

2 Likes

Is the US participating? Or being left out again?

1 Like

Hi @Gideonn1313 , initially the MotokoGold DAO launch will be closed for the following countries:

  • 0"US"
  • 1"AF"
  • 2"BF"
  • 3"CH"
  • 4"CI"
  • 5"CU"
  • 6"IR"
  • 7"ML"
  • 8"MZ"
  • 9"MM"
  • 10"NF"
  • 11"SD"
  • 12"SS"
  • 13"SY"
  • 14"VE"
  • 15"YE"

However, a few days after the successful completion of the SNS launch and DAO creation, we will make a proposal to accept and deploy a secondary market exclusively for upselling, where you can acquire MotokoGold starting at the same final price as at the end of the SNS Launch.

Here’s a sneak peek.

In case anybody here wants to have more information about our plans, we’ve just opened our X @MotokoGold https://x.com/MotokoGold.

You can visit the site on: https://tkiah-yqaaa-aaaag-qjwpa-cai.icp0.io/ After the SNS launch is completed we will start making proposals to update the frontend and backend in order to complete functionalities and if DAO vote yes we’ll add 1:1 swap MTG-MOTOKO and an only-up swap second market were people will be able to join our DAO buying MotokoGold SNS tokens.

Hi @MotokoGold team,

We see that you already submitted the proposal to the NNS: NNS Dapp.

Please note that DFINITY will reject this proposal under our published voting guidelines.

The syndication on the forum including publishing of a whitepaper, architecture, open source code, and SNS parameters (ideally the SNS init yaml file) should start at least 2 weeks prior to the proposal to give the community enough time to review and discuss.

In addition, we added an explicit amendment to the guidelines regarding higher standards for projects that request Neuron Fund (NF) contributions:

2 Likes

Hi @domwoe! Oh I see, thanks for your comment.

Just I’ll provide our overview on this matter.

  • We can open up some more information, sure thing. We’re not doing this for free, we’re launching a DAO for profit here, it’s a memecoin with utility that aims over time to become a DAO driven investment fund if the proposal pass.

  • Dfinity technical documentation is outdated & you should review that please, it was very challenging cause dfx and quill versions incompatibilities are not explained anywhere in the internetcomputer.org guidelines and we’re a super high-level engineering team with experience developing software in the web2 fintech industry for more than 14 years.

  • We have our own path, we’ve overcome this milestone to launch the proposal, we finally understood all the process of the NNS interactions and that was the primary objective. So we’re fine if the proposal gets rejected.

  • Dfinity needs Marketing. Projects like ours have that as one of the main lines where we could add value.

  • We are not a competition of the Original Motoko DAO, we waited for them to launch, I didn’t see a whitepaper from them, but I didn’t care, I know people behind the project they have great intentions and we wish them good luck. Anyway we’re a different thing here.

  • About opening up key functionality of stage 1 is here were you can find the code to manage the swap function we proposed to optionally invite the 1:1 OriginalMotoko DAO Community, every Motoko SNS received would be sent to the DAO treasury. After the DAO is created, we were planning to make different kind of proposals in order to Upgrade the SNS, update the frontend and backend functionalities to link the new SNS MotokoGold token.

#[update]
async fn swap(args: FunctionArguments) -> Result<FunctionResponse, String>  {
    let caller = ic_cdk::api::caller();
    let icrc1_token = args.icrc1_token;
    let ledger_tokens = read_state(|state| state.data.ledger.token_prices.clone());
    let token_price = if let Some(price) = ledger_tokens.get(&icrc1_token) {
        price
    } else {
        return Err("ICRC1 Token not configured".to_string());
    };
    let motoko_gold_token = match read_state(|state| state.data.motoko_sns) {
        Some(token) => token,
        None => return Err("motoko_sns token not found".to_string()),
    };
    let (motoko_fee,): (Nat,) = call(
        icrc1_token,
        "icrc1_fee",
        (),
    )
    .await
    .map_err(|e| format!("Call failed: {:?}", e))?;
    let (motoko_gold_fee,): (Nat,) = call(
        motoko_gold_token,
        "icrc1_fee",
        (),
    )
    .await
    .map_err(|e| format!("Call failed: {:?}", e))?;
    let (balance_of_result,): (Nat,) = call(
        icrc1_token,
        "icrc1_balance_of",
        (Account { owner: api::id(), subaccount: args.subaccount },),
    )
    .await
    .map_err(|e| format!("Call failed: {:?}", e))?;
    let call_result_1: CallResult<(Result<Nat, TransferError>,)> = call(
        icrc1_token,
        "icrc1_transfer",
        (TransferArgs {
            to: Account { owner: api::id(), subaccount: None },
            amount: balance_of_result.clone() - motoko_fee,
            from_subaccount: args.subaccount
        },),
    ).await;
    match call_result_1 {
        Ok((Ok(_),)) => {},
        Ok((Err(e),)) => return Err(format!("Transfer from Motoko token failed: {:?}", e)),
        Err(e) => return Err(format!("Call for transferring Motoko token failed: {:?}", e)),
    };
    let motoko_gold_amount = (balance_of_result.clone() / token_price.clone()) - motoko_gold_fee;
    let call_result_2: CallResult<(Result<Nat, TransferError>,)> = call(
        motoko_gold_token,
        "icrc1_transfer",
        (TransferArgs {
            to: Account { owner: caller, subaccount: None },
            amount: motoko_gold_amount,
            from_subaccount: None
        },),
    ).await;
    match call_result_2 {
        Ok((Ok(_),)) => {}, 
        Ok((Err(e),)) => return Err(format!("Transfer to SNS token failed: {:?}", e)),
        Err(e) => return Err(format!("Call for transferring SNS token failed: {:?}", e)),
    };
    Ok(FunctionResponse {})
}

Here you will find the yaml file, but as you see, you can also find it in the proposal:

# You should make a copy of this file, name it sns_init.yaml, and edit it to
# suit your needs.
#
# All principal IDs should almost certainly be changed.
#
# In this file, 1 year is nominally defined to be 365.25 days.
#
# This gets passed to `sns propose`. See propose_sns.sh.
#
# This follows the second configuration file format developed for the `sns`
# CLI. The first format will be supported for a time, but this format will
# eventually become the standard format.
# ------------------------------------------------------------------------------
# UNITS
#
# This SNS configuration file version allows specifying the various
# fields with units that make configuration easier. For instance,
# in the previous version, all fields relating to token values
# had to be specified in e8s (fractions of 10E-8 of a governance token).
# In this version, similar fields can be specified in whole tokens,
# tokens with decimals, or e8s. Below is more information on the type
# of units that can be used.
#
# For fields that represent token values (such as `transaction_fee`
# or `rejection_fee`), devs can specify decimal strings ending in
# "tokens" (plural), decimal strings ending in "token" (singular),
# or integer strings (base 10) ending in "e8s". In the case of
# "tokens" strings, the maximum number of digits after the (optional)
# decimal point is 8. The "_" character may be sprinkled throughout.
# Whitespace around number is insignificant. E.g. " 42 tokens" is
# equivalent to "42tokens".
#
# For fields that represent duration values (such as `initial_voting_period`
# or `minimum_dissolve_delay`), devs can specify durations as a concatenation
# of time spans. Where each time span is an integer number and a suffix.
# Supported suffixes:
#  - seconds, second, sec, s
#  - minutes, minute, min, m
#  - hours, hour, hr, h
#  - days, day, d
#  - weeks, week, w
#  - months, month, M -- defined as 30.44 days
#  - years, year, y -- defined as 365.25 days
#
# For example, "1w 2d 3h" gets parsed as
#
# 1 week + 2 days + 3 hours
#    =
# (1 * (7 * 24 * 60 * 60) + 2 * 24 * 60 * 60 + 3 * (60 * 60)) seconds
#
# For fields that represent percentage values (such as `bonus`), devs specify
# the value as an integer with a trailing percent sign ('%'). For example,
# `10%`.
#
# For fields that represent time of day (such as `start_time`), devs specify
# the value as a string in form "hh::mm UTC". Where hh is hour, and mm is minute.
# Only the UTC timezone is currently supported.
# ------------------------------------------------------------------------------

# Name of the SNS project. This may differ from the name of the associated
# token. Must be a string of max length = 255.
name: Motoko Gold

# Description of the SNS project.
# Must be a string of max length = 2,000.
description: >
   The Motoko Golden Brother. Only up by design.

# This is currently a placeholder field and must be left empty for now.
Principals: []

# Path to the SNS Project logo on the local filesystem. The path is relative
# to the configuration file's location, unless an absolute path is given.
# Must have less than 341,334 bytes. The only supported format is PNG.
logo: logo.png

# URL to the dapp controlled by the SNS project.
# Must be a string from 10 to 512 bytes.
url: https://tkiah-yqaaa-aaaag-qjwpa-cai.icp0.io/

# Metadata for the NNS proposal required to create the SNS. This data will be
# shown only in the NNS proposal.
NnsProposal:
    # The title of the NNS proposal. Must be a string of 4 to 256 bytes.
    title: "NNS Proposal to create an SNS named 'Motoko Gold'"

    # The HTTPS address of additional content required to evaluate the NNS
    # proposal.
    url: "https://forum.dfinity.org/t/the-motoko-golden-brother-dao-motoko-gold-coming-to-nns-happening-now/30630"

    # The description of the proposal. Must be a string of 10 to 2,000 bytes.
    summary: >
        
        Welcome to the the Motoko Golden DAO foundation. Our goal is to become the promised land for ICP early adopters where growth and value are the norm.
        You may perceive this project as DAO-driven-investment-fund focus 100% on the Internet Computer Blockchain ecosystem.
        
        The initial distribution will be as follows:
        - 2,600 MotokoGold will be available for the SNS Sale.
        - 6,000 MotokoGold will be locked in the DAO Controlled Treasury.
        - 1,400 MotokoGold will be allocated for the team.
         
        Motoko Gold go to market plan:
         - Provide liquidity to MotokoGold/ICP pair to establish a strong liquidity pool on dexes like ICPSwap, Sonic.ooo or ICLight.
         - Stake 8-year neuron to leverage the unique ICP capabilities.
         - 1,000 Motoko GOLD 1:1 Motoko SNS swap (Ready after launch following day)
         - Only-Up secondary market treasury dao driven orderbook (Currently under development).

        Depending on the adoption of this proposal we are planning to extend the roadmap of Motoko Gold DAO to CEX listing initiatives, paid media marketing, dpools, trading utilities and more, like:
         - Buy-backs MotokoGold tokens & burn.
         - ICP/MotokoGold airdrops.
         - Staking MotokoGold neurons with great reward-rate for the early MotokoGold adopters (90% to 0.25% in 4 years).
         - New NFT standard Golden Motoko Collection only possible to buy using motoko gold tokens.

        Key Considerations:
         - This initiative, like everything built on the Internet Computer is very new and experimental. If you are unsure about risking your ICP, please refrain from participating. The team is NOT responsible for any losses incurred if things do not go as planned.
         - We are a 100% engineering high-commited team. We will do our best to increase value of this community. Our main focus is building.
         - Community support and self-organization to spread the word about the project are encouraged.
         - We love ICP and we're here to stay. Will be developments and surprises. Happy 3erd #ICP Anniversary and enjoy catching a golden Motoko.
        

# If the SNS launch attempt fails, control over the dapp canister(s) is given to
# these principals. In most use cases, this is chosen to be the original set of
# controller(s) of the dapp. Must be a list of PrincipalIds.
fallback_controller_principals:
    # For the actual SNS launch, you should replace this with one or more
    # principals of your intended fallback controllers.
    #
    # For testing, propose_sns.sh will fill this in automatically.
#    - YOUR_PRINCIPAL_ID
    - tzfzz-d53nw-kcugq-nhsxj-hodle-mlla7-b7beb-hwwqi-32um6-t24t6-iae
    - sluco-pkvqw-exbpl-tlray-3bb4v-ltikh-ll76w-kne2b-6hxrg-3kvvo-hae

# The list of dapp canister(s) that will be decentralized if the
# decentralization swap succeeds. These are defined in the form of canister IDs,
# for example, `bnz7o-iuaaa-aaaaa-qaaaa-cai`.  For a successful SNS launch,
# these dapp canister(s) must be co-controlled by the NNS Root canister
# (`r7inp-6aaaa-aaaaa-aaabq-cai`) at latest at the time when the NNS proposal to
# create an SNS is adopted (usually this is required even earlier, e.g., to
# convince NNS neurons to vote in favor of your proposal).
dapp_canisters:
    # For the actual SNS launch, you should replace this with one or more
    # IDs of the canisters comprising your to-be-decentralized dapp.
    #
    # For testing, propose_sns.sh will fill this in automatically.
#    - YOUR_CANISTER_ID
    - tkiah-yqaaa-aaaag-qjwpa-cai
    - efdsd-cqaaa-aaaag-qjvta-cai

# Configuration of SNS tokens in the SNS Ledger canister deployed as part
# of the SNS.
Token:
    # The name of the token issued by the SNS ledger.
    # Must be a string of 4 to 255 bytes without leading or trailing spaces.
    name: MotokoGold
    # The symbol of the token issued by the SNS Ledger.
    # Must be a string of 3 to 10 bytes without leading or trailing spaces.
    symbol: MTG

    # SNS ledger transaction fee.
    transaction_fee: 100 e8s

    # Path to the SNS token logo on your local filesystem. The path is relative
    # to the configuration file location, unless an absolute path is given.
    # Must have less than 341,334 bytes. The only supported format is PNG.
    logo: logo.png

# Configures SNS proposal-related fields. These fields define the initial values
# for some of the nervous system parameters related to SNS proposals. This will
# not affect all SNS proposals submitted to the newly created SNS.
Proposals:
    # The cost of making an SNS proposal that is rejected by the SNS neuron
    # holders. This field is specified as a token. For example: "1 token".
    rejection_fee: 0.0001 token

    # The initial voting period of an SNS proposal. A proposal's voting period
    # may be increased during its lifecycle due to the wait-for-quiet algorithm
    # (see details below). This field is specified as a duration. For example
    # "4 days".
    initial_voting_period: 3 days

    # The wait-for-quiet algorithm extends the voting period of a proposal when
    # there is a flip in the majority vote during the proposal's voting period.
    #
    # Without this, there could be an incentive to vote right at the end of a
    # proposal's voting period, in order to reduce the chance that people will
    # see and have time to react to that.
    #
    # If this value is set to 1 day, then a change in the majority vote at the
    # end of a proposal's original voting period results in an extension of the
    # voting period by an additional day. Another change at the end of the
    # extended period will cause the voting period to be extended by another
    # half-day, etc.
    #
    # The total extension to the voting period will never be more than twice
    # this value.
    #
    # For more information, please refer to
    # https://wiki.internetcomputer.org/wiki/Network_Nervous_System#Proposal_decision_and_wait-for-quiet
    #
    # This field is specified as a duration. For example: "1 day".
    maximum_wait_for_quiet_deadline_extension: 1 day

# Configuration of SNS voting.
Neurons:
    # The minimum amount of SNS tokens to stake a neuron. This field is specified
    # as a token. For instance, "1 token".
    minimum_creation_stake: 0.0001 tokens

# Configuration of SNS voting.
Voting:
    # The minimum dissolve delay a neuron must have to be able to cast votes on
    # proposals.
    #
    # Dissolve delay incentivizes neurons to vote in the long-term interest of
    # an SNS, as they are rewarded for longer-term commitment to that SNS.
    #
    # Users cannot access the SNS tokens used to stake neurons (until the neuron
    # is dissolved). This field is specified as a duration. For example: "6 months".
    minimum_dissolve_delay: 3 month

    # Configuration of voting power bonuses that are applied to neurons to
    # incentivize alignment with the best interest of the DAO. Note, these
    # bonuses multiply each other, so the increase in voting power due to
    # the dissolve delay bonus is used in the equation to increase voting
    # power for the age bonus.
    MaximumVotingPowerBonuses:
        # Users with a higher dissolve delay are incentivized to take the
        # long-term interests of the SNS into consideration when voting. To
        # reward this long-term commitment, this bonus can be set to a
        # percentage greater than zero, which will result in neurons having
        # their voting power increased in proportion to their dissolve delay.
        #
        # For example, if the user has a dissolve delay of 6 months, and
        # the maximum dissolve delay duration (defined below as `duration`)
        # for the dissolve delay bonus is 12 months, and the maximum bonus
        # (defined as `bonus` below) is set to 10%, then that user’s voting
        # power will be 105% of their normal voting power based on staked
        # tokens (i.e. they will have a bonus of 5%). If the user increased
        # their dissolve delay to 9 months, they would get 107.5% of the normal
        # voting power of their tokens. And if they increased to 12 months, they
        # would get 110%. If they increase further, they get no additional bonus.
        #
        # If you do not want this bonus to be applied for neurons with higher
        # dissolve delay, set `bonus` to `0%` and those neurons will not receive
        # higher voting power.
        DissolveDelay:
            # This parameter sets the maximum dissolve delay a neuron can have.
            # When reached, the maximum dissolve delay bonus will be applied.
            # This field is specified as a duration. For example: "8 years".
            duration: 5 years
            # If a neuron's dissolve delay is `duration`, its voting power will
            # be increased by the dissolve delay `bonus` amount. 
            # This field is specified as a percentage. For instance, 
            # a value of "100%" means that the voting power will be doubled
            # (multiplied by 2).
            bonus: 90%

        # Users with neurons staked in the non-dissolving state for a long
        # period of time are incentivized to take the long-term interests of
        # the SNS into consideration when voting. To reward this long-term
        # commitment, this bonus can be set to a percentage (greater than zero),
        # which will result in neurons having their voting power increased in
        # proportion to their age.
        #
        # For example, if the neuron has an age of 6 months, and the maximum age
        # duration (defined below as `duration`) for the age bonus is 12 months,
        # and the maximum bonus (defined as `bonus` below) is set to 10%, then
        # that neuron’s voting power will be 105% of their normal voting power
        # based on staked tokens plus dissolve delay bonus (i.e. they will have a
        # bonus of 5%). If neuron aged another 3 months to have an age of 9 months,
        # the neuron would get 107.5% of the normal voting power. And if the neuron
        # aged another 3 months to 12 months, the neuron would get 110%. If the neuron
        # ages further, it get no additional bonus.
        #
        # If this bonus should not be applied for older neurons, set the bonus
        # to `0%` and older neurons will not receive higher voting power.
        Age:
            # This parameter sets the duration of time the neuron must be staked
            # in the non-dissolving state, in other words its `age`, to reach
            # the maximum age bonus. Once this age is reached, the neuron will
            # continue to age, but no more bonus will be applied. This field
            # is specified as a duration. For example: "2 years".
            duration: 5 years
            # If a neuron's age is `duration` or older, its voting power will be
            # increased by this age`bonus` amount. 
            # This field is specified as a percentage. For instance, 
            # a value of "25%" means that the voting power will increase by a quarter
            # (multiplied by 1.25).
            bonus: 50%

    # Configuration of SNS voting reward parameters.
    #
    # The voting reward rate controls how quickly the supply of the SNS token
    # increases. For example, setting `initial` to `2%` will cause the supply to
    # increase by at most `2%` per year. A higher voting reward rate
    # incentivizes users to participate in governance, but also results in
    # higher inflation.
    #
    # The initial and final reward rates can be set to have a higher reward rate
    # at the launch of the SNS and a lower rate further into the SNS’s lifetime.
    # The reward rate falls quadratically from the `initial` rate to the `final`
    # rate over the course of `transition_duration`.
    #
    # Setting both `initial` and `final` to `0%` will result in the system not
    # distributing voting rewards at all.
    #
    # More details on SNS tokenomics can be found in the developer documentation:
    # https://internetcomputer.org/docs/current/developer-docs/integrations/sns/tokenomics/rewards/#voting-rewards
    RewardRate:
        # The initial reward rate at which the SNS voting rewards will increase
        # per year. This field is specified as a percentage. For example: "15%".
        initial: 90%

        # The final reward rate at which the SNS voting rewards will increase
        # per year. This rate is reached after `transition_duration` and remains
        # at this level unless changed by an SNS proposal. This field is
        # specified as a percentage. For example: "5%".
        final: 0.25%

        # The voting reward rate falls quadratically from `initial` to `final`
        # over the time period defined by `transition_duration`.
        #
        # Values of 0 result in the reward rate always being `final`.
        #
        # This field is specified as a duration. For example: "8 years".
        transition_duration: 4 years

# Configuration of the initial token distribution of the SNS. You can configure
# how SNS tokens are distributed in each of the three groups:
# (1) tokens that are given to the original developers of the dapp,
# (2) treasury tokens that are owned by the SNS governance canister, and
# (3) tokens which are distributed to the decentralization swap participants.
#
# The initial token distribution must satisfy the following preconditions to be
# valid:
#    - The sum of all developer tokens in E8s must be less than `u64::MAX`.
#    - The Swap's initial balance (see group (3) above) must be greater than 0.
#    - The Swap's initial balance (see group (3) above) must be greater than or
#      equal to the sum of all developer tokens.
Distribution:
    # The initial neurons created when the SNS Governance canister is installed.
    # Each element in this list specifies one such neuron, including its stake,
    # controlling principal, memo identifying this neuron (every neuron that
    # a user has must be identified by a unique memo), dissolve delay, and a
    # vesting period. Even though these neurons are distributed at genesis,
    # they are locked in a (restricted) pre-initialization mode until the
    # decentralization swap is completed. Note that `vesting_period` starts
    # right after the SNS creation and thus includes the pre-initialization mode
    # period.
    #
    # For example:
    #  - principal: hpikg-6exdt-jn33w-ndty3-fc7jc-tl2lr-buih3-cs3y7-tftkp-sfp62-gqe
    #    stake: 1_000 tokens
    #    memo: 0
    #    dissolve_delay: 2 years
    #    vesting_period: 4 years
    Neurons:
        # For the actual SNS launch, you should replace this with one or more
        # principals of your intended genesis neurons.
        #
        # For testing, propose_sns.sh will fill this in automatically.
#        - principal: YOUR_PRINCIPAL_ID
        - principal: sluco-pkvqw-exbpl-tlray-3bb4v-ltikh-ll76w-kne2b-6hxrg-3kvvo-hae
          stake: 350 tokens
          memo: 0
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: ksbqq-arh2k-csjj7-tcrhk-zp4pi-5kjlf-kzjcr-4bizs-lktqr-7zjnf-tqe
          stake: 350 tokens
          memo: 1
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: 5vsuw-un25d-crm7h-5pcov-iry22-msinr-2bdef-6jtqu-ak4ca-kitao-uqe
          stake: 350 tokens
          memo: 2
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: ghhh6-265d7-xoqhd-gkwh2-6hsnj-ue7ly-xu5d6-n2etm-sk6jj-adu3p-qqe
          stake: 350 tokens
          memo: 3
          dissolve_delay: 1 years
          vesting_period: 0 years


    # The initial SNS token balances of the various canisters of the SNS.
    InitialBalances:
        # The initial SNS token balance of the SNS Governance canister is known
        # as the treasury. This is initialized in a special sub-account, as the
        # main account of Governance is the minting account of the SNS Ledger.
        # This field is specified as a token. governance: 16_000 tokens
        governance: 6_000 token

        # The initial SNS token balance of the Swap canister is what will be
        # available for the decentralization swap. These tokens will be swapped
        # for ICP. This field is specified as a token. For instance, "1 token".
        swap: 2_600 tokens

    # Checksum of the total number of tokens distributed in this section.
    # This field is specified as a token. For instance, "1 token".
    #          1_000    (neuron)
    #      2 million    (governance)
    # + 500 thousand    (swap)
    # --------------
    total: 10_000 tokens

# Configuration of the decentralization swap parameters. Choose these parameters
# carefully, if a decentralization swap fails, the SNS will restore the dapp
# canister(s) to the fallback controllers (defined in
# `fallback_controller_principals`) and you will need to start over.
Swap:
    # The minimum number of direct participants that must participate for the
    # decentralization swap to succeed. If a decentralization swap finishes due
    # to the deadline or the maximum target being reached, and if there are less
    # than `minimum_participants` (here, only direct participants are counted),
    # the swap will be committed.
    minimum_participants: 10

    # Minimum amount of ICP from direct participants. This amount is required for
    # the swap to succeed. If this amount is not achieved, the swap will be
    # aborted (instead of committed) when the due date/time occurs.
    # Must be smaller than or equal than `maximum_direct_participation_icp`.
    minimum_direct_participation_icp: 1_000 tokens

    # Maximum amount of ICP from direct participants. If this amount is achieved,
    # the swap will finalize immediately, without waiting for the due date/time;
    # in this case, the swap would be committed if and only if the number of
    # direct participants (`minimum_participants`) is reached (otherwise, it
    # would be aborted).
    # Must be at least `min_participants * minimum_direct_participation_icp`.
    maximum_direct_participation_icp: 90_000 tokens

    # The minimum amount of ICP that each participant must contribute
    # to participate. This field is specified as a token. For instance,
    # "1 token".
    minimum_participant_icp: 1 tokens

    # The maximum amount of ICP that each participant may contribute
    # to participate. This field is specified as a token. For instance,
    # "1 token".
    maximum_participant_icp: 1_000 tokens

    # The text that swap participants must confirm before they may participate
    # in the swap.
    #
    # This field is optional. If set, must be within 1 to 1,000 characters and
    # at most 8,000 bytes.
    # confirmation_text: >
    #     I confirm my understanding of the responsibilities and risks
    #     associated with participating in this token swap.

    # A list of countries from which swap participation should not be allowed.
    #
    # This field is optional. By default, participants from all countries
    # are allowed.
    #
    # Each list element must be an ISO 3166-1 alpha-2 country code.
    restricted_countries:
        - US 
        - AF
        - BF
        - CH
        - CI
        - CU 
        - IR 
        - ML 
        - MZ
        - MM 
        - NF 
        - SD 
        - SS 
        - SY
        - VE 
        - YE 


    # Configuration of the vesting schedule of the neuron basket, i.e., the SNS
    # neurons that a participants will receive from a successful
    # decentralization swap.
    VestingSchedule:
        # The number of events in the vesting schedule. This translates to how
        # many neurons will be in each participant's neuron basket. Note that
        # the first neuron in each neuron basket will have zero dissolve delay.
        # This value should thus be greater than or equal to `2`.
        events: 2

        # The interval at which the schedule will be increased per event. The
        # first neuron in the basket will be unlocked with zero dissolve delay.
        # Each other neuron in the schedule will have its dissolve delay
        # increased by `interval` compared to the previous one. For example,
        # if `events` is set to `3` and `interval` is `1 month`, then each
        # participant's neuron basket will have three neurons (with equal stake)
        # with dissolve delays zero, 1 month, and 2 months. Note that the notion
        # of `Distribution.neurons.vesting_period` applies only to developer
        # neurons. While neuron basket neurons do not use `vesting_period`, they
        # have a vesting schedule. This field is specified as a duration. For
        # example: "1 month".
        interval: 1 month

    # Absolute time of day when the decentralization swap is supposed to start.
    #
    # An algorithm will be applied to allow at least 24 hours between the time
    # of execution of the CreateServiceNervousSystem proposal and swap start.
    # For example, if start_time is 23:30 UTC and the proposal is adopted and
    # executed at 23:20 UTC, then the swap start will be at 23:30 UTC the next
    # day (i.e., in 24 hours and 10 min from the proposal execution time).
    #
    # WARNING: Swap start_time works differently on mainnet and in testing.
    #
    # On mainnet:
    # - Setting start_time to some value (e.g., 23:30 UTC) will allow the swap
    #   participants to be prepared for the swap in advance, e.g.,
    #   by obtaining ICPs that they would like to participate with.
    # - If start_time is not specified, the actual start time of the swap will
    #   be chosen at random (allowing at least 24 hours and less than 48 hours,
    #   as described above).
    #
    # In testing:
    # - Setting start_time to some value works the same as explained above.
    # - If start_time is not specified, the swap will begin immediately after
    #   the CreateServiceNervousSystem proposal is executed. This facilitates
    #   testing in an accelerated manner.
    #
    # start_time: 23:30 UTC  # Intentionally commented out for testing.

    # The duration of the decentralization swap. When `start_time` is calculated
    # during CreateServiceNervousSystem proposal execution, this `duration` will
    # be added to that absolute time and set as the swap's deadline.
    duration: 10 days

    # Whether Neurons' Fund participation is requested.
    neurons_fund_participation: true

It’s much easier not becoming a DAO, we can build in any ecosystem, if we want to create a memecoin we can create a non-DAO driven canister or go to others blockchains, much easier by far and in other blockchains much more adoption buy far too, but less fun. And also we’re here for the tech.

We will never do the things as others, we just focus on software evolution across time.

Whatever happens, happens,

It was also our way to wish you guys happy 3erd anniversary #ICP.

Best Regards,

MotokoGold Team.

This may not have been intentional, but the way that this SNS is configured, direct participants and the Neurons’ Fund will have 0 voting power when the SNS launches, giving the developer neurons 100% of the voting power and the ability to pass any proposals that they wish, including Transfer SNS Treasury Funds proposals. This is because non-developer neurons will have at most a 1-month dissolve delay at launch (see Vesting Schedule above), but the minimum dissolve delay to vote is 3 months (see minimum_dissolve_delay above).

This is a major red flag.

See here for details about the rate at which the ICP treasury of an SNS can be drained.

1 Like

Great question. A little deterred seeing recent NNS proposals not available in the US.

1 Like

Hello Dylan, if is so as you called it a MAJOR RED FLAG why do you allow that in the settings to pass through with that configuration in the first place?

It’s nonsense from your side. If we would want doing something wrong we would find a spot in Solana memespace, or somewhere else.

We created that configuration because we would NOT wanted to have the people who participate with their MotokoGold tokens locked in 4-5 neurons for a long period of time without letting them the choice.

I understand you’re trying to protect the community but you cannot be that scared. We need some flexibility to start building things.

Just to let you know, our first 4 proposals planned ready for next week launching were these ones:

  • SNS Upgrade

  • Transfer 1,000 MotokoGold to a DAO controlled to open the 1:1 Swap Motoko SNS - MotokoGold

  • Update Frontend to deploy a new section: Only Upselling ICP-MTG

  • Update Backend to deploy functionality section: Only Upselling swap ICP-MTG

  • Transfer 3,000 MotokoGold to a DAO controlled to open the Upselling Swap ICP - MotokoGold

  • Start upselling.

But this is no new information, it’s just as in the proposals is described.

Best Regards.

Please let me know where the instructions are outdated if possible.

Note that there are alternatives to the SNS to launch a token ICP, e.g.
https://icto.app/ and upcoming Fomowell.

If you want to go the SNS route, then you should at least remove the request from the Neurons Fund and make it very clear to everybody that this won’t be decentralized initially, and participants need to fully trust you.

1 Like

Seems like a massive scam lol

Henry have you ever develop software? This is not just an ERC20 token. This a complete dapp built on RUST using ReactJS additionally managing low-level programming languages. What a joke. :joy:

You know what @domwoe,

Thank you for the links you’re sharing, I will take a look.

About the documentation, I swear to you that it have been a pain to develop software on InternetComputer, all my team was complaining about the lack of clarity of the docs. For instance, try to run this process without knowing your inside information about what dfx quill versions works for each command. Commands & actions to go through SNS launch | Internet Computer (Check the questions on the forums too)

I know it’s hard to keep updated the massive amount of technical documentation internetcomputer.org has, but it’s a weakness to bring more developers into the ecosystem. Just saying.
The most important and frequent journeys should be up to date and black testing the step by step without pre-configured local environment from your people.
Example following instructions on your documentation everyone should be able to: 1) Set up a fully working clean local environment 2) Deploy a new canister 3) Deploy a SNS proposal to NNS should be a path super-tested on your end.

In the other hand, I understand and agree with you and the community about the introduction of the project has not been cared on our side as it should be, that respond to reasons on that we’re focus on building sofware, what we’re going to keep doing it.

However, I think you are right. We’re probably changing the scope of the project. Maybe initially we will launch out of the NNS for a while. We won’t be able to dao-control some things as we wanted but maybe in another stage we’ll revisit this idea of launching NNS.

Best Regards and happy 3erd anniversary friends.

MotokoGold Team.

Thank you for the feedback.

The testing, launching, and operating of an SNS has definitely its complexities, and also experienced developers in the ecosystem have struggled :sweat_smile:. However, the goal of the SNS is first and foremost to decentralize apps that already have found product market fit, i.e. there are typically at least a few months between initially deploying a canister and preparing an SNS launch. Nevertheless, I agree that it needs to be a smoother experience.

2 Likes

Sure thing @domwoe .

Look we just finished a team meeting about the stage of the project. There are some utilities that we would love to leverage from NNS like DAO control neuron rewards and an on-chain dao controlled oracle trading.

To keep this project running would you mind to review this SNS yaml and share with us if you think we could re-submit the project to keep our roadmap ongoing or if under your view it’s better to full pivoting the scope.

Thanks for answering and your time in here, it’s appreciated.

# You should make a copy of this file, name it sns_init.yaml, and edit it to
# suit your needs.
#
# All principal IDs should almost certainly be changed.
#
# In this file, 1 year is nominally defined to be 365.25 days.
#
# This gets passed to `sns propose`. See propose_sns.sh.
#
# This follows the second configuration file format developed for the `sns`
# CLI. The first format will be supported for a time, but this format will
# eventually become the standard format.
# ------------------------------------------------------------------------------
# UNITS
#
# This SNS configuration file version allows specifying the various
# fields with units that make configuration easier. For instance,
# in the previous version, all fields relating to token values
# had to be specified in e8s (fractions of 10E-8 of a governance token).
# In this version, similar fields can be specified in whole tokens,
# tokens with decimals, or e8s. Below is more information on the type
# of units that can be used.
#
# For fields that represent token values (such as `transaction_fee`
# or `rejection_fee`), devs can specify decimal strings ending in
# "tokens" (plural), decimal strings ending in "token" (singular),
# or integer strings (base 10) ending in "e8s". In the case of
# "tokens" strings, the maximum number of digits after the (optional)
# decimal point is 8. The "_" character may be sprinkled throughout.
# Whitespace around number is insignificant. E.g. " 42 tokens" is
# equivalent to "42tokens".
#
# For fields that represent duration values (such as `initial_voting_period`
# or `minimum_dissolve_delay`), devs can specify durations as a concatenation
# of time spans. Where each time span is an integer number and a suffix.
# Supported suffixes:
#  - seconds, second, sec, s
#  - minutes, minute, min, m
#  - hours, hour, hr, h
#  - days, day, d
#  - weeks, week, w
#  - months, month, M -- defined as 30.44 days
#  - years, year, y -- defined as 365.25 days
#
# For example, "1w 2d 3h" gets parsed as
#
# 1 week + 2 days + 3 hours
#    =
# (1 * (7 * 24 * 60 * 60) + 2 * 24 * 60 * 60 + 3 * (60 * 60)) seconds
#
# For fields that represent percentage values (such as `bonus`), devs specify
# the value as an integer with a trailing percent sign ('%'). For example,
# `10%`.
#
# For fields that represent time of day (such as `start_time`), devs specify
# the value as a string in form "hh::mm UTC". Where hh is hour, and mm is minute.
# Only the UTC timezone is currently supported.
# ------------------------------------------------------------------------------

# Name of the SNS project. This may differ from the name of the associated
# token. Must be a string of max length = 255.
name: Motoko Gold

# Description of the SNS project.
# Must be a string of max length = 2,000.
description: >
   The Motoko Golden Brother. Only up by design.

# This is currently a placeholder field and must be left empty for now.
Principals: []

# Path to the SNS Project logo on the local filesystem. The path is relative
# to the configuration file's location, unless an absolute path is given.
# Must have less than 341,334 bytes. The only supported format is PNG.
logo: logo.png

# URL to the dapp controlled by the SNS project.
# Must be a string from 10 to 512 bytes.
url: https://tkiah-yqaaa-aaaag-qjwpa-cai.icp0.io

# Metadata for the NNS proposal required to create the SNS. This data will be
# shown only in the NNS proposal.
NnsProposal:
    # The title of the NNS proposal. Must be a string of 4 to 256 bytes.
    title: "NNS Proposal to create an SNS named 'Motoko Gold'"

    # The HTTPS address of additional content required to evaluate the NNS
    # proposal.
    url: "https://forum.dfinity.org/t/the-motoko-golden-brother-dao-motoko-gold-coming-to-nns-happening-now/30630"

    # The description of the proposal. Must be a string of 10 to 2,000 bytes.
    summary: >
        
        Welcome to the the Motoko Golden DAO foundation. Our goal is to become the promised land for ICP early adopters where growth and value are the norm.
        You may perceive this project as DAO-driven-investment-fund focus 100% on the Internet Computer Blockchain ecosystem.
        
        The initial distribution will be as follows:
        - 2,600 MotokoGold will be available for the SNS Sale.
        - 6,000 MotokoGold will be locked in the DAO Controlled Treasury.
        - 1,400 MotokoGold will be allocated for the team.
         
        Motoko Gold go to market plan:
         - Provide liquidity to MotokoGold/ICP pair to establish a strong liquidity pool on dexes like ICPSwap, Sonic.ooo or ICLight.
         - Stake 8-year neuron to leverage the unique ICP capabilities.
         - 1,000 Motoko GOLD 1:1 Motoko SNS swap (Ready after launch following day)
         - Only-Up secondary market treasury dao driven orderbook (Currently under development).

        Depending on the adoption of this proposal we are planning to extend the roadmap of Motoko Gold DAO to CEX listing initiatives, paid media marketing, dpools, trading utilities and more, like:
         - Buy-backs MotokoGold tokens & burn.
         - ICP/MotokoGold airdrops.
         - Staking MotokoGold neurons with great reward-rate for the early MotokoGold adopters (90% to 0.25% in 4 years).
         - New NFT standard Golden Motoko Collection only possible to buy using motoko gold tokens.

        Key Considerations:
         - This initiative, like everything built on the Internet Computer is very new and experimental. If you are unsure about risking your ICP, please refrain from participating. The team is NOT responsible for any losses incurred if things do not go as planned.
         - We are a 100% engineering high-commited team. We will do our best to increase value of this community. Our main focus is building.
         - Community support and self-organization to spread the word about the project are encouraged.
         - We love ICP and we're here to stay. Will be developments and surprises. Happy 3erd #ICP Anniversary and enjoy catching a golden Motoko.
        

# If the SNS launch attempt fails, control over the dapp canister(s) is given to
# these principals. In most use cases, this is chosen to be the original set of
# controller(s) of the dapp. Must be a list of PrincipalIds.
fallback_controller_principals:
    # For the actual SNS launch, you should replace this with one or more
    # principals of your intended fallback controllers.
    #
    # For testing, propose_sns.sh will fill this in automatically.
#    - YOUR_PRINCIPAL_ID
    - tzfzz-d53nw-kcugq-nhsxj-hodle-mlla7-b7beb-hwwqi-32um6-t24t6-iae
    - sluco-pkvqw-exbpl-tlray-3bb4v-ltikh-ll76w-kne2b-6hxrg-3kvvo-hae

# The list of dapp canister(s) that will be decentralized if the
# decentralization swap succeeds. These are defined in the form of canister IDs,
# for example, `bnz7o-iuaaa-aaaaa-qaaaa-cai`.  For a successful SNS launch,
# these dapp canister(s) must be co-controlled by the NNS Root canister
# (`r7inp-6aaaa-aaaaa-aaabq-cai`) at latest at the time when the NNS proposal to
# create an SNS is adopted (usually this is required even earlier, e.g., to
# convince NNS neurons to vote in favor of your proposal).
dapp_canisters:
    # For the actual SNS launch, you should replace this with one or more
    # IDs of the canisters comprising your to-be-decentralized dapp.
    #
    # For testing, propose_sns.sh will fill this in automatically.
#    - YOUR_CANISTER_ID
    - eccux-piaaa-aaaag-qjvtq-cai
    - efdsd-cqaaa-aaaag-qjvta-cai

# Configuration of SNS tokens in the SNS Ledger canister deployed as part
# of the SNS.
Token:
    # The name of the token issued by the SNS ledger.
    # Must be a string of 4 to 255 bytes without leading or trailing spaces.
    name: MotokoGold
    # The symbol of the token issued by the SNS Ledger.
    # Must be a string of 3 to 10 bytes without leading or trailing spaces.
    symbol: MTG

    # SNS ledger transaction fee.
    transaction_fee: 100 e8s

    # Path to the SNS token logo on your local filesystem. The path is relative
    # to the configuration file location, unless an absolute path is given.
    # Must have less than 341,334 bytes. The only supported format is PNG.
    logo: logo.png

# Configures SNS proposal-related fields. These fields define the initial values
# for some of the nervous system parameters related to SNS proposals. This will
# not affect all SNS proposals submitted to the newly created SNS.
Proposals:
    # The cost of making an SNS proposal that is rejected by the SNS neuron
    # holders. This field is specified as a token. For example: "1 token".
    rejection_fee: 0.0001 token

    # The initial voting period of an SNS proposal. A proposal's voting period
    # may be increased during its lifecycle due to the wait-for-quiet algorithm
    # (see details below). This field is specified as a duration. For example
    # "4 days".
    initial_voting_period: 3 days

    # The wait-for-quiet algorithm extends the voting period of a proposal when
    # there is a flip in the majority vote during the proposal's voting period.
    #
    # Without this, there could be an incentive to vote right at the end of a
    # proposal's voting period, in order to reduce the chance that people will
    # see and have time to react to that.
    #
    # If this value is set to 1 day, then a change in the majority vote at the
    # end of a proposal's original voting period results in an extension of the
    # voting period by an additional day. Another change at the end of the
    # extended period will cause the voting period to be extended by another
    # half-day, etc.
    #
    # The total extension to the voting period will never be more than twice
    # this value.
    #
    # For more information, please refer to
    # https://wiki.internetcomputer.org/wiki/Network_Nervous_System#Proposal_decision_and_wait-for-quiet
    #
    # This field is specified as a duration. For example: "1 day".
    maximum_wait_for_quiet_deadline_extension: 1 day

# Configuration of SNS voting.
Neurons:
    # The minimum amount of SNS tokens to stake a neuron. This field is specified
    # as a token. For instance, "1 token".
    minimum_creation_stake: 0.0001 tokens

# Configuration of SNS voting.
Voting:
    # The minimum dissolve delay a neuron must have to be able to cast votes on
    # proposals.
    #
    # Dissolve delay incentivizes neurons to vote in the long-term interest of
    # an SNS, as they are rewarded for longer-term commitment to that SNS.
    #
    # Users cannot access the SNS tokens used to stake neurons (until the neuron
    # is dissolved). This field is specified as a duration. For example: "6 months".
    minimum_dissolve_delay: 3 month

    # Configuration of voting power bonuses that are applied to neurons to
    # incentivize alignment with the best interest of the DAO. Note, these
    # bonuses multiply each other, so the increase in voting power due to
    # the dissolve delay bonus is used in the equation to increase voting
    # power for the age bonus.
    MaximumVotingPowerBonuses:
        # Users with a higher dissolve delay are incentivized to take the
        # long-term interests of the SNS into consideration when voting. To
        # reward this long-term commitment, this bonus can be set to a
        # percentage greater than zero, which will result in neurons having
        # their voting power increased in proportion to their dissolve delay.
        #
        # For example, if the user has a dissolve delay of 6 months, and
        # the maximum dissolve delay duration (defined below as `duration`)
        # for the dissolve delay bonus is 12 months, and the maximum bonus
        # (defined as `bonus` below) is set to 10%, then that user’s voting
        # power will be 105% of their normal voting power based on staked
        # tokens (i.e. they will have a bonus of 5%). If the user increased
        # their dissolve delay to 9 months, they would get 107.5% of the normal
        # voting power of their tokens. And if they increased to 12 months, they
        # would get 110%. If they increase further, they get no additional bonus.
        #
        # If you do not want this bonus to be applied for neurons with higher
        # dissolve delay, set `bonus` to `0%` and those neurons will not receive
        # higher voting power.
        DissolveDelay:
            # This parameter sets the maximum dissolve delay a neuron can have.
            # When reached, the maximum dissolve delay bonus will be applied.
            # This field is specified as a duration. For example: "8 years".
            duration: 5 years
            # If a neuron's dissolve delay is `duration`, its voting power will
            # be increased by the dissolve delay `bonus` amount. 
            # This field is specified as a percentage. For instance, 
            # a value of "100%" means that the voting power will be doubled
            # (multiplied by 2).
            bonus: 90%

        # Users with neurons staked in the non-dissolving state for a long
        # period of time are incentivized to take the long-term interests of
        # the SNS into consideration when voting. To reward this long-term
        # commitment, this bonus can be set to a percentage (greater than zero),
        # which will result in neurons having their voting power increased in
        # proportion to their age.
        #
        # For example, if the neuron has an age of 6 months, and the maximum age
        # duration (defined below as `duration`) for the age bonus is 12 months,
        # and the maximum bonus (defined as `bonus` below) is set to 10%, then
        # that neuron’s voting power will be 105% of their normal voting power
        # based on staked tokens plus dissolve delay bonus (i.e. they will have a
        # bonus of 5%). If neuron aged another 3 months to have an age of 9 months,
        # the neuron would get 107.5% of the normal voting power. And if the neuron
        # aged another 3 months to 12 months, the neuron would get 110%. If the neuron
        # ages further, it get no additional bonus.
        #
        # If this bonus should not be applied for older neurons, set the bonus
        # to `0%` and older neurons will not receive higher voting power.
        Age:
            # This parameter sets the duration of time the neuron must be staked
            # in the non-dissolving state, in other words its `age`, to reach
            # the maximum age bonus. Once this age is reached, the neuron will
            # continue to age, but no more bonus will be applied. This field
            # is specified as a duration. For example: "2 years".
            duration: 5 years
            # If a neuron's age is `duration` or older, its voting power will be
            # increased by this age`bonus` amount. 
            # This field is specified as a percentage. For instance, 
            # a value of "25%" means that the voting power will increase by a quarter
            # (multiplied by 1.25).
            bonus: 50%

    # Configuration of SNS voting reward parameters.
    #
    # The voting reward rate controls how quickly the supply of the SNS token
    # increases. For example, setting `initial` to `2%` will cause the supply to
    # increase by at most `2%` per year. A higher voting reward rate
    # incentivizes users to participate in governance, but also results in
    # higher inflation.
    #
    # The initial and final reward rates can be set to have a higher reward rate
    # at the launch of the SNS and a lower rate further into the SNS’s lifetime.
    # The reward rate falls quadratically from the `initial` rate to the `final`
    # rate over the course of `transition_duration`.
    #
    # Setting both `initial` and `final` to `0%` will result in the system not
    # distributing voting rewards at all.
    #
    # More details on SNS tokenomics can be found in the developer documentation:
    # https://internetcomputer.org/docs/current/developer-docs/integrations/sns/tokenomics/rewards/#voting-rewards
    RewardRate:
        # The initial reward rate at which the SNS voting rewards will increase
        # per year. This field is specified as a percentage. For example: "15%".
        initial: 90%

        # The final reward rate at which the SNS voting rewards will increase
        # per year. This rate is reached after `transition_duration` and remains
        # at this level unless changed by an SNS proposal. This field is
        # specified as a percentage. For example: "5%".
        final: 0.25%

        # The voting reward rate falls quadratically from `initial` to `final`
        # over the time period defined by `transition_duration`.
        #
        # Values of 0 result in the reward rate always being `final`.
        #
        # This field is specified as a duration. For example: "8 years".
        transition_duration: 4 years

# Configuration of the initial token distribution of the SNS. You can configure
# how SNS tokens are distributed in each of the three groups:
# (1) tokens that are given to the original developers of the dapp,
# (2) treasury tokens that are owned by the SNS governance canister, and
# (3) tokens which are distributed to the decentralization swap participants.
#
# The initial token distribution must satisfy the following preconditions to be
# valid:
#    - The sum of all developer tokens in E8s must be less than `u64::MAX`.
#    - The Swap's initial balance (see group (3) above) must be greater than 0.
#    - The Swap's initial balance (see group (3) above) must be greater than or
#      equal to the sum of all developer tokens.
Distribution:
    # The initial neurons created when the SNS Governance canister is installed.
    # Each element in this list specifies one such neuron, including its stake,
    # controlling principal, memo identifying this neuron (every neuron that
    # a user has must be identified by a unique memo), dissolve delay, and a
    # vesting period. Even though these neurons are distributed at genesis,
    # they are locked in a (restricted) pre-initialization mode until the
    # decentralization swap is completed. Note that `vesting_period` starts
    # right after the SNS creation and thus includes the pre-initialization mode
    # period.
    #
    # For example:
    #  - principal: hpikg-6exdt-jn33w-ndty3-fc7jc-tl2lr-buih3-cs3y7-tftkp-sfp62-gqe
    #    stake: 1_000 tokens
    #    memo: 0
    #    dissolve_delay: 2 years
    #    vesting_period: 4 years
    Neurons:
        # For the actual SNS launch, you should replace this with one or more
        # principals of your intended genesis neurons.
        #
        # For testing, propose_sns.sh will fill this in automatically.
#        - principal: YOUR_PRINCIPAL_ID
        - principal: sluco-pkvqw-exbpl-tlray-3bb4v-ltikh-ll76w-kne2b-6hxrg-3kvvo-hae
          stake: 200 tokens
          memo: 0
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: ksbqq-arh2k-csjj7-tcrhk-zp4pi-5kjlf-kzjcr-4bizs-lktqr-7zjnf-tqe
          stake: 200 tokens
          memo: 1
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: 5vsuw-un25d-crm7h-5pcov-iry22-msinr-2bdef-6jtqu-ak4ca-kitao-uqe
          stake: 200 tokens
          memo: 2
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: ghhh6-265d7-xoqhd-gkwh2-6hsnj-ue7ly-xu5d6-n2etm-sk6jj-adu3p-qqe
          stake: 200 tokens
          memo: 3
          dissolve_delay: 1 years
          vesting_period: 0 years


    # The initial SNS token balances of the various canisters of the SNS.
    InitialBalances:
        # The initial SNS token balance of the SNS Governance canister is known
        # as the treasury. This is initialized in a special sub-account, as the
        # main account of Governance is the minting account of the SNS Ledger.
        # This field is specified as a token. governance: 16_000 tokens
        governance: 8_400 token

        # The initial SNS token balance of the Swap canister is what will be
        # available for the decentralization swap. These tokens will be swapped
        # for ICP. This field is specified as a token. For instance, "1 token".
        swap: 800 tokens

    # Checksum of the total number of tokens distributed in this section.
    # This field is specified as a token. For instance, "1 token".
    #          1_000    (neuron)
    #      2 million    (governance)
    # + 500 thousand    (swap)
    # --------------
    total: 10_000 tokens

# Configuration of the decentralization swap parameters. Choose these parameters
# carefully, if a decentralization swap fails, the SNS will restore the dapp
# canister(s) to the fallback controllers (defined in
# `fallback_controller_principals`) and you will need to start over.
Swap:
    # The minimum number of direct participants that must participate for the
    # decentralization swap to succeed. If a decentralization swap finishes due
    # to the deadline or the maximum target being reached, and if there are less
    # than `minimum_participants` (here, only direct participants are counted),
    # the swap will be committed.
    minimum_participants: 10

    # Minimum amount of ICP from direct participants. This amount is required for
    # the swap to succeed. If this amount is not achieved, the swap will be
    # aborted (instead of committed) when the due date/time occurs.
    # Must be smaller than or equal than `maximum_direct_participation_icp`.
    minimum_direct_participation_icp: 10 tokens

    # Maximum amount of ICP from direct participants. If this amount is achieved,
    # the swap will finalize immediately, without waiting for the due date/time;
    # in this case, the swap would be committed if and only if the number of
    # direct participants (`minimum_participants`) is reached (otherwise, it
    # would be aborted).
    # Must be at least `min_participants * minimum_direct_participation_icp`.
    maximum_direct_participation_icp: 800 tokens

    # The minimum amount of ICP that each participant must contribute
    # to participate. This field is specified as a token. For instance,
    # "1 token".
    minimum_participant_icp: 1 tokens

    # The maximum amount of ICP that each participant may contribute
    # to participate. This field is specified as a token. For instance,
    # "1 token".
    maximum_participant_icp: 1 tokens

    # The text that swap participants must confirm before they may participate
    # in the swap.
    #
    # This field is optional. If set, must be within 1 to 1,000 characters and
    # at most 8,000 bytes.
    # confirmation_text: >
    #     I confirm my understanding of the responsibilities and risks
    #     associated with participating in this token swap.

    # A list of countries from which swap participation should not be allowed.
    #
    # This field is optional. By default, participants from all countries
    # are allowed.
    #
    # Each list element must be an ISO 3166-1 alpha-2 country code.
    restricted_countries:
        - US 
        - AF
        - BF
        - CH
        - CI
        - CU 
        - IR 
        - ML 
        - MZ
        - MM 
        - NF 
        - SD 
        - SS 
        - SY
        - VE 
        - YE 


    # Configuration of the vesting schedule of the neuron basket, i.e., the SNS
    # neurons that a participants will receive from a successful
    # decentralization swap.
    VestingSchedule:
        # The number of events in the vesting schedule. This translates to how
        # many neurons will be in each participant's neuron basket. Note that
        # the first neuron in each neuron basket will have zero dissolve delay.
        # This value should thus be greater than or equal to `2`.
        events: 4

        # The interval at which the schedule will be increased per event. The
        # first neuron in the basket will be unlocked with zero dissolve delay.
        # Each other neuron in the schedule will have its dissolve delay
        # increased by `interval` compared to the previous one. For example,
        # if `events` is set to `3` and `interval` is `1 month`, then each
        # participant's neuron basket will have three neurons (with equal stake)
        # with dissolve delays zero, 1 month, and 2 months. Note that the notion
        # of `Distribution.neurons.vesting_period` applies only to developer
        # neurons. While neuron basket neurons do not use `vesting_period`, they
        # have a vesting schedule. This field is specified as a duration. For
        # example: "1 month".
        interval: 6 months

    # Absolute time of day when the decentralization swap is supposed to start.
    #
    # An algorithm will be applied to allow at least 24 hours between the time
    # of execution of the CreateServiceNervousSystem proposal and swap start.
    # For example, if start_time is 23:30 UTC and the proposal is adopted and
    # executed at 23:20 UTC, then the swap start will be at 23:30 UTC the next
    # day (i.e., in 24 hours and 10 min from the proposal execution time).
    #
    # WARNING: Swap start_time works differently on mainnet and in testing.
    #
    # On mainnet:
    # - Setting start_time to some value (e.g., 23:30 UTC) will allow the swap
    #   participants to be prepared for the swap in advance, e.g.,
    #   by obtaining ICPs that they would like to participate with.
    # - If start_time is not specified, the actual start time of the swap will
    #   be chosen at random (allowing at least 24 hours and less than 48 hours,
    #   as described above).
    #
    # In testing:
    # - Setting start_time to some value works the same as explained above.
    # - If start_time is not specified, the swap will begin immediately after
    #   the CreateServiceNervousSystem proposal is executed. This facilitates
    #   testing in an accelerated manner.
    #
    # start_time: 23:30 UTC  # Intentionally commented out for testing.

    # The duration of the decentralization swap. When `start_time` is calculated
    # during CreateServiceNervousSystem proposal execution, this `duration` will
    # be added to that absolute time and set as the swap's deadline.
    duration: 10 days

    # Whether Neurons' Fund participation is requested.
    neurons_fund_participation: false

Just to be super clear @domwoe @Dylan in this yaml we get out the initial funding idea, we starting super small and it’s okey with us.

  • Max amount to raise: 800 ICP
  • Max amount per participant to fund: 10 ICP
  • Neurons_fund_participation: false
  • 3 Neurons for Participants with voting power with a 6 month interval.

Do we clean doubts with the set of configuration?

At least we’re clear about what we are, and what we are doing. I visited the original MotokoDAO thread here and it’s clear to me that original MotokoDao will struggle over time cause the path they have chosen https://forum.dfinity.org/t/upcoming-sns-dao-for-motoko/29052/240 it’s also clear for matthew

That SNS yaml file has an improved voting power distribution when compared to proposal 129732, but you may want to set up the SNS yaml file in a way that doesn’t give a majority of the voting power at launch to the developer neurons.

You can load your SNS yaml file into the SNS Tokenomics Analyzer to to simulate and analyze various tokenomics outcomes. The attached screenshot shows the voting power distribution of the SNS yaml file in this message.

1 Like

What about this config settings:

Any additional recommendations @Dylan ?

Thanks

# You should make a copy of this file, name it sns_init.yaml, and edit it to
# suit your needs.
#
# All principal IDs should almost certainly be changed.
#
# In this file, 1 year is nominally defined to be 365.25 days.
#
# This gets passed to `sns propose`. See propose_sns.sh.
#
# This follows the second configuration file format developed for the `sns`
# CLI. The first format will be supported for a time, but this format will
# eventually become the standard format.
# ------------------------------------------------------------------------------
# UNITS
#
# This SNS configuration file version allows specifying the various
# fields with units that make configuration easier. For instance,
# in the previous version, all fields relating to token values
# had to be specified in e8s (fractions of 10E-8 of a governance token).
# In this version, similar fields can be specified in whole tokens,
# tokens with decimals, or e8s. Below is more information on the type
# of units that can be used.
#
# For fields that represent token values (such as `transaction_fee`
# or `rejection_fee`), devs can specify decimal strings ending in
# "tokens" (plural), decimal strings ending in "token" (singular),
# or integer strings (base 10) ending in "e8s". In the case of
# "tokens" strings, the maximum number of digits after the (optional)
# decimal point is 8. The "_" character may be sprinkled throughout.
# Whitespace around number is insignificant. E.g. " 42 tokens" is
# equivalent to "42tokens".
#
# For fields that represent duration values (such as `initial_voting_period`
# or `minimum_dissolve_delay`), devs can specify durations as a concatenation
# of time spans. Where each time span is an integer number and a suffix.
# Supported suffixes:
#  - seconds, second, sec, s
#  - minutes, minute, min, m
#  - hours, hour, hr, h
#  - days, day, d
#  - weeks, week, w
#  - months, month, M -- defined as 30.44 days
#  - years, year, y -- defined as 365.25 days
#
# For example, "1w 2d 3h" gets parsed as
#
# 1 week + 2 days + 3 hours
#    =
# (1 * (7 * 24 * 60 * 60) + 2 * 24 * 60 * 60 + 3 * (60 * 60)) seconds
#
# For fields that represent percentage values (such as `bonus`), devs specify
# the value as an integer with a trailing percent sign ('%'). For example,
# `10%`.
#
# For fields that represent time of day (such as `start_time`), devs specify
# the value as a string in form "hh::mm UTC". Where hh is hour, and mm is minute.
# Only the UTC timezone is currently supported.
# ------------------------------------------------------------------------------

# Name of the SNS project. This may differ from the name of the associated
# token. Must be a string of max length = 255.
name: Motoko Gold

# Description of the SNS project.
# Must be a string of max length = 2,000.
description: >
   The Motoko Golden Brother. Buying Pressure DAO Automated.

# This is currently a placeholder field and must be left empty for now.
Principals: []

# Path to the SNS Project logo on the local filesystem. The path is relative
# to the configuration file's location, unless an absolute path is given.
# Must have less than 341,334 bytes. The only supported format is PNG.
logo: logo.png

# URL to the dapp controlled by the SNS project.
# Must be a string from 10 to 512 bytes.
url: https://tkiah-yqaaa-aaaag-qjwpa-cai.icp0.io

# Metadata for the NNS proposal required to create the SNS. This data will be
# shown only in the NNS proposal.
NnsProposal:
    # The title of the NNS proposal. Must be a string of 4 to 256 bytes.
    title: "Rectified NNS Proposal to create an SNS named 'Motoko Gold' Max Raising: 800 ICP"

    # The HTTPS address of additional content required to evaluate the NNS
    # proposal.
    url: "https://forum.dfinity.org/t/the-motoko-golden-brother-dao-motoko-gold-coming-to-nns-happening-now/30630"

    # The description of the proposal. Must be a string of 10 to 2,000 bytes.
    summary: >
        
        Welcome to the 2nd attempt of the creation of the Motoko Golden DAO foundation. This Attempt will be final.

        Launchpad:
        - Max amount to raise: 800 ICP
        - Max amount per participant to fund: 10 ICP
        - Neurons_fund_participation: false
        - 3 Neurons for Participants with voting power with a 6 month interval.

        Team:
        - Good Actor of the Ecosystem.
        - Neurons 1 year locked.
        - We all are Engineers.

        Summary:
        - We are building next generation coin leveraging on NNS for create a DAO-controlled oracle and DAO-controlled neuron to use rewards to create buying pressure on the token.

        Goal:
        -  Get MotokoGold token to uptrend in price consistently over time. Get exposure outside ICP ecosystem to bring attention and adoption to ICP.

        Key Considerations:
         - If you are unsure about risking 10 ICP, please refrain from participating. The team is NOT responsible for any losses incurred.


         Your support is kindly appreciated.
        

# If the SNS launch attempt fails, control over the dapp canister(s) is given to
# these principals. In most use cases, this is chosen to be the original set of
# controller(s) of the dapp. Must be a list of PrincipalIds.
fallback_controller_principals:
    # For the actual SNS launch, you should replace this with one or more
    # principals of your intended fallback controllers.
    #
    # For testing, propose_sns.sh will fill this in automatically.
#    - YOUR_PRINCIPAL_ID
    - tzfzz-d53nw-kcugq-nhsxj-hodle-mlla7-b7beb-hwwqi-32um6-t24t6-iae
    - sluco-pkvqw-exbpl-tlray-3bb4v-ltikh-ll76w-kne2b-6hxrg-3kvvo-hae

# The list of dapp canister(s) that will be decentralized if the
# decentralization swap succeeds. These are defined in the form of canister IDs,
# for example, `bnz7o-iuaaa-aaaaa-qaaaa-cai`.  For a successful SNS launch,
# these dapp canister(s) must be co-controlled by the NNS Root canister
# (`r7inp-6aaaa-aaaaa-aaabq-cai`) at latest at the time when the NNS proposal to
# create an SNS is adopted (usually this is required even earlier, e.g., to
# convince NNS neurons to vote in favor of your proposal).
dapp_canisters:
    # For the actual SNS launch, you should replace this with one or more
    # IDs of the canisters comprising your to-be-decentralized dapp.
    #
    # For testing, propose_sns.sh will fill this in automatically.
#    - YOUR_CANISTER_ID
    - eccux-piaaa-aaaag-qjvtq-cai
    - efdsd-cqaaa-aaaag-qjvta-cai

# Configuration of SNS tokens in the SNS Ledger canister deployed as part
# of the SNS.
Token:
    # The name of the token issued by the SNS ledger.
    # Must be a string of 4 to 255 bytes without leading or trailing spaces.
    name: MotokoGold
    # The symbol of the token issued by the SNS Ledger.
    # Must be a string of 3 to 10 bytes without leading or trailing spaces.
    symbol: MTG

    # SNS ledger transaction fee.
    transaction_fee: 100 e8s

    # Path to the SNS token logo on your local filesystem. The path is relative
    # to the configuration file location, unless an absolute path is given.
    # Must have less than 341,334 bytes. The only supported format is PNG.
    logo: logo.png

# Configures SNS proposal-related fields. These fields define the initial values
# for some of the nervous system parameters related to SNS proposals. This will
# not affect all SNS proposals submitted to the newly created SNS.
Proposals:
    # The cost of making an SNS proposal that is rejected by the SNS neuron
    # holders. This field is specified as a token. For example: "1 token".
    rejection_fee: 0.0001 token

    # The initial voting period of an SNS proposal. A proposal's voting period
    # may be increased during its lifecycle due to the wait-for-quiet algorithm
    # (see details below). This field is specified as a duration. For example
    # "4 days".
    initial_voting_period: 3 days

    # The wait-for-quiet algorithm extends the voting period of a proposal when
    # there is a flip in the majority vote during the proposal's voting period.
    #
    # Without this, there could be an incentive to vote right at the end of a
    # proposal's voting period, in order to reduce the chance that people will
    # see and have time to react to that.
    #
    # If this value is set to 1 day, then a change in the majority vote at the
    # end of a proposal's original voting period results in an extension of the
    # voting period by an additional day. Another change at the end of the
    # extended period will cause the voting period to be extended by another
    # half-day, etc.
    #
    # The total extension to the voting period will never be more than twice
    # this value.
    #
    # For more information, please refer to
    # https://wiki.internetcomputer.org/wiki/Network_Nervous_System#Proposal_decision_and_wait-for-quiet
    #
    # This field is specified as a duration. For example: "1 day".
    maximum_wait_for_quiet_deadline_extension: 1 day

# Configuration of SNS voting.
Neurons:
    # The minimum amount of SNS tokens to stake a neuron. This field is specified
    # as a token. For instance, "1 token".
    minimum_creation_stake: 0.0001 tokens

# Configuration of SNS voting.
Voting:
    # The minimum dissolve delay a neuron must have to be able to cast votes on
    # proposals.
    #
    # Dissolve delay incentivizes neurons to vote in the long-term interest of
    # an SNS, as they are rewarded for longer-term commitment to that SNS.
    #
    # Users cannot access the SNS tokens used to stake neurons (until the neuron
    # is dissolved). This field is specified as a duration. For example: "6 months".
    minimum_dissolve_delay: 3 month

    # Configuration of voting power bonuses that are applied to neurons to
    # incentivize alignment with the best interest of the DAO. Note, these
    # bonuses multiply each other, so the increase in voting power due to
    # the dissolve delay bonus is used in the equation to increase voting
    # power for the age bonus.
    MaximumVotingPowerBonuses:
        # Users with a higher dissolve delay are incentivized to take the
        # long-term interests of the SNS into consideration when voting. To
        # reward this long-term commitment, this bonus can be set to a
        # percentage greater than zero, which will result in neurons having
        # their voting power increased in proportion to their dissolve delay.
        #
        # For example, if the user has a dissolve delay of 6 months, and
        # the maximum dissolve delay duration (defined below as `duration`)
        # for the dissolve delay bonus is 12 months, and the maximum bonus
        # (defined as `bonus` below) is set to 10%, then that user’s voting
        # power will be 105% of their normal voting power based on staked
        # tokens (i.e. they will have a bonus of 5%). If the user increased
        # their dissolve delay to 9 months, they would get 107.5% of the normal
        # voting power of their tokens. And if they increased to 12 months, they
        # would get 110%. If they increase further, they get no additional bonus.
        #
        # If you do not want this bonus to be applied for neurons with higher
        # dissolve delay, set `bonus` to `0%` and those neurons will not receive
        # higher voting power.
        DissolveDelay:
            # This parameter sets the maximum dissolve delay a neuron can have.
            # When reached, the maximum dissolve delay bonus will be applied.
            # This field is specified as a duration. For example: "8 years".
            duration: 5 years
            # If a neuron's dissolve delay is `duration`, its voting power will
            # be increased by the dissolve delay `bonus` amount. 
            # This field is specified as a percentage. For instance, 
            # a value of "100%" means that the voting power will be doubled
            # (multiplied by 2).
            bonus: 90%

        # Users with neurons staked in the non-dissolving state for a long
        # period of time are incentivized to take the long-term interests of
        # the SNS into consideration when voting. To reward this long-term
        # commitment, this bonus can be set to a percentage (greater than zero),
        # which will result in neurons having their voting power increased in
        # proportion to their age.
        #
        # For example, if the neuron has an age of 6 months, and the maximum age
        # duration (defined below as `duration`) for the age bonus is 12 months,
        # and the maximum bonus (defined as `bonus` below) is set to 10%, then
        # that neuron’s voting power will be 105% of their normal voting power
        # based on staked tokens plus dissolve delay bonus (i.e. they will have a
        # bonus of 5%). If neuron aged another 3 months to have an age of 9 months,
        # the neuron would get 107.5% of the normal voting power. And if the neuron
        # aged another 3 months to 12 months, the neuron would get 110%. If the neuron
        # ages further, it get no additional bonus.
        #
        # If this bonus should not be applied for older neurons, set the bonus
        # to `0%` and older neurons will not receive higher voting power.
        Age:
            # This parameter sets the duration of time the neuron must be staked
            # in the non-dissolving state, in other words its `age`, to reach
            # the maximum age bonus. Once this age is reached, the neuron will
            # continue to age, but no more bonus will be applied. This field
            # is specified as a duration. For example: "2 years".
            duration: 5 years
            # If a neuron's age is `duration` or older, its voting power will be
            # increased by this age`bonus` amount. 
            # This field is specified as a percentage. For instance, 
            # a value of "25%" means that the voting power will increase by a quarter
            # (multiplied by 1.25).
            bonus: 50%

    # Configuration of SNS voting reward parameters.
    #
    # The voting reward rate controls how quickly the supply of the SNS token
    # increases. For example, setting `initial` to `2%` will cause the supply to
    # increase by at most `2%` per year. A higher voting reward rate
    # incentivizes users to participate in governance, but also results in
    # higher inflation.
    #
    # The initial and final reward rates can be set to have a higher reward rate
    # at the launch of the SNS and a lower rate further into the SNS’s lifetime.
    # The reward rate falls quadratically from the `initial` rate to the `final`
    # rate over the course of `transition_duration`.
    #
    # Setting both `initial` and `final` to `0%` will result in the system not
    # distributing voting rewards at all.
    #
    # More details on SNS tokenomics can be found in the developer documentation:
    # https://internetcomputer.org/docs/current/developer-docs/integrations/sns/tokenomics/rewards/#voting-rewards
    RewardRate:
        # The initial reward rate at which the SNS voting rewards will increase
        # per year. This field is specified as a percentage. For example: "15%".
        initial: 90%

        # The final reward rate at which the SNS voting rewards will increase
        # per year. This rate is reached after `transition_duration` and remains
        # at this level unless changed by an SNS proposal. This field is
        # specified as a percentage. For example: "5%".
        final: 0.25%

        # The voting reward rate falls quadratically from `initial` to `final`
        # over the time period defined by `transition_duration`.
        #
        # Values of 0 result in the reward rate always being `final`.
        #
        # This field is specified as a duration. For example: "8 years".
        transition_duration: 4 years

# Configuration of the initial token distribution of the SNS. You can configure
# how SNS tokens are distributed in each of the three groups:
# (1) tokens that are given to the original developers of the dapp,
# (2) treasury tokens that are owned by the SNS governance canister, and
# (3) tokens which are distributed to the decentralization swap participants.
#
# The initial token distribution must satisfy the following preconditions to be
# valid:
#    - The sum of all developer tokens in E8s must be less than `u64::MAX`.
#    - The Swap's initial balance (see group (3) above) must be greater than 0.
#    - The Swap's initial balance (see group (3) above) must be greater than or
#      equal to the sum of all developer tokens.
Distribution:
    # The initial neurons created when the SNS Governance canister is installed.
    # Each element in this list specifies one such neuron, including its stake,
    # controlling principal, memo identifying this neuron (every neuron that
    # a user has must be identified by a unique memo), dissolve delay, and a
    # vesting period. Even though these neurons are distributed at genesis,
    # they are locked in a (restricted) pre-initialization mode until the
    # decentralization swap is completed. Note that `vesting_period` starts
    # right after the SNS creation and thus includes the pre-initialization mode
    # period.
    #
    # For example:
    #  - principal: hpikg-6exdt-jn33w-ndty3-fc7jc-tl2lr-buih3-cs3y7-tftkp-sfp62-gqe
    #    stake: 1_000 tokens
    #    memo: 0
    #    dissolve_delay: 2 years
    #    vesting_period: 4 years
    Neurons:
        # For the actual SNS launch, you should replace this with one or more
        # principals of your intended genesis neurons.
        #
        # For testing, propose_sns.sh will fill this in automatically.
#        - principal: YOUR_PRINCIPAL_ID
        - principal: sluco-pkvqw-exbpl-tlray-3bb4v-ltikh-ll76w-kne2b-6hxrg-3kvvo-hae
          stake: 150 tokens
          memo: 0
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: ksbqq-arh2k-csjj7-tcrhk-zp4pi-5kjlf-kzjcr-4bizs-lktqr-7zjnf-tqe
          stake: 150 tokens
          memo: 1
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: 5vsuw-un25d-crm7h-5pcov-iry22-msinr-2bdef-6jtqu-ak4ca-kitao-uqe
          stake: 150 tokens
          memo: 2
          dissolve_delay: 1 years
          vesting_period: 0 years

        - principal: ghhh6-265d7-xoqhd-gkwh2-6hsnj-ue7ly-xu5d6-n2etm-sk6jj-adu3p-qqe
          stake: 150 tokens
          memo: 3
          dissolve_delay: 1 years
          vesting_period: 0 years


    # The initial SNS token balances of the various canisters of the SNS.
    InitialBalances:
        # The initial SNS token balance of the SNS Governance canister is known
        # as the treasury. This is initialized in a special sub-account, as the
        # main account of Governance is the minting account of the SNS Ledger.
        # This field is specified as a token. governance: 16_000 tokens
        governance: 8_400 token

        # The initial SNS token balance of the Swap canister is what will be
        # available for the decentralization swap. These tokens will be swapped
        # for ICP. This field is specified as a token. For instance, "1 token".
        swap: 800 tokens

    # Checksum of the total number of tokens distributed in this section.
    # This field is specified as a token. For instance, "1 token".
    #          1_000    (neuron)
    #      2 million    (governance)
    # + 500 thousand    (swap)
    # --------------
    total: 10_000 tokens

# Configuration of the decentralization swap parameters. Choose these parameters
# carefully, if a decentralization swap fails, the SNS will restore the dapp
# canister(s) to the fallback controllers (defined in
# `fallback_controller_principals`) and you will need to start over.
Swap:
    # The minimum number of direct participants that must participate for the
    # decentralization swap to succeed. If a decentralization swap finishes due
    # to the deadline or the maximum target being reached, and if there are less
    # than `minimum_participants` (here, only direct participants are counted),
    # the swap will be committed.
    minimum_participants: 10

    # Minimum amount of ICP from direct participants. This amount is required for
    # the swap to succeed. If this amount is not achieved, the swap will be
    # aborted (instead of committed) when the due date/time occurs.
    # Must be smaller than or equal than `maximum_direct_participation_icp`.
    minimum_direct_participation_icp: 10 tokens

    # Maximum amount of ICP from direct participants. If this amount is achieved,
    # the swap will finalize immediately, without waiting for the due date/time;
    # in this case, the swap would be committed if and only if the number of
    # direct participants (`minimum_participants`) is reached (otherwise, it
    # would be aborted).
    # Must be at least `min_participants * minimum_direct_participation_icp`.
    maximum_direct_participation_icp: 800 tokens

    # The minimum amount of ICP that each participant must contribute
    # to participate. This field is specified as a token. For instance,
    # "1 token".
    minimum_participant_icp: 1 tokens

    # The maximum amount of ICP that each participant may contribute
    # to participate. This field is specified as a token. For instance,
    # "1 token".
    maximum_participant_icp: 1 tokens

    # The text that swap participants must confirm before they may participate
    # in the swap.
    #
    # This field is optional. If set, must be within 1 to 1,000 characters and
    # at most 8,000 bytes.
    # confirmation_text: >
    #     I confirm my understanding of the responsibilities and risks
    #     associated with participating in this token swap.

    # A list of countries from which swap participation should not be allowed.
    #
    # This field is optional. By default, participants from all countries
    # are allowed.
    #
    # Each list element must be an ISO 3166-1 alpha-2 country code.
    restricted_countries:
        - US 
        - AF
        - BF
        - CH
        - CI
        - CU 
        - IR 
        - ML 
        - MZ
        - MM 
        - NF 
        - SD 
        - SS 
        - SY
        - VE 
        - YE 


    # Configuration of the vesting schedule of the neuron basket, i.e., the SNS
    # neurons that a participants will receive from a successful
    # decentralization swap.
    VestingSchedule:
        # The number of events in the vesting schedule. This translates to how
        # many neurons will be in each participant's neuron basket. Note that
        # the first neuron in each neuron basket will have zero dissolve delay.
        # This value should thus be greater than or equal to `2`.
        events: 4

        # The interval at which the schedule will be increased per event. The
        # first neuron in the basket will be unlocked with zero dissolve delay.
        # Each other neuron in the schedule will have its dissolve delay
        # increased by `interval` compared to the previous one. For example,
        # if `events` is set to `3` and `interval` is `1 month`, then each
        # participant's neuron basket will have three neurons (with equal stake)
        # with dissolve delays zero, 1 month, and 2 months. Note that the notion
        # of `Distribution.neurons.vesting_period` applies only to developer
        # neurons. While neuron basket neurons do not use `vesting_period`, they
        # have a vesting schedule. This field is specified as a duration. For
        # example: "1 month".
        interval: 24 months

    # Absolute time of day when the decentralization swap is supposed to start.
    #
    # An algorithm will be applied to allow at least 24 hours between the time
    # of execution of the CreateServiceNervousSystem proposal and swap start.
    # For example, if start_time is 23:30 UTC and the proposal is adopted and
    # executed at 23:20 UTC, then the swap start will be at 23:30 UTC the next
    # day (i.e., in 24 hours and 10 min from the proposal execution time).
    #
    # WARNING: Swap start_time works differently on mainnet and in testing.
    #
    # On mainnet:
    # - Setting start_time to some value (e.g., 23:30 UTC) will allow the swap
    #   participants to be prepared for the swap in advance, e.g.,
    #   by obtaining ICPs that they would like to participate with.
    # - If start_time is not specified, the actual start time of the swap will
    #   be chosen at random (allowing at least 24 hours and less than 48 hours,
    #   as described above).
    #
    # In testing:
    # - Setting start_time to some value works the same as explained above.
    # - If start_time is not specified, the swap will begin immediately after
    #   the CreateServiceNervousSystem proposal is executed. This facilitates
    #   testing in an accelerated manner.
    #
    # start_time: 23:30 UTC  # Intentionally commented out for testing.

    # The duration of the decentralization swap. When `start_time` is calculated
    # during CreateServiceNervousSystem proposal execution, this `duration` will
    # be added to that absolute time and set as the swap's deadline.
    duration: 10 days

    # Whether Neurons' Fund participation is requested.
    neurons_fund_participation: false

My personal opinion, not speaking as a representative of DFINITY, is that an SNS should not configure its tokenomics in a way that the developers can immediately attain a majority of the voting power by maxing out the dissolve delay of the developer neurons, which is possible in your latest SNS yaml file.

The SNS yaml file allocates 800 tokens to swap participants, 600 tokens to developers, and 8,400 tokens to the treasury, which by the way doesn’t add up to the specified total: 10_000 tokens. If you increased the tokens for direct participants from swap: 800 tokens to swap: 1000 tokens, that would correct both the total and the voting power issue I mentioned above. With this configuration, if the dissolve delay of the developer neurons were maxed out, the developer neurons would have 47.8% of the total voting power.

1 Like