Skip to content

Commit

Permalink
Merge branch 'main' of https://github.com/invarch/InvArch-Frames into…
Browse files Browse the repository at this point in the history 
… gabriel-general_fixes
  • Loading branch information
@arrudagates
arrudagates committed Mar 18, 2024
2 parents a0273e1 + fecfbd8 commit 634af7d
Show file tree
Hide file tree
Showing 15 changed files with 652 additions and 243 deletions.
22 changes: 8 additions & 14 deletions .github/workflows/build.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -14,39 +14,33 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
with:
toolchain: nightly-2022-09-01
- name: Install & display rust toolchain
run: rustup show
- name: Build
run: cargo build --verbose

test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
with:
toolchain: nightly-2022-09-01
- name: Install & display rust toolchain
run: rustup show
- name: Run tests
run: cargo test --verbose

clippy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
with:
toolchain: nightly-2022-09-01
components: clippy
- name: Install & display rust toolchain
run: rustup show
- name: Run clippy
run: cargo clippy -- -D warnings
fmt:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
with:
toolchain: nightly-2022-09-01
components: rustfmt
- name: Install & display rust toolchain
run: rustup show
- name: Run cargofmt
run: cargo fmt --all -- --check
17 changes: 0 additions & 17 deletions INV4/README.md
View file

This file was deleted.

