• [x] mint IPF
• [x] burn IPF
• [x] create IPS
• [x] destroy IPS
• [x] append IPS
• [x] remove IPS
• [x] allow replica IPS
• [x] disallow replica IPS
• [x] create replica IPS
• [x] mint IPT
• [x] burn IPT
• [x] operate multisig IPT
• [x] vote multisig IPT
• [x] withdraw vote multisig IPT
• [x] create sub asset IPT
• [x] set permission IPL
• [x] set asset weight IPL

In IPT we used to define execution threshold as total_issuance / threshold, but with the introduction of sub assets which can also vote, it's necessary to redefine where the total issuance comes from, the ups and downsides of each approach need to be evaluated. Some of the possible approaches include:

• Just using the root IPT's issuance
• Using the issuance of root IPT + all sub assets
• Using only the issuance of all assets present in the multisig operation
• Having a formula that uses the issuance of all assets but takes their weights in consideration

Pallet IPL uses Percent for execution threshold and voting weights, but Percent describes the range between 0 and 1 non-inclusive, meaning it's not possible to set those fields to 1 as the max for Percent is 99.

This PR will refactor the users field of the DEV, accommodating the allocation and role of that user. The PR is not complete yet, so it will be opened as a draft PR.

• [X] Fix benchmarking on pallet-ipl
• [X] Fix benchmarking on pallet-ipf
• [x] Fix benchmarking on pallet-ips
• [x] Fix benchmarking on pallet-ipt

and also merge development

With the merge of Pallet IPL, IPT and IPS tests were disabled and need to be updated before they can be re-enabled, this issue tracks both their update and their re-enabling.

If you remove your vote from a multisig operation it returns what you paid for fees. If you are the creator of that multisig, and you withdraw it will cancel the whole multisig and return everyone's fees.

TODO:

• [x] Cargo toml, README
• [x] Config, Event, Error, Storage
• [x] Function register
• [x] Functions unregister
• [x] Function bond-and-stake
• [x] Function unbond-and-unstake
• [x] Function withdraw_unbond
• [x] Function claim
• [x] Function force_new_era
• [x] Functions owner_pre_approval and enable_owner_pre_approval
• [x] Pallet's Implementation

This PR will add the custom multisig pallet and the SmartIP pallet, will also refactor the codebase to remove unnecessary crates and change IPT to IPF

This PR fixes the Amend function that was actually minting new IPTs instead of changing the original, it also fully implements unit tests for all functions. Closes #20

• Add get free_balance, reserved_balance and account balance functions
• [Need help] There's reducancy from get_balance function from storage in line #156. Should we just stick to the get_balance from storage?

This issue will keep track of progress towards the INV4 v2 implementation, along with discussions of the feature set and design decisions.

• [ ] Replace voting logic with pallet-ranked_collective, while having the ranked-collective ranks and rank weight inputs come from INV4 itself, thus keeping the original logic of INV4 and only delegating the raw voting logic to ranked-collective as a better standardized API.
• [ ] Refactor the voting weights to implement CurrencyToVote instead of raw Balance
• [ ] Detach IPF and RMRK from INV4 and instead replace with a cusotm trait that requires the implementastion of all the necessary functions for NFTs on pallet-inv4, making INV4 a true generalized NFT wrapper where NFT pallets implement the INV4 trait in the runtime and plug into an enum also defined in the runtime
• [ ] Implement a track system similar to pallet-referenda's so that we can customize parameters like amount of multisig calls allowed concurrently for each different subtoken
• [ ] Research and implement an efficient system for fully customizable user provided call filters for each track, similar to the current permissions system, but with an extensive rule system. See https://github.com/InvArch/InvArch-Frames/discussions/186
• [ ] Simplify IPS multisig fee system by removing the whole logic of distributing the call fee among voters and instead just take the fee from the multisig account by proceeding with the call naturally
• [ ] Rethink origin types for a more flexible account representation, using XCM's Plurality junction seems to be a great way to represent calls made by the multisig, as we can have an implementation that always derives the same account while the plurality can still dynamically represent different things, like different groups within the same IP Set and even different voting ratios. This would eliminate a bunch of checks and also make multisigs extremely powerful, while also preparing them for XCM transactions.

With these functions an IPS should be able to mint an NFT (RMRK or IPF) and automatically appending it to the data field, and also should be able to burn an NFT, removing it from the data field.

Basically when you use the operateMultisig to burn an IPF that is owned and appended to that IPS, it burns the IPF, but doesn't remove it from the IPS. On the very bottom is the IPF I just burned (IpfId 0), but you can see that the IPS still thinks it has IPF 0. Seems to me that this should be in sync. If the multisig votes to burn an IPF, then the IPS shouldn't show it still has the file as the hash has been deleted from the chain. That just doesn't make sense I think

As it currently stands, the ipt multisig fee system works by calculating how much the operator or voter should contribute for the fee and then tries to make a balance transfer from the caller account to the multisig account, in preparation for the multisig account to then be the executor of the multisig operation and pay the fee with it's transferred balance. This is not the optimal solution as it depends on an internal extrinsic that can fail. The proposed solution takes note of how Parity's multisig pallet handles fees, but first let's go through the formula we use to determine how much an operator/voter should pay, as that's not going to change.

IPT 0 has total supply of 10 tokens

Alice has 3 tokens
Bob has 3 tokens
Charlie has 4 tokens

They want to execute a multisig operation where the call to be executed has a fee of 10 varch

Let's consider this IPT has been set up to execute calls once the multisig reaches 50% of the ipt supply in votes. Meaning none of the 3 owners can execute a call alone.

So to find out how much they will each pay in fees we first have to calculate the relation between ipt and varch for this situation, we can do so with a simple formula of (fee / (execution threshold * total supply)), or in our case: (10 / (0.5 * 10)) = 2.
Then, knowing how much each ipt translates in the transaction fee, we can simply multiply that by the operator/voter's ipt amount. For example:
Alice + Charlie = 7 tokens. Alice initiates the operation, contributing 3 (ipt) * 2 (fee multiplier) = 6 varch for the multisig. Then Charlie comes along and since there's already 3 ipt in the operation, charlie only needs to vote with 2 of his 4, so he contributes 2 (ipt) * 2 (fee multiplier) = 4 varch. 
This completes the 10 varch needed for the operation!

It's a simple system and it works perfectly, so that won't need to change, however we need to rework the way we deposit the fee and the best approach is to calculate that fee alongside the extrinsic weight of the operate/vote calls, that way this gets deposited as a normal fee and we utilize native substrate fee/weight systems!