TODO

• [x] weights
• [x] test events
• [x] add split pooling function (aura)
• [ ] add authorities to aura list (aura)
• [x] Properly protect functions with relay chain calls

https://github.com/paritytech/statemint/blob/9664809ad5de6ce43b6b78a6b3d12fbfece7f147/runtime/statemine/src/lib.rs#L610-L611

New candidates can only be author blocks after 2 sessions, but threshold is just 1 period.

And why KickThreshold needs to be a multiple of session?

Should really only track last authored blocks & kick inactive one only for current collator.

Should parachains like statemint be registered in BIP-0044 coin types?

This question can be applied to any parachain, once non-standalone parachains/parathreads are ephemeral as it can lose an auction and consequently be "kicked" from polkadot shared security. Should parachains like Statemint be registered in BIP-0044? If they don't, how users will store assets in their third-part wallets and do transfers?

Links

• BIP-44: Multi-Account Hierarchy for Deterministic Wallets
• Registered coin types for BIP-0044

The majority of the functionality will come from the Assets pallet in FRAME.

Pallets

• Assets
• Multisig
• Proxy (#8)
• Transaction Payment (#5)
• Utility
• Democracy (? -> #4)

Block Production

• Collator set selection: Simple Staking
• Author selection: Aura

The Assets pallet is designed for fungible assets. At some point in the future (probably after initial launch), add logic to support non-fungible assets.

Follow on to https://github.com/paritytech/statemint/pull/62. Runtime with sudo in it to use on Westend.

Closes https://github.com/paritytech/statemint/issues/63

Weight files copied from Statemint.

• [x] Make tests work again
• [x] TODOs in the code. fixes parts of https://github.com/paritytech/statemint/issues/9 related to https://github.com/paritytech/statemint/issues/23

Two decisions to make about transaction fees:

1. How much to charge? I have configured the runtime to charge 1/10 the tx fees as the Relay Chain would charge. I think transactions on parachains should be cheaper as the execution does not affect other parachains. Note that I left the target block fullness at 25%, but the target block weight is 500ms, as opposed to 2s on the Relay Chain, so blocks will be relatively more full for a given number of transactions. Is 1/10 OK or are there arguments for another value?
2. What to do with them? a. Burn some portion and give the rest to the collator (or burn 0 and give all to the collator, but I believe this has some economic issues). b. Give to a Relay Chain validator and let them handle the validator/treasury split. c. Add an account to Statemint over which the Relay Chain Council has control and send fees (or some portion) there.

Statemint should be fully aligned with the Relay Chain to which it is connected. This will require the ability to define Origins as coming from another chain (i.e. an implementation of EnsureOneOf that allows declaring another chain's origin).

Edit: Decisions based on comments:

• Statemint Root = Relay Chain Root
• Statemint ForceOrigin = More than half of Relay Chain Council
• Statemint Transaction Payment Origin = More than half of Relay Chain Council

We also need to make some concrete decisions about these origins (i.e. Relay Chain root? Some fraction of Council/Technical Committee?):

• Root origin (ability to perform runtime upgrades)
• ForceOrigin origin (ability to perform force_* actions in pallet-assets)
• Origin to set transaction payment DOT to asset ratio (#5 )

In addition, should this have the Democracy pallet to allow users to make Statemint-specific proposals for the Relay Chain to decide on? Or should those proposals be made through the Relay Chain's governance?

Parameters to Review Before Launch

• MAXIMUM_BLOCK_WEIGHT - 500 ms
• Assets
  • [ ] AssetDeposit - 1 KSM, 100 DOT
  • [ ] MetadataDepositBase
  • [ ] MetadataDepositPerByte
  • [ ] ApprovalDeposit
  • [ ] StringLimit
• Balances
  • [ ] ExistentialDeposit - 1/10 of parent chain
  • [ ] MaxLocks - shouldn't be so relevant for this chain, same as parent.
  • [ ] Align transaction_payment with Relay Chain.
• Multisig
  • [ ] DepositBase - parent chain / (factor)
  • [ ] DepositFactor - parent chain / (factor)
  • [ ] MaxSignatories - same as parent chain
• Proxy
  • [ ] ProxyDepositBase - parent chain / (factor)
  • [ ] ProxyDepositFactor - parent chain / (factor)
  • [ ] MaxProxies - I would like to bump this up higher here to allow issuer groups
  • [ ] AnnouncementDepositBase - parent chain / (factor)
  • [ ] AnnouncementDepositFactor - parent chain / (factor)
  • [ ] MaxPending - same as parent chain

• [x] Statemine chain spec #82
• [x] add consensus support for transitioning from Shell to Statemine https://github.com/paritytech/statemint/pull/80
• [x] test Shell -> Statemine upgrade process on a local Rococo

Final steps to deploy Statemine on Kusama:

• [x] Ability to upgrade from Shell
• [x] Call filter https://github.com/paritytech/statemint/issues/64
• [x] Statemine config https://github.com/paritytech/statemint/issues/14 (using shell chainspec)
• [x] Shell -> Statemine runtime upgrade #81
• [x] Merge and include https://github.com/paritytech/substrate/pull/8935 (freezer can be in an upgrade)
• [x] Update Substrate/Cumulus/Polkadot dependencies https://github.com/paritytech/statemint/pull/83
• [x] Final weights https://github.com/paritytech/statemint/pull/56

currently benchmarks are taken from the substrate repo. Both I and @kianenigma feel this is not optimal going forward. We should run all benchmarks for used pallets that need them as well as create an optimal flow to run them before releases

Some assets, as allowed by the Relay Chain, will be accepted for the payment of transaction fees. The abstract logic should be handled in pallet-transaction-payment. This parachain will need the following:

• [ ] Functions to allow/forbid the payment of transaction fees with a given AssetId
• [ ] Function to set the DOT/KSM to Asset ratio with which to convert native fees
• [ ] Privileged origins for these functions. Ideally setting the ratio has a unique origin that could be passed off to an oracle at some point in the future.