137 changes: 28 additions & 109 deletions INV4/pallet-inv4/README.md
View file
Original file line number Diff line number Diff line change
@@ -1,124 +1,43 @@
[![Compatible with Substrate v3.0.0](https://img.shields.io/badge/Substrate-v3.0.0-E6007A)](https://github.com/paritytech/substrate/releases/tag/v3.0.0)
# INV4 Pallet

# IPS Pallet: IP Sets for Substrate
## Introduction

This is a Substrate [Pallet](https://substrate.dev/docs/en/knowledgebase/runtime/pallets) that defines basic functions
to create and manage sets of [intellectual property (IP)](https://en.wikipedia.org/wiki/Intellectual_property) stored as [non-fungible tokens (NFTs)](https://en.wikipedia.org/wiki/Non-fungible_token).
The INV4 pallet is designed to manage advanced virtual multisigs, internally referred to as cores. It provides the functionality to create cores, mint and burn the core's voting tokens, and manage multisig proposals. This pallet is a comprehensive solution for decentralized decision-making processes, allowing for flexible and secure management of multisig operations.

# IP Set : Non-Fungible Folders of IP Files & other IP Sets
## Features

The following **components** are defined:
- **Core Creation**: Establish new cores with customizable parameters, including metadata, voting thresholds, and token freeze state.
- **Token Management**: Mint and burn the core's voting tokens to manage the voting power within the core.
- **Multisig Proposals**: Create, vote on, and cancel multisig proposals. Proposals automatically execute if they meet the execution threshold requirements.
- **Vote Management**: Members can vote on proposals, withdraw their votes, and influence the outcome of decisions.
- **Parameter Adjustment**: Core parameters, such as voting thresholds and token freeze state, can be dynamically adjusted by core origins.

* `IPSet` + Metadata
## Functionality Overview

The following **callab efunctions** are possible:
### Core Management

* `create_ips` - Create a new IP Set
* `destroy` - Delete an IP Set and all of its contents
* `append` - Append an IP Set with other assets / subassets
* `remove` - Remove assets / subassets from an IP Set
* `allow_replica` - Allow an IP Set to be replicated
* `disallow_replica` - Disallow an IP Set to be replicated
* `create_replica` - Replicate a replica from an IP Set
- `create_core`: Initialize a new core with specific parameters and distribute initial voting tokens to the creator.
- `set_parameters`: Modify core parameters, including voting thresholds, metadata, and token freeze state.

### Token Operations

# IP Set
- `token_mint`: Mint the core's voting tokens to a specified target, increasing their voting power within the core.
- `token_burn`: Burn the core's voting tokens from a specified target, decreasing their voting power.

This standard defines how **Sets** of related IP Tokens are minted.
### Multisig Operations

In context an IP Set is viewed as an idea, which consists of one or more components (IP Tokens) that help to strenghthen and describe that idea.
- `operate_multisig`: Submit a new multisig proposal. If the proposal meets execution thresholds, it is automatically executed.
- `vote_multisig`: Cast a vote on an existing multisig proposal. Proposals execute automatically if they meet threshold requirements after the vote.
- `withdraw_vote_multisig`: Withdraw a previously cast vote from a multisig proposal.
- `cancel_multisig_proposal`: Cancel an existing multisig proposal. This action can only be performed by a core origin.

For example, a 3D rendering of a flux capacitor prototype could be stored as an IP Token representing an STL file.
Additionally, an XML file explaining the relation between flux capacitors different components could also be stored as an IP Token.
in the "Flux Capacitor" IP Set, these two files exists and help to strengethen and expand on the idea for building an flux capacitor.
Every IP Token must have a parent IP Set it belongs to.
### Utility Functions

## IP Set Standard
- `CoreAccountDerivation`: Derive consistent core AccountIds across parachains for seamless interaction.
- `INV4Lookup`: Custom account lookup implementation for converting CoreIds to AccountIds.
- `FeeAsset`: Define the asset used by the multisig for paying transaction fees.
- `MultisigFeeHandler`: Manage fee payments for multisig operations, supporting both native and non-native assets.

An IP Set MUST adhere to the following standard.
## Usage

```json
{
"name": {
"type": "string",
"description": "Name of the IP Set. Name must be limited to alphanumeric characters. Underscore is allowed as word separator. E.g. HOVER-CRAFT is NOT allowed. HOVER_CRAFT is allowed."
},
"ipsId": {
"type": "u64",
"description": "The ID of an existing IPS owned by the current caller, can be found in events after minting or in storage"
},
"metadata": {
"type": "Vec<u8>",
"description": "Free to use any value as this won't affect logic and is intended to be used by dApp developers"
},
"data": {
"type": "H256",
"description": "An IPFS CID hash, intended to be the content identifier of the actual file, can be taken from CID here: https://cid.ipfs.io by copying the Digest (Hex) field"
},
}
```

When either metadata or [data](#data) is present, the other is optional. Data takes precedence
always. Note that because metadata contains description, attributes, third party URLs, etc. it is
still recommended to include it alongside `data`.

### Data

The `data` object is composed of:

- protocol (strict, see Protocols below)
- data
- type (mime type)

#### Protocols

| Protocol | Mime default | Description |
| --------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `ipfs` | image/png | Points to a directly interpretable resource, be it audio, video, code, or something else |
| `http(s)` | image/html | Points to a directly interpretable resource, be it audio, video, code, or something else (not recommended for use) |
| `p5` | application/javascript | Processing.js code |
| `js` | application/javascript | Plain JS code |
| `html` | text/html | HTML code, no need for `<html>` and `<body>`, can support dependencies but it's up to the author to prevent the dependencies from disappearing |
| `svg` | image/svg+xml | SVG image data |
| `bin` | n/a | binary, directly interpretable |

## Metadata

A collection SHOULD have metadata to describe it and help visualization on various platforms.

```json
{
"description": {
"type": "string",
"description": "Description of the IP Set as a whole. Markdown is supported."
},
"category": {
"type": "string",
"description": "A string citing the IP Set's category. Markdown is supported."
},
"sub_category": {
"type": "string",
"description": "A string citing the IP Set's sub-category, relative to its primary category. Markdown is supported."
},
"attributes": {
"type": "array",
"description": "An Array of JSON objects, matching OpenSea's: https://docs.opensea.io/docs/metadata-standards#section-attributes"
},
"external_url": {
"type": "string",
"description": "HTTP or IPFS URL for finding out more about this idea. If IPFS, MUST be in the format of ipfs://ipfs/HASH"
},
"image": {
"type": "string",
"description": "HTTP or IPFS URL to idea's main image, in the vein of og:image. If IPFS, MUST be in the format of ipfs://ipfs/HASH"
},
"image_data": {
"type": "string?",
"description": "[OPTIONAL] Use only if you don't have the image field (they are mutually exclusive and image takes precedence). Raw base64 or SVG data for the image. If SVG, MUST start with <svg, if base64, MUST start with base64:"
}
}
```

## Testing Documentation

[IPS Testing Documentation](https://gist.github.com/arrudagates/877d6d7b56d06ea1a941b73573a28d3f#file-ips-md)
To utilize the INV4 pallet, users must first create a core and receive initial voting tokens. Cores can propose actions, vote on proposals, and execute decisions based on the collective voting power of their members. The pallet's flexible design supports a wide range of multisig use cases, from simple governance decisions to complex, conditional executions.
3 changes: 0 additions & 3 deletions OCIF/README.md
View file

This file was deleted.

72 changes: 32 additions & 40 deletions OCIF/staking/README.md
View file
Original file line number Diff line number Diff line change
@@ -1,55 +1,47 @@
# pallet-ocif-staking
# OCIF Staking Pallet

## OCIF Staking pallet
A pallet for for allowing INV-Cores to be staked towards.
## Overview

The OCIF Staking Pallet is a pallet designed to facilitate staking towards INV-Cores within a blockchain network. This pallet introduces a staking mechanism that allows two distinct sets of entities, namely Cores and Stakers, to participate in the distribution of tokens from a predefined pot. The allocation of rewards is determined based on the amount staked by each entity and the total stake towards each Core.

### Overview
### Cores

This pallet provides functionality to allow 2 sets of entities to participate in distribution of tokens
available in a predefined pot account.
The tokens provided to the pot account are to be handled by the Runtime,
either directly or with the assistance of another pallet.
Cores represent virtual accounts identified by unique IDs, which are responsible for registering themselves within the staking ecosystem. The primary role of Cores is to attract Stakers to lock tokens in their favor. The rewards allocated to Cores are proportional to the total amount staked towards them by Stakers. However, for a Core to be eligible for rewards, it must have a total stake above a predefined threshold, thereby becoming `active`.

The 2 entity sets will be referred to in code as Cores and Stakers:
### Stakers

#### Cores
Cores are virtual accounts that have an ID used to derive their own account address,
their task in the process is to register themselves and have Stakers lock tokens in favor of a specifc Core.
Cores receive their fraction of the pot rewards based on the total amount staked towards them by Stakers,
however, a Core must have total stake above the defined threshold (making it `active`), otherwise they won't be entitled to rewards.
Stakers are individual accounts that engage in locking tokens in favor of a Core. Unlike Cores, Stakers receive a fraction of the rewards based on their own stake.

#### Stakers
Stakers are any account existing on the chain, their task is to lock tokens in favor of a Core.
Unlike Cores, Stakers get their fraction of the rewards based on their own stake and regardless of
the `active` state of the Core they staked towards.
## Runtime Configuration Parameters

- `BlocksPerEra`: Defines the duration of an era in terms of block numbers.
- `RegisterDeposit`: Specifies the deposit amount required for Core registration.
- `MaxStakersPerCore`: Limits the maximum number of Stakers that can simultaneously stake towards a single Core.
- `MinimumStakingAmount`: Sets the minimum amount required for a Staker to participate in staking.
- `UnbondingPeriod`: Determines the period, in eras, required for unbonding staked tokens.
- `RewardRatio`: Establishes the distribution ratio of rewards between Cores and Stakers.
- `StakeThresholdForActiveCore`: Sets the stake threshold required for a Core to become `active`.

### Relevant runtime configs
## Dispatchable Functions

* `BlocksPerEra` - Defines how many blocks constitute an era.
* `RegisterDeposit` - Defines the deposit amount for a Core to register in the system.
* `MaxStakersPerCore` - Defines the maximum amount of Stakers allowed to stake simultaneously towards the same Core.
* `MinimumStakingAmount` - Defines the minimum amount a Staker has to stake to participate.
* `UnbondingPeriod` - Defines the period, in blocks, that it takes to unbond a stake.
* `RewardRatio` - Defines the ratio of balance from the pot to distribute to Cores and Stakers, respectively.
* `StakeThresholdForActiveCore` - Defines the threshold of stake a Core needs to surpass to become active.
- `register_core`: Allows Cores to register themselves in the system.
- `unregister_core`: Enables Cores to unregister from the system, initiating the unbonding period for Stakers.
- `change_core_metadata`: Changes the metadata associated to a Core.
- `stake`: Allows Stakers to lock tokens in favor of a Core.
- `unstake`: Unstakes tokens previously staked to a Core, starting the unbonding period.
- `withdraw_unstaked`: Allows Stakers to withdraw tokens that have completed the unbonding period.
- `staker_claim_rewards`: Allows Stakers to claim available rewards.
- `core_claim_rewards`: Allows rewards to be claimed for Cores.
- `halt_unhalt_pallet`: Allows Root to trigger a halt of the system, eras will stop counting and rewards won't be distributed.

**Example Runtime implementation can be found in [src/testing/mock.rs](./src/testing/mock.rs)**
## Events

### Dispatchable Functions
The pallet emits events such as `Staked`, `Unstaked`, `CoreRegistered`, `CoreUnregistered`, and others to signal various operations and state changes within the staking ecosystem.

* `register_core` - Registers a Core in the system.
* `unregister_core` - Unregisters a Core from the system, starting the unbonding period for the Stakers.
* `change_core_metadata` - Changes the metadata tied to a Core.
* `stake` - Stakes tokens towards a Core.
* `untake` - Unstakes tokens from a core and starts the unbonding period for those tokens.
* `withdraw_unstaked` - Withdraws tokens that have already been through the unbonding period.
* `staker_claim_rewards` - Claims rewards available for a Staker.
* `core_claim_rewards` - Claims rewards available for a Core.
* `halt_unhalt_pallet` - Allows Root to trigger a halt of the system, eras will stop counting and rewards won't be distributed.
## Errors

[`Call`]: ./enum.Call.html
[`Config`]: ./trait.Config.html
Errors such as `StakingNothing`, `InsufficientBalance`, `MaxStakersReached`, and others are defined to handle exceptional scenarios encountered during pallet operations.

License: GPLv3
## Example Runtime Implementation

For an example runtime implementation that integrates this pallet, refer to [src/testing/mock.rs](./src/testing/mock.rs).
Loading

0 comments on commit 634af7d

Please sign in to comment.