Implement docs for accumulator and nft modules (#5)

* docs

proto/cosmos/nft/tx.proto

@@ -12,16 +12,14 @@ option go_package = "github.com/cosmos/cosmos-sdk/x/nft/types";
 
 // Msg defines the Msg service.
 service Msg {
-  // Balance queries the number of NFTs of a given class owned by the owner, same as balanceOf in ERC721
-  rpc Undelegate(MsgUndelegate) returns (MsgUndelegateResponse);
-
-  rpc Delegate(MsgDelegate) returns (MsgDelegateResponse);
-
-  // Class queries an NFT class based on its id
   rpc Send(MsgSend) returns (MsgSendResponse);
 
   rpc Withdraw (MsgWithdrawal) returns (MsgWithdrawalResponse);
 
+  rpc Undelegate(MsgUndelegate) returns (MsgUndelegateResponse);
+
+  rpc Delegate(MsgDelegate) returns (MsgDelegateResponse);
+
   rpc Redelegate ( MsgRedelegate) returns (MsgRedelegateResponse);
 }
 

x/accumulator/README.md

@@ -0,0 +1,8 @@
+<!--
+order: 0
+-->
+
+# Accumulator
+
+* [Accumulator](spec/README.md) - The accumulator module is designed to be the
+primary accumulator and distributor of the native tokens in the system. 

x/accumulator/spec/01_concepts.md

@@ -0,0 +1,44 @@
+<!--
+order: 1
+-->
+
+# Concepts
+
+## The accumulator module
+The accumulator module is designed to be the primary accumulator and
+distributor of the native tokens in the system. According to System
+tokenomics, all native tokens issued in the system will be minted to the 
+accumulator module balance in the genesis block. By operating the
+module configuration and business logic, the module will be able to 
+dispose of funds according to System tokenomics.
+
+
+Token distribution requirements:
+* All tokens should be issued to the accumulator module account in the
+genesis block;
+* Module should be configured to split all tokens into three treasures:
+  * community (admin) treasury; 
+  * NFT shard treasury;
+  * validator treasury;
+* Validator treasury will be used to cover validators' rewards with linear distribution during 48 months according to the voting power;
+* NFT shard treasury will be used by the NFT module and implies the locking tokens till some data in the non-fungible token can be staked;
+* Admin treasury will have the self-inner distribution partially configured in the genesis block. This distribution implies the following distribution flows:
+  * Tokens will be split into the launch and cliff parts;
+  * Launch part of tokens should be transferred to the admin’s
+  accounts in the genesis block;
+  * Cliff parts of tokens will have different unlock periods (period
+  after the distribution starts);
+  * Cliff parts can optionally follow the linear distribution during
+  the fixed period (by default - it should be the immediate
+  transfer to the receiver);
+  * Cliff parts receiver accounts can be optionally configured later
+  with the System master admin;
+
+Linear distribution or linear unlocking during a certain fixed period involves dividing the entire amount into several equal
+parts and being able to transfer (or receive) these parts each time at the same interval.
+
+
+
+
+
+

x/accumulator/spec/02_end_block.md

@@ -0,0 +1,24 @@
+<!--
+order: 3
+-->
+
+## Overview
+
+The `EndBlocker` function handles the vesting process for administrators (admins) by updating their vesting state at the end of each block. 
+This ensures that admins receive their allocated rewards based on the vesting schedule. Locked tokens are stored on accumulator pull address.
+
+## Purpose of EndBlocker
+
+The `EndBlocker` function updates the vesting state for each admin, distributing the rewards to their accounts based on the vesting schedule.
+
+### Key Steps
+
+1. **Retrieve Admins**: The function retrieves all admins.
+2. **Check Vesting Period**: It checks if the current block time is greater than or equal to the last vesting time plus the vesting period.
+3. **Check Vesting Counter**: It ensures that the vesting counter has not reached the maximum number of vesting periods.
+4. **Distribute Rewards**: If both conditions are met, it distributes the reward to the admin's account.
+5. **Increment Counter**: It increments the vesting counter and updates the last vesting time.
+
+
+The `EndBlocker` function is crucial for maintaining the correct vesting state for admins, ensuring that they receive the amount that has
+vested over time according to the specified schedule.

x/accumulator/spec/03_client.md

@@ -0,0 +1,70 @@
+
+# Client
+
+## Query
+
+
+### Admins
+This query returns list of admins
+
+#### CLI
+
+```sh
+simd noaccumulator admins --flags"
+```
+
+Example:
+```
+simd-cored query noaccumulator admins
+```
+Example Output:
+
+```
+admins: ["bridge103n4cmjt2je8nqcxg9y9desyhy6m57u52kkuc4"]
+pagination:
+  next_key: null
+  total: "0"
+```
+
+#### HTTP
+
+This query returns list of admins
+```
+cosmos/cosmos-sdk/accumulator/admins
+```
+
+Example:
+```
+http://localhost:1317/cosmos/cosmos-sdk/accumulator/admins
+```
+Example Output
+```
+{
+  "admins": ["bridge103n4cmjt2je8nqcxg9y9desyhy6m57u52kkuc4"], 
+  "pagination": {
+    "next_key": null,
+    "total": "0"
+  }
+}
+```
+
+
+## Message
+
+### AddAdmin
+
+This message is used to add a new admin to the `accumulator` module.
+
+```protobuf
+message MsgAddAdmin {
+  string creator = 1;
+  string address = 2;
+  cosmos.base.v1beta1.Coin reward_per_period = 3 [(gogoproto.nullable) = false];
+  int64 vesting_periods_count = 4;
+  string denom = 5;
+  int64 vesting_period = 6;
+}
+
+message MsgAddAdminResponse {}
+```
+

x/accumulator/spec/README.md

@@ -0,0 +1,17 @@
+<!--
+order: 0
+title: Accumulator Overview
+parent:
+  title: "Accumulator"
+-->
+
+# `Accumulator`
+
+## Contents
+
+1 **[Concept](01_concepts.md)**
+
+2 **[End-Block](02_end_block.md)**
+
+3 **[Client](03_client.md)**
+

x/nft/README.md

@@ -0,0 +1,8 @@
+<!--
+order: 0
+-->
+
+# NFT
+
+* [NFT](spec/README.md) - The NFT module is primarily created for a special type of system of
+  non-fungible tokens that hold locked native tokens and can be staked

x/nft/spec/01_concepts.md

@@ -0,0 +1,25 @@
+<!--
+order: 1
+-->
+
+# Concepts
+
+## The NFT module
+
+The NFT module is primarily created for a special type of system of 
+non-fungible tokens that hold locked native tokens and can be staked.
+
+
+## Module requirements: 
+* The module implements the non-fungible token based methods;
+* Module configuration implies the tokens distribution in the genesis
+block as well as token mint by the System master admin in the future;
+* From the architectural perspective - each token represents an independent balance with locked tokens and tokens available for withdrawal;
+* Besides owner and metadata URL, each token is characterized by the number of locked tokens and unlock period during which tokens will be unlocked linearly;
+* Each token can be delegated or undelegated using built-in methods, which means the standard delegation or undelegation of the whole token balance by the token owner;
+* Each delegated token is able to collect rewards that can be immediately withdrawn by the token owner;
+* If the token is not delegated and contains unlocked tokens - they can be immediately withdrawn from the token balance;
+* If the token is delegated, it should not be able to transfer the token ownership;
+* Token withdrawal implies the transfer of the corresponding amount of tokens from the NFT shard treasury to the token owner account;
+* The locked amount in the minted NFTs can not exceed the amount in the NFT shard treasury;
+* There should not be any other way to access the NFT shard treasury tokens besides withdrawing unlocked tokens from NFT.

x/nft/spec/02_state.md

@@ -0,0 +1,53 @@
+# State
+
+## NFT
+
+Each NFT is represented in the blockchain by a unique address. This address is used to store a balance and to stake this balance to a validator. To generate an NFT address, the following code snippet can be used:
+
+```go
+sdk.Bech32ifyAddressBytes("bridge", address.Derive(authtypes.NewModuleAddress(acumulatortypes.ModuleName), []byte(strconv.FormatInt(id, 10))))
+```
+
+The NFT object contains specific information to describe a token:
+
+```protobuf
+message NFT {
+  string address = 1;
+  string owner = 2;
+  string uri = 3;
+  int64 vesting_period = 4;
+  cosmos.base.v1beta1.Coin reward_per_period = 5 [(gogoproto.nullable) = false];
+  int64 vesting_periods_count = 6;
+  cosmos.base.v1beta1.Coin available_to_withdraw = 7 [(gogoproto.nullable) = false];
+  int64 last_vesting_time = 8;
+  int64 vesting_counter = 9;
+  string denom = 10;
+}
+```
+
+There are several commands to update the NFT store:
+
+- To add a new NFT or update an existing NFT, use `SetNFT(ctx sdk.Context, v types.NFT)`.
+- To remove an NFT, use `RemoveNFT(ctx sdk.Context, address string)`, where `address` is the unique address of the NFT.
+- To get an NFT by address, use `GetNFT(ctx sdk.Context, address string)`, where `address` is the unique address of the NFT.
+- To get all NFTs, there are two methods (with and without pagination):
+    - `GetNFTsWithPagination(ctx sdk.Context, pagination *query.PageRequest) ([]types.NFT, *query.PageResponse, error)`
+    - `GetNFTs(ctx sdk.Context) (list []types.NFT)`
+
+## Owner
+
+The Owner struct matches the NFT holder (owner) address with the NFT address:
+
+```protobuf
+message Owner {
+  string address = 1;
+  string nft_address = 2;
+}
+```
+
+There are several commands to update the owner store:
+
+- To add a new NFT owner, use `SetOwnerNFT(ctx sdk.Context, owner, nftAddress string)`. This function creates a new branch in the store where the key is the owner address, and the leaf in this branch is the Owner object.
+- To remove the NFT owner, use `RemoveOwnerNft(ctx sdk.Context, owner string, nftAddress string)`.
+- To get all NFTs by owner address, use `GetAllNFTsByOwnerWithPagination(ctx sdk.Context, ownerAddress string, pagination *query.PageRequest) ([]types.NFT, *query.PageResponse, error)`.
+- To get all addresses that hold any NFT `GetAllOwnersWithPagination(ctx sdk.Context, pagination *query.PageRequest) ([]string, *query.PageResponse, error)`

x/nft/spec/03_end_block.md

@@ -0,0 +1,32 @@
+<!--
+order: 3
+-->
+# End Block: NFT Vesting Update
+
+## Overview
+
+The `EndBlocker` function is responsible for updating the vesting state of each NFT at the end of each block. This ensures that NFT owners can only withdraw the available amount as per the vesting schedule.
+
+## NFT Vesting Information
+
+Each NFT contains vesting information structured as follows:
+
+- **Vesting Period**: The period (in seconds) between each vesting event.
+- **Reward Per Period**: The amount of reward to be vested per period.
+- **Vesting Periods Count**: The total number of vesting periods.
+- **Available to Withdraw**: The amount available for withdrawal.
+- **Last Vesting Time**: The timestamp of the last vesting event.
+- **Vesting Counter**: The current count of how many periods have vested.
+
+## Purpose of EndBlocker
+
+The `EndBlocker` function updates the vesting state for each NFT, ensuring that the available amount to withdraw is updated based on the vesting schedule.
+
+### Key Steps
+
+1. **Retrieve NFTs**: The function retrieves all NFTs.
+2. **Check Vesting Period**: It checks if the current block time is greater than or equal to the last vesting time plus the vesting period.
+3. **Check Vesting Counter**: It ensures that the vesting counter has not reached the maximum number of vesting periods.
+4. **Update Available Amount**: If both conditions are met, it calculates the new available amount to withdraw based on the reward per period and updates the `Available to Withdraw` field.
+5. **Increment Counter**: It increments the vesting counter and updates the last vesting time.
+