Token claims and vesting

[MOZGIII]

This is a tracking issue for token claims and vesting implementation.

---

pallet-token-claims (#427)

Design decisions

• We abstract the vesting and signature validation via traits and test them with mocks so we simply ensure all possible trait method behaviors are properly handled.
• We do not support signing statements, just the claim itself. If we were to implement it, as long as there is only one kind of statement we need to sign (i.e. it's not parametrized), no changes are needed at pallet-token-claims, and the changes can simply be offloaded into the eip712-token-claim. If we need to parameterize the changes - we'll have to alter both the pallet-token-claims and eip712-token-claim.
• The claiming will be implemented as a signed extrinsic (no unsigned version). This means token claimers will have to get tokens from somewhere to cover the transaction fee before they can send the token claim extrinsic - likely from an exchange or a bridge. Will we have the necessary integrations at launch? Where do we take the tokens from.
• For simplicity's sake, we don't implement moving claims or minting claims, as well as any other claiming mechanisms but the claim call.
• The tokens for the claiming have to be stored in some system-level account while they are not claimed, so the total issuance looks right. This requires that the system account is properly initialized with the balance equaling to the existential balance + sum of all claims. We will implement a failsafe at the genesis that would ensure the proper state of the balance of the system account. We will also check the total sum of the claimable balance against the manually entered expected value, just to ensure that the genesis works properly.
• We keep the claims information in a simple "ethereum address to claim info" map, representing one possible claim per eth address. We might reconsider this design in case the public sale requirements change - for instance if we need to represent more than one claim descriptor per address.

To do

See:

• Token claims #427

pallet-token-claims changes to make token claims free (#443)

See:

• Claim tokens for free #443

eip712-token-claim (#431)

Notes

We don't implement the trait from pallet-token-claims directly at eip712-token-claim, but instead, do it at the runtime; we also run the tests there.

To do

See:

• Token Claims EIP712 signature verification (and ethereum primitives switch) #431

pallet-vesting (#429)

Design decisions

• Vesting pallet provides a runtime-internal pub fn for locking the balance under vesting and externally callable fn (an extrinsic) for unlocking vested balance;
• The balance is actually locked via LockableCurrency trait implementation.
• We implement a straightforward approach. The pallet will support only one lock / vesting schedule per account. No merging or combining of the vestings.
• Scheduling implementation will be abstracted via a scheduling driver - something that is capable of tracking the schedule progress and computing the balance value that should be under lock at any given time for the provided vesting schedule and initial vested balance parameters.
• If we need to support multiple vesting periods for a single account we will implement that logic as an implementation detail of the schedule. The idea is as follows: we can have an arbitrary scheduling logic, so we can have an implementation of the calculation that takes a list of schedules, computes each of them and then sums the results to get a final amount of balance under lock.

To do

See:

• Vesting #429

Runtime

To do

See:

• Integrate token claims and vesting into the runtime #441
• Token claims and vesting runtime tests #445
• Token claims and vesting benchmarks #446

[MOZGIII]

An update on the token claims design: we need to make the claim tx free.