diff --git a/docs/develop/api/cosmos-grpc-rest.md b/docs/develop/api/cosmos-grpc-rest.md index d19fb19..e1391ff 100644 --- a/docs/develop/api/cosmos-grpc-rest.md +++ b/docs/develop/api/cosmos-grpc-rest.md @@ -14,4 +14,4 @@ wallets and block explorers to interact with the Proof-of-Stake logic and native [gRPC-Gateway](https://grpc-ecosystem.github.io/grpc-gateway/) reads a gRPC service definition and generates a reverse-proxy server which translates RESTful JSON API into gRPC. With gRPC-Gateway, users can use REST to interact with the Cosmos gRPC service. -See the list of supported gRPC-Gateway API endpoints using Swagger [here](../api#clients). +See the list of supported gRPC-Gateway API endpoints using Swagger [here](../api#clients). \ No newline at end of file diff --git a/docs/develop/api/ethereum-json-rpc/index.md b/docs/develop/api/ethereum-json-rpc/index.md index bf95775..352776b 100644 --- a/docs/develop/api/ethereum-json-rpc/index.md +++ b/docs/develop/api/ethereum-json-rpc/index.md @@ -31,17 +31,17 @@ Find below the JSON-RPC namespaces supported on HAQQ or head over to the documen and their respective curl commands on the [JSON-RPC Methods](./methods.md) page. | Namespace | Description | Supported | Enabled by Default | -| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------: | :----------------: | -| [`eth`](./methods.md#eth-methods) | HAQQ provides several extensions to the standard `eth` JSON-RPC namespace. | ✔ | ✔ | -| [`web3`](./methods.md#web3-methods) | The `web3` API provides utility functions for the web3 client. | ✔ | ✔ | -| [`net`](./methods.md#net-methods) | The `net` API provides access to network information of the node | ✔ | ✔ | +|---------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------:|:------------------:| +| [`eth`](./methods.md#eth-methods) | HAQQ provides several extensions to the standard `eth` JSON-RPC namespace. | ✔ | ✔ | +| [`web3`](./methods.md#web3-methods) | The `web3` API provides utility functions for the web3 client. | ✔ | ✔ | +| [`net`](./methods.md#net-methods) | The `net` API provides access to network information of the node | ✔ | ✔ | | `clique` | The `clique` API provides access to the state of the clique consensus engine. You can use this API to manage signer votes and to check the health of a private network. | 🚫 | | -| `debug` | The `debug` API gives you access to several non-standard RPC methods, which will allow you to inspect, debug and set certain debugging flags during runtime. | ✔ | | +| `debug` | The `debug` API gives you access to several non-standard RPC methods, which will allow you to inspect, debug and set certain debugging flags during runtime. | ✔ | | | `les` | The `les` API allows you to manage LES server settings, including client parameters and payment settings for prioritized clients. It also provides functions to query checkpoint information in both server and client mode. | 🚫 | | -| [`miner`](./methods.md#miner-methods) | The `miner` API allows you to remote control the node’s mining operation and set various mining specific settings. | ✔ | 🚫 | -| [`txpool`](./methods.md#txpool-methods) | The `txpool` API gives you access to several non-standard RPC methods to inspect the contents of the transaction pool containing all the currently pending transactions as well as the ones queued for future processing. | ✔ | 🚫 | +| [`miner`](./methods.md#miner-methods) | The `miner` API allows you to remote control the node’s mining operation and set various mining specific settings. | ✔ | 🚫 | +| [`txpool`](./methods.md#txpool-methods) | The `txpool` API gives you access to several non-standard RPC methods to inspect the contents of the transaction pool containing all the currently pending transactions as well as the ones queued for future processing. | ✔ | 🚫 | | `admin` | The `admin` API gives you access to several non-standard RPC methods, which will allow you to have a fine grained control over your node instance, including but not limited to network peer and RPC endpoint management. | 🚫 | | -| [`personal`](./methods.md#personal-methods) | The `personal` API manages private keys in the key store. | ✔ | 🚫 | +| [`personal`](./methods.md#personal-methods) | The `personal` API manages private keys in the key store. | ✔ | 🚫 | ## Subscribing to Ethereum Events @@ -102,8 +102,8 @@ ws ws://localhost:8546/ At present there are two key datatypes that are passed over JSON: -- **quantities** and -- **unformatted byte arrays**. +* **quantities** and +* **unformatted byte arrays**. Both are passed with a hex encoding, however with different requirements to formatting. @@ -142,4 +142,4 @@ The following options are possible for the `defaultBlock` parameter: - `HEX String` - an integer block number - `String "earliest"` for the earliest/genesis block - `String "latest"` - for the latest mined block -- `String "pending"` - for the pending state/transactions +- `String "pending"` - for the pending state/transactions \ No newline at end of file diff --git a/docs/develop/api/ethereum-json-rpc/methods.md b/docs/develop/api/ethereum-json-rpc/methods.md index 2bb746e..b9382a6 100644 --- a/docs/develop/api/ethereum-json-rpc/methods.md +++ b/docs/develop/api/ethereum-json-rpc/methods.md @@ -15,69 +15,69 @@ The examples also do not include the URL/IP & port combination which must be the ## Endpoints | Method | Namespace | Implemented | Public | Notes | -| --------------------------------------------------------------------------------- | --------- | ----------- | ------ | ------------------ | -| [`web3_clientVersion`](#web3_clientversion) | Web3 | ✔ | ✔ | | -| [`web3_sha3`](#web3_sha3) | Web3 | ✔ | ✔ | | -| [`net_version`](#net_version) | Net | ✔ | ✔ | | -| [`net_peerCount`](#net_peercount) | Net | ✔ | ✔ | | -| [`net_listening`](#net_listening) | Net | ✔ | ✔ | | -| [`eth_protocolVersion`](#eth_protocolversion) | Eth | ✔ | ✔ | | -| [`eth_syncing`](#eth_syncing) | Eth | ✔ | ✔ | | -| [`eth_gasPrice`](#eth_gasprice) | Eth | ✔ | ✔ | | -| [`eth_accounts`](#eth_accounts) | Eth | ✔ | ✔ | | -| [`eth_blockNumber`](#eth_blocknumber) | Eth | ✔ | ✔ | | -| [`eth_getBalance`](#eth_getbalance) | Eth | ✔ | ✔ | | -| [`eth_getStorageAt`](#eth_getstorageat) | Eth | ✔ | ✔ | | -| [`eth_getTransactionCount`](#eth_gettransactioncount) | Eth | ✔ | ✔ | | -| [`eth_getBlockTransactionCountByNumber`](#eth_getblocktransactioncountbynumber) | Eth | ✔ | ✔ | | -| [`eth_getBlockTransactionCountByHash`](#eth_getblocktransactioncountbyhash) | Eth | ✔ | ✔ | | -| [`eth_getCode`](#eth_getcode) | Eth | ✔ | ✔ | | -| [`eth_sign`](#eth_sign) | Eth | ✔ | ✔ | | -| [`eth_sendTransaction`](#eth_sendtransaction) | Eth | ✔ | ✔ | | -| [`eth_sendRawTransaction`](#eth_sendrawtransaction) | Eth | ✔ | ✔ | | -| [`eth_call`](#eth_call) | Eth | ✔ | ✔ | | -| [`eth_estimateGas`](#eth_estimategas) | Eth | ✔ | ✔ | | -| [`eth_getBlockByNumber`](#eth_getblockbynumber) | Eth | ✔ | ✔ | | -| [`eth_getBlockByHash`](#eth_getblockbyhash) | Eth | ✔ | ✔ | | -| [`eth_getTransactionByHash`](#eth_gettransactionbyhash) | Eth | ✔ | ✔ | | -| [`eth_getTransactionByBlockHashAndIndex`](#eth_gettransactionbyblockhashandindex) | Eth | ✔ | ✔ | | -| [`eth_getTransactionReceipt`](#eth_gettransactionreceipt) | Eth | ✔ | ✔ | | -| [`eth_newFilter`](#eth_newfilter) | Eth | ✔ | ✔ | | -| [`eth_newBlockFilter`](#eth_newblockfilter) | Eth | ✔ | ✔ | | -| [`eth_newPendingTransactionFilter`](#eth_newpendingtransactionfilter) | Eth | ✔ | ✔ | | -| [`eth_uninstallFilter`](#eth_uninstallfilter) | Eth | ✔ | ✔ | | -| [`eth_getFilterChanges`](#eth_getfilterchanges) | Eth | ✔ | ✔ | | -| [`eth_getFilterLogs`](#eth_getfilterlogs) | Eth | ✔ | ✔ | | -| [`eth_getLogs`](#eth_getlogs) | Eth | ✔ | ✔ | | -| `eth_getTransactionbyBlockNumberAndIndex` | Eth | | ✔ | | -| `eth_getWork` | Eth | N/A | ✔ | PoW-only | -| `eth_submitWork` | Eth | N/A | ✔ | PoW-only | +|-----------------------------------------------------------------------------------|-----------|-------------|--------|--------------------| +| [`web3_clientVersion`](#web3_clientversion) | Web3 | ✔ | ✔ | | +| [`web3_sha3`](#web3_sha3) | Web3 | ✔ | ✔ | | +| [`net_version`](#net_version) | Net | ✔ | ✔ | | +| [`net_peerCount`](#net_peercount) | Net | ✔ | ✔ | | +| [`net_listening`](#net_listening) | Net | ✔ | ✔ | | +| [`eth_protocolVersion`](#eth_protocolversion) | Eth | ✔ | ✔ | | +| [`eth_syncing`](#eth_syncing) | Eth | ✔ | ✔ | | +| [`eth_gasPrice`](#eth_gasprice) | Eth | ✔ | ✔ | | +| [`eth_accounts`](#eth_accounts) | Eth | ✔ | ✔ | | +| [`eth_blockNumber`](#eth_blocknumber) | Eth | ✔ | ✔ | | +| [`eth_getBalance`](#eth_getbalance) | Eth | ✔ | ✔ | | +| [`eth_getStorageAt`](#eth_getstorageat) | Eth | ✔ | ✔ | | +| [`eth_getTransactionCount`](#eth_gettransactioncount) | Eth | ✔ | ✔ | | +| [`eth_getBlockTransactionCountByNumber`](#eth_getblocktransactioncountbynumber) | Eth | ✔ | ✔ | | +| [`eth_getBlockTransactionCountByHash`](#eth_getblocktransactioncountbyhash) | Eth | ✔ | ✔ | | +| [`eth_getCode`](#eth_getcode) | Eth | ✔ | ✔ | | +| [`eth_sign`](#eth_sign) | Eth | ✔ | ✔ | | +| [`eth_sendTransaction`](#eth_sendtransaction) | Eth | ✔ | ✔ | | +| [`eth_sendRawTransaction`](#eth_sendrawtransaction) | Eth | ✔ | ✔ | | +| [`eth_call`](#eth_call) | Eth | ✔ | ✔ | | +| [`eth_estimateGas`](#eth_estimategas) | Eth | ✔ | ✔ | | +| [`eth_getBlockByNumber`](#eth_getblockbynumber) | Eth | ✔ | ✔ | | +| [`eth_getBlockByHash`](#eth_getblockbyhash) | Eth | ✔ | ✔ | | +| [`eth_getTransactionByHash`](#eth_gettransactionbyhash) | Eth | ✔ | ✔ | | +| [`eth_getTransactionByBlockHashAndIndex`](#eth_gettransactionbyblockhashandindex) | Eth | ✔ | ✔ | | +| [`eth_getTransactionReceipt`](#eth_gettransactionreceipt) | Eth | ✔ | ✔ | | +| [`eth_newFilter`](#eth_newfilter) | Eth | ✔ | ✔ | | +| [`eth_newBlockFilter`](#eth_newblockfilter) | Eth | ✔ | ✔ | | +| [`eth_newPendingTransactionFilter`](#eth_newpendingtransactionfilter) | Eth | ✔ | ✔ | | +| [`eth_uninstallFilter`](#eth_uninstallfilter) | Eth | ✔ | ✔ | | +| [`eth_getFilterChanges`](#eth_getfilterchanges) | Eth | ✔ | ✔ | | +| [`eth_getFilterLogs`](#eth_getfilterlogs) | Eth | ✔ | ✔ | | +| [`eth_getLogs`](#eth_getlogs) | Eth | ✔ | ✔ | | +| `eth_getTransactionbyBlockNumberAndIndex` | Eth | | ✔ | | +| `eth_getWork` | Eth | N/A | ✔ | PoW-only | +| `eth_submitWork` | Eth | N/A | ✔ | PoW-only | | `eth_submitHashrate` | Eth | | | | | `eth_getCompilers` | Eth | | | | | `eth_compileLLL` | Eth | | | | | `eth_compileSolidity` | Eth | | | | | `eth_compileSerpent` | Eth | | | | | `eth_signTransaction` | Eth | | | | -| `eth_mining` | Eth | | ❌ | | -| [`eth_coinbase`](#eth_coinbase) | Eth | ✔ | | | -| `eth_hashrate` | Eth | N/A | ❌ | PoW-only | +| `eth_mining` | Eth | | ❌ | | +| [`eth_coinbase`](#eth_coinbase) | Eth | ✔ | | | +| `eth_hashrate` | Eth | N/A | ❌ | PoW-only | | `eth_getUncleCountByBlockHash` | Eth | N/A | | PoW-only | | `eth_getUncleCountByBlockNumber` | Eth | N/A | | PoW-only | | `eth_getUncleByBlockHashAndIndex` | Eth | N/A | | PoW-only | | `eth_getUncleByBlockNumberAndIndex` | Eth | N/A | | PoW-only | -| [`eth_getProof`](#eth_getproof) | Eth | ✔ | | | -| [`eth_subscribe`](#eth_subscribe) | Websocket | ✔ | | | -| [`eth_unsubscribe`](#eth_unsubscribe) | Websocket | ✔ | | | -| [`personal_importRawKey`](#personal_importrawkey) | Personal | ✔ | ❌ | | -| [`personal_listAccounts`](#personal_listaccounts) | Personal | ✔ | ❌ | | -| [`personal_lockAccount`](#personal_lockaccount) | Personal | ✔ | ❌ | | -| [`personal_newAccount`](#personal_newaccount) | Personal | ✔ | ❌ | | -| [`personal_unlockAccount`](#personal_unlockaccount) | Personal | ✔ | ❌ | | -| [`personal_sendTransaction`](#personal_sendtransaction) | Personal | ✔ | ❌ | | -| [`personal_sign`](#personal_sign) | Personal | ✔ | ❌ | | -| [`personal_ecRecover`](#personal_ecrecover) | Personal | ✔ | ❌ | | -| [`personal_initializeWallet`](#personal_initializewallet) | Personal | ✔ | ❌ | | -| [`personal_unpair`](#personal_unpair) | Personal | ✔ | ❌ | | +| [`eth_getProof`](#eth_getproof) | Eth | ✔ | | | +| [`eth_subscribe`](#eth_subscribe) | Websocket | ✔ | | | +| [`eth_unsubscribe`](#eth_unsubscribe) | Websocket | ✔ | | | +| [`personal_importRawKey`](#personal_importrawkey) | Personal | ✔ | ❌ | | +| [`personal_listAccounts`](#personal_listaccounts) | Personal | ✔ | ❌ | | +| [`personal_lockAccount`](#personal_lockaccount) | Personal | ✔ | ❌ | | +| [`personal_newAccount`](#personal_newaccount) | Personal | ✔ | ❌ | | +| [`personal_unlockAccount`](#personal_unlockaccount) | Personal | ✔ | ❌ | | +| [`personal_sendTransaction`](#personal_sendtransaction) | Personal | ✔ | ❌ | | +| [`personal_sign`](#personal_sign) | Personal | ✔ | ❌ | | +| [`personal_ecRecover`](#personal_ecrecover) | Personal | ✔ | ❌ | | +| [`personal_initializeWallet`](#personal_initializewallet) | Personal | ✔ | ❌ | | +| [`personal_unpair`](#personal_unpair) | Personal | ✔ | ❌ | | | `db_putString` | DB | | | | | `db_getString` | DB | | | | | `db_putHex` | DB | | | | @@ -92,14 +92,14 @@ The examples also do not include the URL/IP & port combination which must be the | `shh_uninstallFilter` | SSH | | | | | `shh_getFilterChanges` | SSH | | | | | `shh_getMessages` | SSH | | | | -| `admin_addPeer` | Admin | | ❌ | | -| `admin_datadir` | Admin | | ❌ | | -| `admin_nodeInfo` | Admin | | ❌ | | -| `admin_peers` | Admin | | ❌ | | -| `admin_startRPC` | Admin | | ❌ | | -| `admin_startWS` | Admin | | ❌ | | -| `admin_stopRPC` | Admin | | ❌ | | -| `admin_stopWS` | Admin | | ❌ | | +| `admin_addPeer` | Admin | | ❌ | | +| `admin_datadir` | Admin | | ❌ | | +| `admin_nodeInfo` | Admin | | ❌ | | +| `admin_peers` | Admin | | ❌ | | +| `admin_startRPC` | Admin | | ❌ | | +| `admin_startWS` | Admin | | ❌ | | +| `admin_stopRPC` | Admin | | ❌ | | +| `admin_stopWS` | Admin | | ❌ | | | `clique_getSnapshot` | Clique | | | | | `clique_getSnapshotAtHash` | Clique | | | | | `clique_getSigners` | Clique | | | | @@ -108,35 +108,35 @@ The examples also do not include the URL/IP & port combination which must be the | `clique_discard` | Clique | | | | | `clique_status` | Clique | | | | | `debug_backtraceAt` | Debug | | | | -| `debug_blockProfile` | Debug | ✔ | | | -| `debug_cpuProfile` | Debug | ✔ | | | +| `debug_blockProfile` | Debug | ✔ | | | +| `debug_cpuProfile` | Debug | ✔ | | | | `debug_dumpBlock` | Debug | | | | -| `debug_gcStats` | Debug | ✔ | | | +| `debug_gcStats` | Debug | ✔ | | | | `debug_getBlockRlp` | Debug | | | | -| `debug_goTrace` | Debug | ✔ | | | -| `debug_freeOSMemory` | Debug | ✔ | | | -| `debug_memStats` | Debug | ✔ | | | -| `debug_mutexProfile` | Debug | ✔ | | | +| `debug_goTrace` | Debug | ✔ | | | +| `debug_freeOSMemory` | Debug | ✔ | | | +| `debug_memStats` | Debug | ✔ | | | +| `debug_mutexProfile` | Debug | ✔ | | | | `debug_seedHash` | Debug | | | | | `debug_setHead` | Debug | | | | -| `debug_setBlockProfileRate` | Debug | ✔ | | | -| `debug_setGCPercent` | Debug | ✔ | | | -| `debug_setMutexProfileFraction` | Debug | ✔ | | | -| `debug_stacks` | Debug | ✔ | | | -| `debug_startCPUProfile` | Debug | ✔ | | | -| `debug_startGoTrace` | Debug | ✔ | | | -| `debug_stopCPUProfile` | Debug | ✔ | | | -| `debug_stopGoTrace` | Debug | ✔ | | | -| [`debug_traceBlockByNumber`](#debug_traceblockbynumber) | Debug | ✔ | | | +| `debug_setBlockProfileRate` | Debug | ✔ | | | +| `debug_setGCPercent` | Debug | ✔ | | | +| `debug_setMutexProfileFraction` | Debug | ✔ | | | +| `debug_stacks` | Debug | ✔ | | | +| `debug_startCPUProfile` | Debug | ✔ | | | +| `debug_startGoTrace` | Debug | ✔ | | | +| `debug_stopCPUProfile` | Debug | ✔ | | | +| `debug_stopGoTrace` | Debug | ✔ | | | +| [`debug_traceBlockByNumber`](#debug_traceblockbynumber) | Debug | ✔ | | | | `debug_traceBlockFromFile` | Debug | | | | | `debug_standardTraceBlockToFile` | Debug | | | | | `debug_standardTraceBadBlockToFile` | Debug | | | | -| [`debug_traceTransaction`](#debug_tracetransaction) | Debug | ✔ | | | +| [`debug_traceTransaction`](#debug_tracetransaction) | Debug | ✔ | | | | `debug_verbosity` | Debug | | | | | `debug_vmodule` | Debug | | | | -| `debug_writeBlockProfile` | Debug | ✔ | | | -| `debug_writeMemProfile` | Debug | ✔ | | | -| `debug_writeMutexProfile` | Debug | ✔ | | | +| `debug_writeBlockProfile` | Debug | ✔ | | | +| `debug_writeMemProfile` | Debug | ✔ | | | +| `debug_writeMutexProfile` | Debug | ✔ | | | | `les_serverInfo` | Les | | | | | `les_clientInfo` | Les | | | | | `les_priorityClientInfo` | Les | | | | @@ -146,16 +146,16 @@ The examples also do not include the URL/IP & port combination which must be the | `les_latestCheckpoint` | Les | | | | | `les_getCheckpoint` | Les | | | | | `les_getCheckpointContractAddress` | Les | | | | -| [`miner_getHashrate`](#miner_gethashrate) | Miner | ✔ | ❌ | No-op | -| [`miner_setExtra`](#miner_setextra) | Miner | ✔ | ❌ | No-op | -| [`miner_setGasPrice`](#miner_setgasprice) | Miner | ✔ | ❌ | Needs node restart | -| [`miner_start`](#miner_start) | Miner | ✔ | ❌ | No-op | -| [`miner_stop`](#miner_stop) | Miner | ✔ | ❌ | No-op | -| [`miner_setGasLimit`](#miner_setgaslimit) | Miner | ✔ | ❌ | No-op | -| [`miner_setEtherbase`](#miner_setetherbase) | Miner | ✔ | ❌ | | -| [`txpool_content`](#txpool_content) | TxPool | ✔ | | | -| [`txpool_inspect`](#txpool_inspect) | TxPool | ✔ | | | -| [`txpool_status`](#txpool_status) | TxPool | ✔ | | | +| [`miner_getHashrate`](#miner_gethashrate) | Miner | ✔ | ❌ | No-op | +| [`miner_setExtra`](#miner_setextra) | Miner | ✔ | ❌ | No-op | +| [`miner_setGasPrice`](#miner_setgasprice) | Miner | ✔ | ❌ | Needs node restart | +| [`miner_start`](#miner_start) | Miner | ✔ | ❌ | No-op | +| [`miner_stop`](#miner_stop) | Miner | ✔ | ❌ | No-op | +| [`miner_setGasLimit`](#miner_setgaslimit) | Miner | ✔ | ❌ | No-op | +| [`miner_setEtherbase`](#miner_setetherbase) | Miner | ✔ | ❌ | | +| [`txpool_content`](#txpool_content) | TxPool | ✔ | | | +| [`txpool_inspect`](#txpool_inspect) | TxPool | ✔ | | | +| [`txpool_status`](#txpool_status) | TxPool | ✔ | | | :::tip Block Number can be entered as a Hex string, `"earliest"`, `"latest"` or `"pending"`. @@ -174,7 +174,7 @@ Get the web3 client version. #### Result ```json -{ "jsonrpc": "2.0", "id": 1, "result": "Haqq/1.7.0+/linux/go1.20" } + {"jsonrpc":"2.0","id":1,"result":"Haqq/1.7.0+/linux/go1.20"} ``` #### Client Examples @@ -204,11 +204,7 @@ Returns Keccak-256 (not the standardized SHA3-256) of the given data. #### Result ```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": "0x1b84adea42d5b7d192fd8a61a85b25abe0757e9a65cab1da470258914053823f" -} +{"jsonrpc":"2.0","id":1,"result":"0x1b84adea42d5b7d192fd8a61a85b25abe0757e9a65cab1da470258914053823f"} ``` #### Client Examples @@ -634,7 +630,7 @@ Returns the receipt of a transaction by transaction hash. Note: Tx Code from Tendermint and the Ethereum receipt status are switched: | | Tendermint | Ethereum | -| ------- | ---------- | -------- | +|---------|------------|----------| | Success | 0 | 1 | | Fail | 1 | 0 | @@ -1373,5 +1369,5 @@ txpool.status(); #### Result ```json -{ "jsonrpc": "2.0", "id": 1, "result": { "pending": "0x0", "queued": "0x0" } } +{"jsonrpc":"2.0","id":1,"result":{"pending":"0x0","queued":"0x0"}} ``` diff --git a/docs/develop/api/index.md b/docs/develop/api/index.md index 7532973..a3ce457 100644 --- a/docs/develop/api/index.md +++ b/docs/develop/api/index.md @@ -1,24 +1,24 @@ # API -The following API's are recommended for development purposes. For maximum control and reliability it's recommended +The following API's are recommended for development purposes. For maximum control and reliability it's recommended to run your own node. ## Networks -Quickly connect your app or client to HAQQ mainnet and public testnets. Head over to [Networks](./networks.md) +Quickly connect your app or client to HAQQ mainnet and public testnets. Head over to [Networks](./networks.md) to find a list of publicly available endpoints that you can use to connect to the HAQQ Network. ## Clients -The HAQQ Network supports different clients in order to support Cosmos and Ethereum transactions and queries. +The HAQQ Network supports different clients in order to support Cosmos and Ethereum transactions and queries. You can use Swagger as a REST interface for state queries and transactions: -| | Description | Default Port | Swagger | -| ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | :----------: | ------------------------------------------------------------------------------------------------------------------- | -| **Cosmos [gRPC](./cosmos-grpc-rest.md#cosmos-grpc)** | Query or send HAQQ transactions using gRPC | `9090` | | -| **Cosmos REST ([gRPC-Gateway](./cosmos-grpc-rest.md#cosmos-http-rest-grpc-gateway))** | Query or send HAQQ transactions using an HTTP RESTful API | `9091` | [Mainnet](https://rest.cosmos.haqq.network/swagger/) [Testnet](https://rest.cosmos.testedge2.haqq.network/swagger/) | -| **Ethereum [JSON-RPC](./ethereum-json-rpc/index.md)** | Query Ethereum-formatted transactions and blocks or send Ethereum txs using JSON-RPC | `8545` | | -| **Ethereum [Websocket](./ethereum-json-rpc/index.md#ethereum-websocket)** | Subscribe to Ethereum logs and events emitted in smart contracts. | `8586` | | -| **CometBFT [RPC](./tendermint.md)** | Query transactions, blocks, consensus state, broadcast transactions, etc. | `26657` | [Localhost](https://docs.tendermint.com/v0.34/rpc/) | -| **CometBFT [Websocket](./tendermint.md)** | Subscribe to CometBFT ABCI events | `26657` | | -| **Command Line Interface (CLI)** | Query or send HAQQ transactions using your Terminal or Console. | N/A | | +| | Description | Default Port | Swagger | +|---------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------|:------------:|---------------------------------------------------------------------| +| **Cosmos [gRPC](./cosmos-grpc-rest.md#cosmos-grpc)** | Query or send HAQQ transactions using gRPC | `9090` | | +| **Cosmos REST ([gRPC-Gateway](./cosmos-grpc-rest.md#cosmos-http-rest-grpc-gateway))** | Query or send HAQQ transactions using an HTTP RESTful API | `9091` | [Mainnet](https://rest.cosmos.haqq.network/swagger/) [Testnet](https://rest.cosmos.testedge2.haqq.network/swagger/) | +| **Ethereum [JSON-RPC](./ethereum-json-rpc/index.md)** | Query Ethereum-formatted transactions and blocks or send Ethereum txs using JSON-RPC | `8545` | | +| **Ethereum [Websocket](./ethereum-json-rpc/index.md#ethereum-websocket)** | Subscribe to Ethereum logs and events emitted in smart contracts. | `8586` | | +| **CometBFT [RPC](./tendermint.md)** | Query transactions, blocks, consensus state, broadcast transactions, etc. | `26657` | [Localhost](https://docs.tendermint.com/v0.34/rpc/) | +| **CometBFT [Websocket](./tendermint.md)** | Subscribe to CometBFT ABCI events | `26657` | | +| **Command Line Interface (CLI)** | Query or send HAQQ transactions using your Terminal or Console. | N/A | | \ No newline at end of file diff --git a/docs/develop/api/networks.md b/docs/develop/api/networks.md index 707bbe2..7ac8467 100644 --- a/docs/develop/api/networks.md +++ b/docs/develop/api/networks.md @@ -19,7 +19,7 @@ If you are searching for the protobuf interfaces, head over [here](https://buf.b ### MainNet | Endpoint | Category | Maintainer | -| -------------------------------------------------------------------- | --------------- | --------------------------------- | +|----------------------------------------------------------------------|-----------------|-----------------------------------| | [wss://rpc-ws.eth.haqq.network](wss://rpc-ws.eth.haqq.network) | `EVM Websocket` | [HAQQ](https://haqq.network) | | [https://rpc.eth.haqq.network](https://rpc.eth.haqq.network) | `EVM JSON-RPC` | [HAQQ](https://haqq.network) | | [https://rpc.tm.haqq.network](https://rpc.tm.haqq.network) | `CometBFT RPC` | [HAQQ](https://haqq.network) | @@ -34,7 +34,7 @@ If you are searching for the protobuf interfaces, head over [here](https://buf.b ### TestEdge-2 | Endpoint | Category | Maintainer | -| ---------------------------------------------------------------------------------------- | --------------- | --------------------------------- | +|------------------------------------------------------------------------------------------|-----------------|-----------------------------------| | [https://rpc-ws.eth.testedge2.haqq.network](https://rpc-ws.eth.testedge2.haqq.network) | `EVM Websocket` | [HAQQ](https://haqq.network) | | [https://rpc.eth.testedge2.haqq.network](https://rpc.eth.testedge2.haqq.network) | `EVM JSON-RPC` | [HAQQ](https://haqq.network) | | [https://rpc.tm.testedge2.haqq.network](https://rpc.tm.testedge2.haqq.network) | `CometBFT RPC` | [HAQQ](https://haqq.network) | diff --git a/docs/develop/api/swagger.md b/docs/develop/api/swagger.md index 3cbd255..b1c86fa 100644 --- a/docs/develop/api/swagger.md +++ b/docs/develop/api/swagger.md @@ -3,7 +3,6 @@ sidebar_position: 5 --- # Swagger - -HAQQ REST API Swagger available [here](https://rest.cosmos.haqq.network/swagger/). +HAQQ REST API Swagger available [here](https://rest.cosmos.haqq.network/swagger/). diff --git a/docs/develop/api/tendermint.md b/docs/develop/api/tendermint.md index 59b8e3e..6ee2c27 100644 --- a/docs/develop/api/tendermint.md +++ b/docs/develop/api/tendermint.md @@ -6,7 +6,7 @@ sidebar_position: 4 The CometBFT RPC allows you to query transactions, blocks, consensus state, broadcast transactions, etc. -The latest CometBFT RPC documentations can be found [here](https://docs.cometbft.com/v0.37/rpc/). +The latest CometBFT RPC documentations can be found [here](https://docs.cometbft.com/v0.37/rpc/). CometBFT supports the following RPC protocols: - URI over HTTP @@ -43,7 +43,7 @@ More on Events: ### Subscribing to Events via Websocket -CometBFT Core provides a [Websocket](https://docs.cometbft.com/v0.37/core/subscription) connection to subscribe +CometBFT Core provides a [Websocket](https://docs.cometbft.com/v0.37/core/subscription) connection to subscribe or unsubscribe to CometBFT `Events`. To start a connection with the CometBFT websocket you need to define the address with the `--rpc.laddr` flag when starting the node (default `tcp://127.0.0.1:26657`): @@ -67,12 +67,12 @@ has `sender` and `recipient` as `attributes`. Subscribing to this `event` would ```json { - "jsonrpc": "2.0", - "method": "subscribe", - "id": "0", - "params": { - "query": "tm.event='Tx' AND ethereum.recipient='hexAddress'" - } + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='Tx' AND ethereum.recipient='hexAddress'" + } } ``` @@ -82,12 +82,12 @@ The generic syntax looks like this: ```json { - "jsonrpc": "2.0", - "method": "subscribe", - "id": "0", - "params": { - "query": "tm.event='' AND eventType.eventAttribute=''" - } + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='' AND eventType.eventAttribute=''" + } } ``` @@ -147,27 +147,27 @@ Example response: ```json { - "jsonrpc": "2.0", - "id": 0, - "result": { - "query": "tm.event='ValidatorSetUpdates'", - "data": { - "type": "tendermint/event/ValidatorSetUpdates", - "value": { - "validator_updates": [ - { - "address": "09EAD022FD25DE3A02E64B0FE9610B1417183EE4", - "pub_key": { - "type": "tendermint/PubKeyEd25519", - "value": "ww0z4WaZ0Xg+YI10w43wTWbBmM3dpVza4mmSQYsd0ck=" - }, - "voting_power": "10", - "proposer_priority": "0" - } - ] - } + "jsonrpc": "2.0", + "id": 0, + "result": { + "query": "tm.event='ValidatorSetUpdates'", + "data": { + "type": "tendermint/event/ValidatorSetUpdates", + "value": { + "validator_updates": [ + { + "address": "09EAD022FD25DE3A02E64B0FE9610B1417183EE4", + "pub_key": { + "type": "tendermint/PubKeyEd25519", + "value": "ww0z4WaZ0Xg+YI10w43wTWbBmM3dpVza4mmSQYsd0ck=" + }, + "voting_power": "10", + "proposer_priority": "0" + } + ] + } + } } - } } ``` @@ -180,4 +180,4 @@ Here's an example with the CLI: curl -X GET "http://localhost:26657/tx_search?query=ethereum_tx.ethereumTxHash%3D0x8d43464891fac6c113e809e14dff1a3e608eae124d629799e42ca0e36562d9d7&prove=false&page=1&per_page=30&order_by=asc" -H "accept: application/json" ``` -::: +::: \ No newline at end of file diff --git a/docs/develop/crosschain.md b/docs/develop/crosschain.md index bbc04b2..5d8fcce 100644 --- a/docs/develop/crosschain.md +++ b/docs/develop/crosschain.md @@ -5,27 +5,27 @@ title: Cross-Chain Token Addresses # Cross-Chain Token Addresses -ISLM has multiple representations across different networks. The primary bridge utilized by the team is the [Axelar blockchain](https://www.axelar.network). Below are the official token addresses on other networks. For more information, please visit [Axelar documentation](https://docs.axelar.dev/resources/contract-addresses/mainnet) +ISLM has multiple representations across different networks. The primary bridge utilized by the team is the [Axelar blockchain](https://www.axelar.network). Below are the official token addresses on other networks. For more information, please visit [Axelar documentation](https://docs.axelar.dev/resources/contract-addresses/mainnet) ## Mainnet -| Network | ID | Token Symbol | Address | -| --------- | --------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------- | -| Ethereum | ethereum | aISLM | [0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5](https://etherscan.io/address/0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5) | -| Polygon | polygon | aISLM | [0x4E7A6031B7282431ff9cBC016dA2E7e50e0C54A4](https://polygonscan.com/address/0x4E7A6031B7282431ff9cBC016dA2E7e50e0C54A4) | -| Arbitrum | arbitrum | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://arbiscan.io/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Avalanche | avalanche | aISLM | [0xB5D8c52B65c24B020c51736D22F8bd961A281909](https://snowtrace.io/address/0xB5D8c52B65c24B020c51736D22F8bd961A281909) | -| Base | base | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://basescan.org/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| BNB Chain | binance | aISLM | [0xB208C4451bc3DE576a836406bD785951b939503E](https://bscscan.com/address/0xB208C4451bc3DE576a836406bD785951b939503E) | -| Blast | blast | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://blastscan.io/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Celo | celo | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://celoscan.io//address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Fantom | fantom | aISLM | [0xB208C4451bc3DE576a836406bD785951b939503E](https://ftmscan.com/address/0xB208C4451bc3DE576a836406bD785951b939503E) | -| Filecoin | filecoin | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://filfox.info/en/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Filecoin | filecoin | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://filfox.info/en/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Fraxtal | fraxtal | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://fraxscan.com/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Kava | kava | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://kavascan.com/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Linea | linea | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://lineascan.build/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Mantle | mantle | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://explorer.mantle.xyz/address/0x2a98d978817949D45a5528013850772E762B7F12) | -| Moonbeam | moonbeam | aISLM | [0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5](https://moonscan.io/address/0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5) | -| Optimism | optimism | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://optimistic.etherscan.io/address0x2a98d978817949D45a5528013850772E762B7F12) | -| Scroll | scroll | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://scrollscan.com/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Network | ID | Token Symbol | Address | +|----------|------------|--------------|-------------------------------------------------------------------------------------------------------------------------------- | +| Ethereum | ethereum | aISLM | [0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5](https://etherscan.io/address/0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5) | +| Polygon | polygon | aISLM | [0x4E7A6031B7282431ff9cBC016dA2E7e50e0C54A4](https://polygonscan.com/address/0x4E7A6031B7282431ff9cBC016dA2E7e50e0C54A4) | +| Arbitrum | arbitrum | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://arbiscan.io/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Avalanche| avalanche | aISLM | [0xB5D8c52B65c24B020c51736D22F8bd961A281909](https://snowtrace.io/address/0xB5D8c52B65c24B020c51736D22F8bd961A281909) | +| Base | base | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://basescan.org/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| BNB Chain| binance | aISLM | [0xB208C4451bc3DE576a836406bD785951b939503E](https://bscscan.com/address/0xB208C4451bc3DE576a836406bD785951b939503E) | +| Blast | blast | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://blastscan.io/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Celo | celo | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://celoscan.io//address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Fantom | fantom | aISLM | [0xB208C4451bc3DE576a836406bD785951b939503E](https://ftmscan.com/address/0xB208C4451bc3DE576a836406bD785951b939503E) | +| Filecoin | filecoin | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://filfox.info/en/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Filecoin | filecoin | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://filfox.info/en/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Fraxtal | fraxtal | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://fraxscan.com/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Kava | kava | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://kavascan.com/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Linea | linea | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://lineascan.build/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Mantle | mantle | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://explorer.mantle.xyz/address/0x2a98d978817949D45a5528013850772E762B7F12) | +| Moonbeam | moonbeam | aISLM | [0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5](https://moonscan.io/address/0xF10c41cA085FC8d9326a65408D14Dae28A3E69a5) | +| Optimism | optimism | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://optimistic.etherscan.io/address0x2a98d978817949D45a5528013850772E762B7F12) | +| Scroll | scroll | aISLM | [0x2a98d978817949D45a5528013850772E762B7F12](https://scrollscan.com/address/0x2a98d978817949D45a5528013850772E762B7F12) | diff --git a/docs/develop/explores.md b/docs/develop/explores.md index cd4d1a9..7b69bbf 100644 --- a/docs/develop/explores.md +++ b/docs/develop/explores.md @@ -20,7 +20,7 @@ Below is a list of public block explorers that support Haqq Mainnet and Testnet: ### Mainnet | | Layer | URL | -| ---------- | -------- | ------------------------------------------------------- | +|------------|----------|---------------------------------------------------------| | Blockscout | `evm` | [explorer.haqq.network](https://explorer.haqq.network/) | | PingPub | `cosmos` | [ping.pub/haqq](https://ping.pub/haqq) | | NodesGuru | `cosmos` | [haqq.explorers.guru](https://haqq.explorers.guru/) | @@ -29,7 +29,7 @@ Below is a list of public block explorers that support Haqq Mainnet and Testnet: ### TestEdge-2 | | Layer | URL | -| ---------- | -------- | --------------------------------------------------------------------------- | +|------------|----------|-----------------------------------------------------------------------------| | Blockscout | `evm` | [explorer.testedge2.haqq.network](https://explorer.testedge2.haqq.network/) | | PingPub | `cosmos` | [testnet.ping.pub/haqq](https://testnet.ping.pub/haqq) | | Manticore | `cosmos` | [testnet.manticore.team](https://testnet.manticore.team/haqq) | diff --git a/docs/develop/haqqwallet.md b/docs/develop/haqqwallet.md index 4181d4c..a4c1584 100644 --- a/docs/develop/haqqwallet.md +++ b/docs/develop/haqqwallet.md @@ -3,13 +3,13 @@ sidebar_position: 12 title: Haqq Wallet --- -# Haqq Wallet - DApps developer's guide +# Haqq Wallet - DApps developer's guide -This page is dedicated to HAQQ Wallet functionality aimed at integrating external DApps, it will be of interest to all developers planning to interact with HAQQ Wallet. +This page is dedicated to HAQQ Wallet functionality aimed at integrating external DApps, it will be of interest to all developers planning to interact with HAQQ Wallet. ## Dynamic Link -Dynamic Link are designed to perform specific actions in an application, such as displaying a new banner on the main screen after clicking on a link. +Dynamic Link are designed to perform specific actions in an application, such as displaying a new banner on the main screen after clicking on a link. Dynamic Link allow you to transfer a user to an HAQQ Wallet with a target action if it is installed, and to install an HAQQ Wallet if it is not already installed on the user. If HAQQ Wallet has not been installed on the user, the target action will be performed after installation and creation (or restoration) of the wallet. :::info Wallet signature @@ -17,18 +17,17 @@ Please note that wallet signature of transactions on external sites on HAQQ Main To add your DApp to the WhiteList, please contact the HAQQ team. -The functionality to add DApp to WhiteList via onChain voting on HAQQ network will be implemented soon, stay tuned for updates. +The functionality to add DApp to WhiteList via onChain voting on HAQQ network will be implemented soon, stay tuned for updates. ::: Format: https://haqq.page.link/?link=ENCODED_LINK&apn=APN_ID&isi=ISI_ID&ibi=IBI_ID :::info Current HAQQ Wallet ID APN_ID - app package name for Android, ISI_ID - app ID in App Store for iOS, IBI_ID - app package name for iOS - -- APN_ID = **com.haqq.wallet** -- ISI_ID = **6443843352** -- IBI_ID = **com.haqq.wallet** - ::: +* APN_ID = **com.haqq.wallet** +* ISI_ID = **6443843352** +* IBI_ID = **com.haqq.wallet** +::: ENCODED_LINK is an encoded URL with the required query parameters (web3_browser, browser, distinct_id) that are processed within the application. @@ -38,28 +37,27 @@ The basic structure of Dynamic Link for Firebase in HAQQ Wallet application look ### ENCODED_LINK Current actions supported by HAQQ Wallet via Dynamic Link passed to ENCODED_LINK - -- browser - page opening in Web2 browser -- web3_browser - page opening in Web3 browser -- distinct_id - transfer of external client identifier: **for Analytics** -- :::info Applications - For most applications it is sufficient to use only **web3_browser** - ::: +* browser - page opening in Web2 browser +* web3_browser - page opening in Web3 browser +* distinct_id - transfer of external client identifier: **for Analytics** +* +:::info Applications +For most applications it is sufficient to use only **web3_browser** +::: ENCODED_LINK should use only escaped characters, you can get such a link with `encodeURIComponent`. -#### Format +#### Format `ENCODED_LINK = encodeURIComponent(https://haqq.network?{ACTION}=${PARAMETR})` -- ACTION - required action one of browser, web3_browser, distinct_id -- PARAMETR - passed parameter e.g. page/DApp link or ID +* ACTION - required action one of browser, web3_browser, distinct_id +* PARAMETR - passed parameter e.g. page/DApp link or ID example: - -- https://haqq.network?browser=siteLink -- https://haqq.network?web3_browser=dAppLink -- https://haqq.network?distinct_id=dID +* https://haqq.network?browser=siteLink +* https://haqq.network?web3_browser=dAppLink +* https://haqq.network?distinct_id=dID :::danger ENCODE Be sure to use encodeURIComponent or similar to escape special characters for Dynamic Link to work correctly @@ -70,7 +68,6 @@ After encode: `https%3A%2F%2Fhaqq.network%3Fbrowser%3DsiteLink` #### Code example JS code example - ```JS const siteLink = 'https://alpha.islm.ai'; const distinctId = '123456'; @@ -90,21 +87,18 @@ console.log('web3_browser', dynamicLinkForWeb3Browser); console.log('distinctId', dynamicLinkForDistinctId); ``` -Log example - +Log example ``` -[Log] browser +[Log] browser "https://haqq.page.link/?link=https%3A%2F%2Fhaqq.network%3Fbrowser%3Dhttps%3A%2F%2Falpha.islm.ai&apn=com.haqq.wallet&isi=6443843352&ibi=com.haqq.wallet" -[Log] web3_browser +[Log] web3_browser "https://haqq.page.link/?link=https%3A%2F%2Fhaqq.network%3Fweb3_browser%3Dhttps%3A%2F%2Falpha.islm.ai&apn=com.haqq.wallet&isi=6443843352&ibi=com.haqq.wallet" -[Log] distinctId -"https://haqq.page.link/?link=https%3A%2F%2Fhaqq.network%3Fdistinct_id%3D123456&apn=com.haqq.wallet&isi=6443843352&ibi=com.haqq.wallet" +[Log] distinctId +"https://haqq.page.link/?link=https%3A%2F%2Fhaqq.network%3Fdistinct_id%3D123456&apn=com.haqq.wallet&isi=6443843352&ibi=com.haqq.wallet" ``` -#### React example - +#### React example Create a hook - ```JS import {useMemo} from 'react'; @@ -120,7 +114,6 @@ export function useDeeplink(siteUrl = window.location.origin) { ``` Add into components - ```JS const deeplink = useDeepLink() @@ -131,4 +124,4 @@ const deeplink = useDeepLink() Open in HAQQ Wallet } -``` +``` \ No newline at end of file diff --git a/docs/develop/ibc.md b/docs/develop/ibc.md index 85e6125..33f19dd 100644 --- a/docs/develop/ibc.md +++ b/docs/develop/ibc.md @@ -11,50 +11,52 @@ You can read more about IBC - [here](/network/modules/ibc/) ## Mainnet - short form -| Network | Channel from HAQQ | Network | Channel to HAQQ | -| ------- | ----------------- | --------- | --------------- | -| HAQQ | channel-0 | GRAVITY | channel-100 | -| HAQQ | channel-1 | AXELAR | channel-113 | -| HAQQ | channel-2 | OSMOSIS | channel-1575 | -| HAQQ | channel-3 | COSMOSHUB | channel-632 | -| HAQQ | channel-4 | NOBLE | channel-32 | -| HAQQ | channel-6 | KAVA | channel-135 | +| Network | Channel from HAQQ | Network | Channel to HAQQ| +| --- | -------- | -------- | -------- | +| HAQQ | channel-0 | GRAVITY | channel-100 | +| HAQQ | channel-1 | AXELAR | channel-113 | +| HAQQ | channel-2 | OSMOSIS | channel-1575 | +| HAQQ | channel-3 | COSMOSHUB | channel-632 | +| HAQQ | channel-4 | NOBLE | channel-32 | +| HAQQ | channel-6 | KAVA | channel-135 | + ## Mainnet - FULL PATH -| From Network | To Network | FULL PATH | -| ------------ | ---------- | ------------------------------------------------------- | -| HAQQ | GRAVITY | 07-tendermint-0 - > connection-0 - > channel-0 | -| GRAVITY | HAQQ | 07-tendermint-192 - > connection-163 - > channel-100 | -| | | | -| HAQQ | AXELAR | 07-tendermint-1 - > connection-1 - > channel-1 | -| AXELAR | HAQQ | 07-tendermint-162 - > connection-148 - > channel-113 | -| | | | -| HAQQ | OSMOSIS | 07-tendermint-3 - > connection-2 - > channel-2 | -| OSMOSIS | HAQQ | 07-tendermint-2871 - > connection-2388 - > channel-1575 | -| | | | -| HAQQ | COSMOSHUB | 07-tendermint-2 - > connection-3 - > channel-3 | -| COSMOSHUB | HAQQ | 07-tendermint-1153 - > connection-874 - > channel-632 | -| | | | -| HAQQ | NOBLE | 07-tendermint-4 - > connection-4 - > channel-4 | -| NOBLE | HAQQ | 07-tendermint-58 - > connection-56 - > channel-32 | -| | | | -| HAQQ | KAVA | 07-tendermint-5 - > connection-7 - > channel-6 | -| KAVA | HAQQ | 07-tendermint-149 - > connection-193 - > channel-135 | +| From Network | To Network | FULL PATH | +| --- | --- | -------- | +| HAQQ | GRAVITY | 07-tendermint-0 - > connection-0 - > channel-0 | +| GRAVITY | HAQQ | 07-tendermint-192 - > connection-163 - > channel-100 | +| | | | +| HAQQ | AXELAR | 07-tendermint-1 - > connection-1 - > channel-1 | +| AXELAR | HAQQ | 07-tendermint-162 - > connection-148 - > channel-113 | +| | | | +| HAQQ | OSMOSIS | 07-tendermint-3 - > connection-2 - > channel-2 +| OSMOSIS | HAQQ | 07-tendermint-2871 - > connection-2388 - > channel-1575 | +| | | | +| HAQQ | COSMOSHUB | 07-tendermint-2 - > connection-3 - > channel-3 | +| COSMOSHUB | HAQQ | 07-tendermint-1153 - > connection-874 - > channel-632 | +| | | | +| HAQQ | NOBLE | 07-tendermint-4 - > connection-4 - > channel-4 | +| NOBLE | HAQQ | 07-tendermint-58 - > connection-56 - > channel-32 | +| | | | +| HAQQ | KAVA | 07-tendermint-5 - > connection-7 - > channel-6 | +| KAVA | HAQQ | 07-tendermint-149 - > connection-193 - > channel-135 | ## TestEdge2 - short form -| Network | Channel from HAQQ | Network | Channel to HAQQ | -| -------------- | ----------------- | --------------------- | --------------- | -| HAQQ TestEdge2 | channel-4 | AXELAR TESTNET LISBON | channel-304 | -| HAQQ TestEdge2 | channel-0 | GRAVITY | channel-94 | +| Network | Channel from HAQQ | Network | Channel to HAQQ| +| --- | -------- | -------- | -------- | +| HAQQ TestEdge2 | channel-4 | AXELAR TESTNET LISBON | channel-304 | +| HAQQ TestEdge2 | channel-0 | GRAVITY | channel-94 | + ## TestEdge2 - FULL PATH -| From Network | To Network | FULL PATH | -| --------------------- | --------------------- | ---------------------------------------------------- | -| HAQQ TestEdge2 | GRAVITY | 07-tendermint-1 - > connection-0 - > channel-0 | -| GRAVITY | HAQQ TestEdge2 | 07-tendermint-181 - > connection-156 - > channel-94 | -| | | | -| HAQQ TestEdge2 | AXELAR TESTNET LISBON | 07-tendermint-13 - > connection-13 - > channel-4 | -| AXELAR TESTNET LISBON | HAQQ TestEdge2 | 07-tendermint-602 - > connection-602 - > channel-304 | +| From Network | To Network | FULL PATH | +| ------------ | ----------- | --------- | +| HAQQ TestEdge2 | GRAVITY | 07-tendermint-1 - > connection-0 - > channel-0 | +| GRAVITY | HAQQ TestEdge2 | 07-tendermint-181 - > connection-156 - > channel-94 | +| | | | +| HAQQ TestEdge2 | AXELAR TESTNET LISBON | 07-tendermint-13 - > connection-13 - > channel-4 | +| AXELAR TESTNET LISBON | HAQQ TestEdge2 | 07-tendermint-602 - > connection-602 - > channel-304 | diff --git a/docs/develop/index.mdx b/docs/develop/index.mdx index 5e466db..33e5384 100644 --- a/docs/develop/index.mdx +++ b/docs/develop/index.mdx @@ -2,10 +2,11 @@ sidebar_position: 0 --- -# Overview +# Overview -This section of the documentation provides a comprehensive guide to start developing dApp, Smart Contracs, on a HAAQ network. +This section of the documentation provides a comprehensive guide to start developing dApp, Smart Contracs, on a HAAQ network. It covers fundamental concepts such as the architecture of blockchain, smart contracts, consensus mechanisms, and the role of nodes in the network. -The guide offers step-by-step instructions on setting up a blockchain development environment, writing and deploying smart contracts, and integrating blockchain applications with existing systems. +The guide offers step-by-step instructions on setting up a blockchain development environment, writing and deploying smart contracts, and integrating blockchain applications with existing systems. -Useful code examples, best practices, and troubleshooting tips are included to assist developers in creating robust and efficient blockchain-based applications. + +Useful code examples, best practices, and troubleshooting tips are included to assist developers in creating robust and efficient blockchain-based applications. \ No newline at end of file diff --git a/docs/develop/whitelisttoken.md b/docs/develop/whitelisttoken.md index a911c9c..0389d0c 100644 --- a/docs/develop/whitelisttoken.md +++ b/docs/develop/whitelisttoken.md @@ -5,27 +5,26 @@ title: White List Tokens # White List Tokens -As long as the sharia oracle mechanism is not running on the network, on the network - HAQQ Wallet has a WhiteList of ERC20 tokens already added to our network via IBC. +As long as the sharia oracle mechanism is not running on the network, on the network - HAQQ Wallet has a WhiteList of ERC20 tokens already added to our network via IBC. ## Mainnet -| Name | Address | Type | CoinGecoID | -| ------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------- | ----------------------- | -| axlUSDC | [0x80b5a32E4F032B2a058b4F29EC95EEfEEB87aDcd](https://explorer.haqq.network/token/0x80b5a32E4F032B2a058b4F29EC95EEfEEB87aDcd) | IBC/ERC20 Token | bridged-usd-coin-axelar | -| axlUSDT | [0xd567B3d7B8FE3C79a1AD8dA978812cfC4Fa05e75](https://explorer.haqq.network/token/0xd567B3d7B8FE3C79a1AD8dA978812cfC4Fa05e75) | IBC/ERC20 Token | bridged-tether-axelar | -| AXL | [0x1D54EcB8583Ca25895c512A8308389fFD581F9c9](https://explorer.haqq.network/token/0x1D54EcB8583Ca25895c512A8308389fFD581F9c9) | IBC/ERC20 Token | axelar | -| OSMO | [0xc03345448969Dd8C00e9E4A85d2d9722d093aF8E](https://explorer.haqq.network/token/0xc03345448969Dd8C00e9E4A85d2d9722d093aF8E) | IBC/ERC20 Token | osmosis | -| ATOM | [0xFA3C22C069B9556A4B2f7EcE1Ee3B467909f4864](https://explorer.haqq.network/token/0xFA3C22C069B9556A4B2f7EcE1Ee3B467909f4864) | IBC/ERC20 Token | cosmos-hub | -| axlWBTC | [0x5FD55A1B9FC24967C4dB09C513C3BA0DFa7FF687](https://explorer.haqq.network/token/0x5FD55A1B9FC24967C4dB09C513C3BA0DFa7FF687) | IBC/ERC20 Token | axlwbtc | -| axlWETH | [0xecEEEfCEE421D8062EF8d6b4D814efe4dc898265](https://explorer.haqq.network/token/0xecEEEfCEE421D8062EF8d6b4D814efe4dc898265) | IBC/ERC20 Token | axelar-wrapped-ether | -| axlDAI | [0xC5e00D3b04563950941f7137B5AfA3a534F0D6d6](https://explorer.haqq.network/token/0xC5e00D3b04563950941f7137B5AfA3a534F0D6d6) | IBC/ERC20 Token | dai | -| USDC | [0x0CE35b0D42608Ca54Eb7bcc8044f7087C18E7717](https://explorer.haqq.network/token/0x0CE35b0D42608Ca54Eb7bcc8044f7087C18E7717) | IBC/ERC20 Token | usdc | -| USDT | [0x5aD523d94Efb56C400941eb6F34393b84c75ba39](https://explorer.haqq.network/token/0x5aD523d94Efb56C400941eb6F34393b84c75ba39) | IBC/ERC20 Token | tether | -| stISLM | [0x12fEFEAc0568503F7C0D934c149f29a42B05C48f](https://explorer.haqq.network/token/0x12fEFEAc0568503F7C0D934c149f29a42B05C48f) | IBC/ERC20 Token | stride-staked-islm | -| DEEN | [0x4FEBDDe47Ab9a76200e57eFcC80b212a07b3e6cE](https://explorer.haqq.network/token/0x4FEBDDe47Ab9a76200e57eFcC80b212a07b3e6cE) | IBC/ERC20 Token | | +| Name | Address | Type | CoinGecoID | +| ------- | ------------------------------------------ | ---------------- | ----------------------- | +| axlUSDC | [0x80b5a32E4F032B2a058b4F29EC95EEfEEB87aDcd](https://explorer.haqq.network/token/0x80b5a32E4F032B2a058b4F29EC95EEfEEB87aDcd) | IBC/ERC20 Token | bridged-usd-coin-axelar | +| axlUSDT | [0xd567B3d7B8FE3C79a1AD8dA978812cfC4Fa05e75](https://explorer.haqq.network/token/0xd567B3d7B8FE3C79a1AD8dA978812cfC4Fa05e75) | IBC/ERC20 Token | bridged-tether-axelar | +| AXL | [0x1D54EcB8583Ca25895c512A8308389fFD581F9c9](https://explorer.haqq.network/token/0x1D54EcB8583Ca25895c512A8308389fFD581F9c9) | IBC/ERC20 Token | axelar | +| OSMO | [0xc03345448969Dd8C00e9E4A85d2d9722d093aF8E](https://explorer.haqq.network/token/0xc03345448969Dd8C00e9E4A85d2d9722d093aF8E) | IBC/ERC20 Token | osmosis | +| ATOM | [0xFA3C22C069B9556A4B2f7EcE1Ee3B467909f4864](https://explorer.haqq.network/token/0xFA3C22C069B9556A4B2f7EcE1Ee3B467909f4864) | IBC/ERC20 Token | cosmos-hub | +| axlWBTC | [0x5FD55A1B9FC24967C4dB09C513C3BA0DFa7FF687](https://explorer.haqq.network/token/0x5FD55A1B9FC24967C4dB09C513C3BA0DFa7FF687) | IBC/ERC20 Token | axlwbtc | +| axlWETH | [0xecEEEfCEE421D8062EF8d6b4D814efe4dc898265](https://explorer.haqq.network/token/0xecEEEfCEE421D8062EF8d6b4D814efe4dc898265) | IBC/ERC20 Token | axelar-wrapped-ether | +| axlDAI | [0xC5e00D3b04563950941f7137B5AfA3a534F0D6d6](https://explorer.haqq.network/token/0xC5e00D3b04563950941f7137B5AfA3a534F0D6d6) | IBC/ERC20 Token | dai | +| USDC | [0x0CE35b0D42608Ca54Eb7bcc8044f7087C18E7717](https://explorer.haqq.network/token/0x0CE35b0D42608Ca54Eb7bcc8044f7087C18E7717) | IBC/ERC20 Token | usdc | +| USDT | [0x5aD523d94Efb56C400941eb6F34393b84c75ba39](https://explorer.haqq.network/token/0x5aD523d94Efb56C400941eb6F34393b84c75ba39) | IBC/ERC20 Token | tether | +| stISLM | [0x12fEFEAc0568503F7C0D934c149f29a42B05C48f](https://explorer.haqq.network/token/0x12fEFEAc0568503F7C0D934c149f29a42B05C48f) | IBC/ERC20 Token | stride-staked-islm | +| DEEN | [0x4FEBDDe47Ab9a76200e57eFcC80b212a07b3e6cE](https://explorer.haqq.network/token/0x4FEBDDe47Ab9a76200e57eFcC80b212a07b3e6cE) | IBC/ERC20 Token | | -## Wrap - -| Name | Address | Type | CoinGecoID | -| ----- | ---------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------ | -| wISLM | [0xec8cc083787c6e5218d86f9ff5f28d4cc377ac54](https://explorer.haqq.network/token/0xec8cc083787c6e5218d86f9ff5f28d4cc377ac54) | ERC20 Token | islamic-coin | +## Wrap +| Name | Address | Type | CoinGecoID | +| ------- | ------------------------------------------ | ---------------- | ----------------------- | +| wISLM | [0xec8cc083787c6e5218d86f9ff5f28d4cc377ac54](https://explorer.haqq.network/token/0xec8cc083787c6e5218d86f9ff5f28d4cc377ac54) | ERC20 Token | islamic-coin | \ No newline at end of file diff --git a/docs/learn/_getting-started.mdx b/docs/learn/_getting-started.mdx index 0687bbb..e655fff 100644 --- a/docs/learn/_getting-started.mdx +++ b/docs/learn/_getting-started.mdx @@ -4,4 +4,4 @@ sidebar_position: 3 # Getting started -Coming soon... +Coming soon... \ No newline at end of file diff --git a/docs/learn/ecosystem/evergreen.md b/docs/learn/ecosystem/evergreen.md index e59aeb3..f762904 100644 --- a/docs/learn/ecosystem/evergreen.md +++ b/docs/learn/ecosystem/evergreen.md @@ -5,7 +5,7 @@ sidebar_position: 3 # Evergreen DAO Evergreen DAO is introduced to fund projects benefiting the global Muslim community, grants to ecosystem maintainers, -bug bounties, marketing activities and other initiatives which the community decides are helpful +bug bounties, marketing activities and other initiatives which the community decides are helpful for the Haqq Network and/or the Muslim community. :::tip @@ -20,9 +20,9 @@ Evergreen DAO governance is similar to a default Cosmos Governance with three di 1. The Haqq Shariah Board can approves every spending proposal 2. Users are financially incentivized to submit high-quality proposals which benefit - the Muslim Community +the Muslim Community 3. Deposits never burn – they get transferred to the Evergreen DAO in the event of - Voting Period or Deposit Period failure. +Voting Period or Deposit Period failure. ### Evergreen DAO will be based on the Cosmos Community Pool @@ -34,7 +34,7 @@ of the following periods: 3. Shariah Approval Period If and when the proposal has passed the Voting Period, the proposal enters the Shariah Approval Period. -During this period Haqq Association Shariah Board reviews a proposal and decides if it complies with Shariah Law. +During this period Haqq Association Shariah Board reviews a proposal and decides if it complies with Shariah Law. If the Shariah Board approves a proposal, it gets executed and coins are transferred to the destination defined in a proposal. If the Shariah Board rejects the proposal, coins stay in Evergreen DAO. If the Shariah Board doesn’t submit a decision in 21 days, a proposal gets automatically rejected, coins stay in Evergreen DAO. @@ -44,10 +44,13 @@ If the Shariah Board doesn’t submit a decision in 21 days, a proposal gets aut When a proposal finalized, the coins from the deposit are either refunded or go to Evergreen DAO (on the contrary to the default cosmos governance where coins are burned), according to the final tally of the proposal: -- If the proposal is approved or if it's rejected but not vetoed during Voting Period, deposit will automatically +- If the proposal is approved or if it's rejected but not vetoed during Voting Period, deposit will automatically be refunded to their respective depositor (transferred from the governance ModuleAccount) regardless of the Shariah Approval Period outcome. -- If the proposal is vetoed by a supermajority during the Voting Period, deposit is transferred +- If the proposal is vetoed by a supermajority during the Voting Period, deposit is transferred to the Evergreen DAO (Community Pool Module). - If the proposal closes during the Deposit Period (didn’t reach MinDeposit during MaxDepositPeriod), deposit is transferred to the Evergreen DAO + + + diff --git a/docs/learn/ecosystem/index.mdx b/docs/learn/ecosystem/index.mdx index ce69c30..50bc6d2 100644 --- a/docs/learn/ecosystem/index.mdx +++ b/docs/learn/ecosystem/index.mdx @@ -15,71 +15,71 @@ of decentralized finance. This integration has opened up a plethora of applicati ensuring that all transactions and applications are in compliance with Sharia law.
-
-
- - } - /> - +
+
+ + } + /> + +
+
+ + } + /> + +
-
- - } - /> - +
+
+ + } + /> + +
+
+ + } + /> + +
+
+ + } + /> + +
-
-
-
- - } - /> - -
-
- - } - /> - -
-
- - } - /> - -
-
- Learn more about HAQQ [ecosystem partners](https://haqq.network/ecosystem) diff --git a/docs/learn/ecosystem/shariah.md b/docs/learn/ecosystem/shariah.md index 3efe9eb..1f39010 100644 --- a/docs/learn/ecosystem/shariah.md +++ b/docs/learn/ecosystem/shariah.md @@ -5,20 +5,20 @@ sidebar_position: 4 # Shariah Oracle: A Unique Vetting Mechanism -In the dynamic and evolving ecosystem of the HAQQ Network, all future developments and additions are subject +In the dynamic and evolving ecosystem of the HAQQ Network, all future developments and additions are subject to the approval of the Shariah Board, using a unique vetting mechanism called the Shariah Oracle. This ensures that any changes or additions to the HAQQ Network align with Shariah law, maintaining the network's integrity under Islamic law and fostering trust and reassurance for its users. ## Transparency in dApp Integrations -Moreover, the HAQQ Network maintains complete transparency about the status of various dApp integrations within its ecosystem. -Users can find a comprehensive list of integration statuses on the official HAQQ Network webpage, +Moreover, the HAQQ Network maintains complete transparency about the status of various dApp integrations within its ecosystem. +Users can find a comprehensive list of integration statuses on the official HAQQ Network webpage, located at https://haqq.network/ecosystem. This feature underscores the network's commitment to openness and transparency, keeping users informed about ongoing developments and improvements and enabling them to make informed decisions. ## Conclusion -The incorporation of blockchain technology with Shariah law is a promising step towards creating more inclusive -and diverse blockchain environments. This approach not only serves the global Muslim community but also appeals +The incorporation of blockchain technology with Shariah law is a promising step towards creating more inclusive +and diverse blockchain environments. This approach not only serves the global Muslim community but also appeals to others who appreciate ethical and sustainable financial practices. diff --git a/docs/learn/ecosystem/vesting.md b/docs/learn/ecosystem/vesting.md index d2bad26..98af5da 100644 --- a/docs/learn/ecosystem/vesting.md +++ b/docs/learn/ecosystem/vesting.md @@ -4,16 +4,15 @@ sidebar_position: 5 --- # Vesting: The vesting dApp - [Go to the vesting dApp](https://vesting.haqq.network/) ![vesting.png](/img/vesting.png) Vesting DApp allows users to manage vesting and view their wallet details, including: -- **Total Balance**: The complete overall balance of your wallet. -- **Available Balance**: The amount that is free to use for spending and transfers. -- **Locked Balance**: The total of coins locked in vesting and staking. +* **Total Balance**: The complete overall balance of your wallet. +* **Available Balance**: The amount that is free to use for spending and transfers. +* **Locked Balance**: The total of coins locked in vesting and staking. ## Schedule functionality @@ -21,7 +20,7 @@ Vesting DApp allows users to manage vesting and view their wallet details, inclu If you have ongoing vesting schedules, the site displays the full vesting timeline, details about the next release period, and how many periods remain. -## Liquid vesting functionality +## Liquid vesting functionality ![liquidity.png](/img/liquidity.png) diff --git a/docs/learn/ecosystem/wallet.mdx b/docs/learn/ecosystem/wallet.mdx index 638b9a2..699b2f7 100644 --- a/docs/learn/ecosystem/wallet.mdx +++ b/docs/learn/ecosystem/wallet.mdx @@ -5,64 +5,50 @@ sidebar_position: 1 # HAQQ Wallet Enter the world of HAQQ Wallet, a digital wallet specifically designed for the global Muslim population -of 1.8 billion and ethical finance enthusiasts. It's tailor-made to handle Islamic Coin ($ISLM) +of 1.8 billion and ethical finance enthusiasts. It's tailor-made to handle Islamic Coin ($ISLM) in a Shariah-compliant manner. Join us to experience the fusion of traditional finance and blockchain technology, all while upholding Islamic values. ## Creating a Secure Wallet Has Never Been Easier HAQQ Wallet offers the perfect blend of web2 UX and web3 security, making it incredibly simple to create a secure wallet -for your Islamic Coin. With HAQQ Wallet, you own your private keys, giving you complete control over your +for your Islamic Coin. With HAQQ Wallet, you own your private keys, giving you complete control over your assets and ensuring absolute security. ## Storing, Sending, and Receiving Made Simple -HAQQ Wallet enables you to effortlessly manage your digital assets. Whether you're storing, sending, +HAQQ Wallet enables you to effortlessly manage your digital assets. Whether you're storing, sending, or receiving Islamic Coin within the HAQQ network, our intuitive user interface ensures a seamless experience. ## Embrace the Future with Staking and DeFi -With HAQQ Wallet, you can stake your Islamic Coin and earn rewards, contributing to the network's growth -and sustainability. As a part of the HAQQ ecosystem, you'll have the opportunity to explore DeFi, +With HAQQ Wallet, you can stake your Islamic Coin and earn rewards, contributing to the network's growth +and sustainability. As a part of the HAQQ ecosystem, you'll have the opportunity to explore DeFi, earn passive income, and participate in exclusive raffles and giveaways. ## Seamless Trading and Transacting -HAQQ Wallet empowers you to conduct secure transactions within the HAQQ Network. It allows you access -to decentralized exchanges, enabling seamless transactions between ecosystems. At HAQQ Wallet, +HAQQ Wallet empowers you to conduct secure transactions within the HAQQ Network. It allows you access +to decentralized exchanges, enabling seamless transactions between ecosystems. At HAQQ Wallet, the security and protection of your assets are our top priority. ## Stay Informed and Ahead -HAQQ Wallet keeps you informed about the latest news, updates, and developments within the HAQQ Network. +HAQQ Wallet keeps you informed about the latest news, updates, and developments within the HAQQ Network. Stay ahead of the curve and make informed decisions in the ever-evolving crypto landscape. ## Download Now and Experience the Future of Finance -Download HAQQ Wallet now and unlock the full potential of the HAQQ Network. -Step into the future of finance that prioritizes security, convenience, and Shariah-compliant innovation. +Download HAQQ Wallet now and unlock the full potential of the HAQQ Network. +Step into the future of finance that prioritizes security, convenience, and Shariah-compliant innovation. Join a community of Muslim crypto enthusiasts and be part of the change. Experience the future of finance with HAQQ Wallet today. diff --git a/docs/learn/faq.md b/docs/learn/faq.md index 822acf0..de5c10a 100644 --- a/docs/learn/faq.md +++ b/docs/learn/faq.md @@ -10,7 +10,7 @@ sidebar_position: 7 Which wallet would you recommend for HAQQ? We recommend using the HAQQ Wallet for your HAQQ Network transactions. -It`s a mobile wallet specifically designed to work seamlessly with the HAQQ Network, enhancing your experience and ensuring secure transactions. +It`s a mobile wallet specifically designed to work seamlessly with the HAQQ Network, enhancing your experience and ensuring secure transactions. You can download the HAQQ Wallet from our official website: [HAQQ Wallet](https://haqq.network/wallet/) @@ -39,6 +39,7 @@ the receiving chain support EVM (i.e. Ethermint-based chains). + ## EVM compatibility.
@@ -47,14 +48,12 @@ the receiving chain support EVM (i.e. Ethermint-based chains). HAQQ Network is fully compatible with the EVM version Paris. (Solidity 8.19). Unfortunately, now we do not support the functionality of the account is abstract. (EIP-4337). -
Can i deploy the contract written in solidity directly in the chain？ **Yes, you can** - HAQQ Network is fully compatible with the EVM version Paris. (Solidity 8.19). -
@@ -68,19 +67,16 @@ HAQQ HD path is **m/44'/60'/0'/0.** HAQQ Netowrk use Coin type 60 to support Eth What is the block size? Each block on HAQQ Network has a maxium block size is **40.000.000 GAS** -
What is the block time? On HAQQ Network the block time is within **5.6 - 6.2 seconds.** -
What is Time to Finality (TTF)? -HAQQ has instant Time to Finality (TTF) ** -6 sec, 1 block.** Because as a consensus mechanism HAQQ is CometBFT (formerly Tendermint). - +HAQQ has instant Time to Finality (TTF) ** -6 sec, 1 block.** Because as a consensus mechanism HAQQ is CometBFT (formerly Tendermint).
diff --git a/docs/learn/glossary.mdx b/docs/learn/glossary.mdx index 4d90b9e..2fb8a28 100644 --- a/docs/learn/glossary.mdx +++ b/docs/learn/glossary.mdx @@ -86,7 +86,7 @@ A user who delegates, bonds, or stakes ISLM to a validator to earn rewards. ## Fees - Gas: Computed fees added on to all transactions to avoid spamming. Validators set minimum gas prices and reject transactions - that have implied gas prices below this threshold. +that have implied gas prices below this threshold. ## Full node diff --git a/docs/learn/index.mdx b/docs/learn/index.mdx index c4b9e66..cd2da0c 100644 --- a/docs/learn/index.mdx +++ b/docs/learn/index.mdx @@ -45,5 +45,5 @@ software to seamlessly deploy smart contracts which interact with the rest of th | ------------------ | -------------------------------------------------- | | HAQQ Mainnet ID | | | HAQQ TestEdge-2 ID | | -| Block Explorers | [Block Explorers](../develop/explores/) | +| Block Explorers | [Block Explorers](../develop/explores/) | | Block Time | ~6 seconds | diff --git a/docs/network/configuration/disk-optimization.md b/docs/network/configuration/disk-optimization.md index 5112ba0..f000a83 100644 --- a/docs/network/configuration/disk-optimization.md +++ b/docs/network/configuration/disk-optimization.md @@ -16,10 +16,9 @@ disk usage quite significantly. Some of these changes take full effect only when you do the configuration and start syncing from start with them in use. -## Storage Configuration Options +## Storage Configuration Options Set to true to discard ABCI responses from the state store, which can save a considerable amount of disk space. On `config.toml` setß - ```toml [storage] discard_abci_responses = true @@ -38,6 +37,7 @@ If you do this on already synced node, the collected index is not purged automatically, you need to delete it manually. The index is located under the database directory with name `data/tx_index.db/`. + ## Consensus Configuration Options ```toml @@ -63,7 +63,6 @@ would not have the history. By default every 500th state, and the last zero states are kept. This consumes a lot of disk space on long run, and can be optimized with following custom configuration in `app.toml`: - ```toml pruning = "everything" @@ -72,8 +71,8 @@ pruning-interval = "0" min-retain-blocks = 400000 ``` -## API +## API To reduce the load, we recommend disabling all APIs in in `app.toml`: ```toml diff --git a/docs/network/configuration/kms.md b/docs/network/configuration/kms.md index 0440b16..a34abea 100644 --- a/docs/network/configuration/kms.md +++ b/docs/network/configuration/kms.md @@ -29,7 +29,6 @@ source $HOME/.cargo/env ``` ### GCC - #### Ubuntu ```sh diff --git a/docs/network/configuration/restake.md b/docs/network/configuration/restake.md index 1705625..d2cebbb 100644 --- a/docs/network/configuration/restake.md +++ b/docs/network/configuration/restake.md @@ -4,67 +4,65 @@ sidebar_position: 8 # ReStake Config -:::note +:::note Learn about ReStake on [restake.app](https://restake.app) and [github](https://github.com/eco-stake/restake) ::: ## About REStake > REStake allows delegators to grant permission for a validator to compound their rewards, and provides a script validators can run to find their granted delegators and send the compounding transactions automatically. -> +> > REStake is also a convenient staking tool, allowing you to claim and compound your rewards individually or in bulk. This can save transaction fees and time, and many more features are planned. REStake allows users to automatically stack rewards received on stacking back to the validator - this allows users to invest in stacking as an asset with compound interest, and validators not only increase their attractiveness in the eyes of the user, but also to increase the number of stacked tokens on a regular basis ## Setup local - -:::info +:::info We recommend running ReStake on a separate machine not associated with the validator. ::: -### 1. Download the repository, and prepare environment variables. + + +### 1. Download the repository, and prepare environment variables. ```bash git clone https://github.com/eco-stake/restake -cd restake +cd restake cp .env.sample .env nano .env ``` -:::warning +:::warning Categorically **DO NOT** use the validator mnemonic for the ReStake operator ::: -:::info +:::info We recommend creating a new mnemonic, and transferring a small balance in ISLM to it ::: -In environment variables - instert your mnemonic - MNEMONIC=my hot wallet seed words here that has minimal funds +In environment variables - instert your mnemonic - MNEMONIC=my hot wallet seed words here that has minimal funds -Since the HAQQ network is still in experimental mode at the moment - you need to write your config, and specify the path to it in your environment variables. +Since the HAQQ network is still in experimental mode at the moment - you need to write your config, and specify the path to it in your environment variables. NETWORKS_OVERRIDE_PATH=src/networks.local.json -An example of the contents of the .env file. +An example of the contents of the .env file. ```environment MNEMONIC=my hot wallet seed words here that has minimal funds NETWORKS_OVERRIDE_PATH=src/networks.local.json ``` -### 2. Add HAQQ Config +### 2. Add HAQQ Config Open/Create networks.local.json - ```bash cd src nano networks.local.json ``` Write your config: - -- ownerAddress - address your validator in haqqvaloper..... format. -- healthCheck - your id from [healthchecks](https://healthchecks.io) -- restUrl - haqq node rest url. - +* ownerAddress - address your validator in haqqvaloper..... format. +* healthCheck - your id from [healthchecks](https://healthchecks.io) +* restUrl - haqq node rest url. ``` { "haqq": { @@ -82,7 +80,7 @@ Write your config: } ``` -### 3. Create container +### 3. Create container ```bash git pull @@ -97,15 +95,13 @@ crontab -e ``` Add new cron task - ``` 0 */1 * * * /bin/bash -c "cd /...yourpath.../restake && docker compose run --rm app npm run autostake haqq" > ./restake.log 2>&1 ``` ## Add your validator to ReStake App -### 1. Create your fork - +### 1. Create your fork FORK - https://github.com/eco-stake/validator-registry ### 2. Add your validator @@ -154,7 +150,6 @@ nano profile.json ``` ### 5. Create your services.json - ```bash nano services.json ``` @@ -171,4 +166,4 @@ nano services.json } ] } -``` +``` \ No newline at end of file diff --git a/docs/network/configuration/security-checklist.md b/docs/network/configuration/security-checklist.md index 86d0cc6..86d3eb5 100644 --- a/docs/network/configuration/security-checklist.md +++ b/docs/network/configuration/security-checklist.md @@ -9,7 +9,7 @@ sidebar_position: 4 ## Pre-requisite Readings -- [Validator Security](security.md) +- [Validator Security](security.md) ## Conduct Survey on General Controls of Hosting Data Centre @@ -18,7 +18,7 @@ Perform a survey on the hosting data centre, and compare your result with the be For example, your hosting data centre should have following features | Controls Category | Description of Best Practice | -| ----------------- | ------------------------------- | +|-------------------|---------------------------------| | Data Center | Redundant Power | | Data Center | Redundant Cooling | | Data Center | Redundant Networking | @@ -30,7 +30,7 @@ For example, your hosting data centre should have following features Perform a survey on your current status of node setup, and compare your result with the best practice suggested below | Controls Category | Description of Best Practice | -| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +|----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | General System Security | Operating system appropriately patched. Kernel is updated to latest stable version. The node should be operated in x86_64 environment | | General System Security | Auto-updates for operation system is configured. Toolkit for automatic upgrades exists (e.g. auter, yum-cron, dnf-automatic, unattended-upgrades) | | General System Security | Security framework enabled and enforcing. SELinux / AppArmor / Tomoyo / Grsecurity Enabled | diff --git a/docs/network/index.mdx b/docs/network/index.mdx index b3b56f0..be60cda 100644 --- a/docs/network/index.mdx +++ b/docs/network/index.mdx @@ -60,3 +60,5 @@ while ensuring the same developer experience as Ethereum: - Ethereum's `secp256k1` curve for the Cosmos Keyring - `StateDB` interface for state updates and queries - [JSON-RPC](../develop/api/ethereum-json-rpc) client for interacting with the EVM + + diff --git a/docs/network/module-accounts.md b/docs/network/module-accounts.md index 190d249..28c363a 100644 --- a/docs/network/module-accounts.md +++ b/docs/network/module-accounts.md @@ -4,13 +4,13 @@ sidebar_position: 3 # Module Accounts -Some modules have their own module account. Think of this as a wallet that can only be controlled by that module. +Some modules have their own module account. Think of this as a wallet that can only be controlled by that module. Below is a table of modules, their respective wallet addresses and permissions: ## List of Module Accounts | Name | Address | Permissions | -| :----------------------- | :----------------------------------------------------------------------------------------------------------------------- | :----------------- | +|:-------------------------|:-------------------------------------------------------------------------------------------------------------------------|:-------------------| | `coinomics` | [haqq13lmzrazlsjzca7ugqtpwe6xyy3553ghlh5hupc](https://ping.pub/haqq/account/haqq13lmzrazlsjzca7ugqtpwe6xyy3553ghlh5hupc) | `minter` | | `distribution` | [haqq1jv65s3grqf6v6jl3dp4t6c9t9rk99cd89c30hf](https://ping.pub/haqq/account/haqq1jv65s3grqf6v6jl3dp4t6c9t9rk99cd89c30hf) | `none` | | `erc20` | [haqq1glht96kr2rseywuvhhay894qw7ekuc4qgrxfhs](https://ping.pub/haqq/account/haqq1glht96kr2rseywuvhhay894qw7ekuc4qgrxfhs) | `minter` `burner` | @@ -22,8 +22,9 @@ Below is a table of modules, their respective wallet addresses and permissions: | `transfer` | [haqq1yl6hdjhmkf37639730gffanpzndzdpmhvcr6f4](https://ping.pub/haqq/account/haqq1yl6hdjhmkf37639730gffanpzndzdpmhvcr6f4) | `minter` `burner` | | `liquidvesting` | [haqq102lq49sg6lmw2e0mw740tjldzq68v0yfylw05s](https://ping.pub/haqq/account/haqq102lq49sg6lmw2e0mw740tjldzq68v0yfylw05s) | `minter` `burner` | + ## Account Permissions -- The `burner` permission means this account has the permission to burn or destroy tokens. -- The `minter` permission means this account has permission to mint or create new tokens. -- The `staking` permission means this account has permission to stake tokens on behalf of its owner. +* The `burner` permission means this account has the permission to burn or destroy tokens. +* The `minter` permission means this account has permission to mint or create new tokens. +* The `staking` permission means this account has permission to stake tokens on behalf of its owner. \ No newline at end of file diff --git a/docs/network/modules/bank.md b/docs/network/modules/bank.md index 95ef395..0e9fe6e 100644 --- a/docs/network/modules/bank.md +++ b/docs/network/modules/bank.md @@ -5,6 +5,7 @@ title: x/bank # Bank + ## Abstract This document specifies the internal `x/bank` module of the HAQQ Network. @@ -19,9 +20,9 @@ Initially, this wrapper was made to comply with the tokenomics requirements desc [Whitepaper](https://islamiccoin.net/whitepaper). HAQQ bank keeper has a custom coins `burn` policy, that funds Evergreen DAO account instead of complete coins destruction in certain cases. -The latest improvements of HAQQ bank make it an EVM-first module. It supports a trustless, on-chain bidirectional +The latest improvements of HAQQ bank make it an EVM-first module. It supports a trustless, on-chain bidirectional internal conversion of tokens between HAQQ EVM and Cosmos runtimes. Bank utilizes the `x/erc20` features -to instantaneously convert users' native Cosmos `sdk.Coins` (in this document referred to as "Coin(s)") +to instantaneously convert users' native Cosmos `sdk.Coins` (in this document referred to as "Coin(s)") to ERC-20 (aka "Token(s)") during the transfers. That allows users' to see the same information about balances and make transfers without additional conversions using the preferred wallet apps (e.g. Keplr, MetaMask, etc). @@ -37,7 +38,7 @@ bank/ ├── keeper │ ├── grpc_query.go # gRPC state query handlers │ ├── keeper.go # Store keeper with the custom Burn() function -│ └── msg_server.go # Tx handlers (overrides functions Send, GetBalance, etc.) +│ └── msg_server.go # Tx handlers (overrides functions Send, GetBalance, etc.) │ └── querier.go # Legacy state query handlers │ └── wrapped_keeper.go # Store keeper wrapper └── module.go # Module setup for the module manager & ABCI InitGenesis and ExportGenesis functionality @@ -49,7 +50,7 @@ bank/ Once a token pair proposal passes, users of native Cosmos wallets (e.g., Keplr) can see their accurate Tokens balance as if they were native Coins. -Holders of native Cosmos coins and IBC vouchers on the HAQQ Network can transfer their Tokens on HAQQ EVM +Holders of native Cosmos coins and IBC vouchers on the HAQQ Network can transfer their Tokens on HAQQ EVM by creating a `MsgSend` or `MsgTransfer` Tx. :::tip @@ -98,6 +99,6 @@ Send coins from one address to another via IBC. Internal state transitions during execution: - check if ERC-20 is enabled - - check if the coins have registered token pairs - - convert tokens into coins + - check if the coins have registered token pairs + - convert tokens into coins - execute IBC transfer on HAQQ Cosmos runtime diff --git a/docs/network/modules/coinomics.md b/docs/network/modules/coinomics.md index 62fe6e9..0ac55a2 100644 --- a/docs/network/modules/coinomics.md +++ b/docs/network/modules/coinomics.md @@ -38,7 +38,7 @@ coinomics/ ├── keeper │ ├── abci.go # ABCI BeginBlock and EndBlock logic │ ├── grpc_query.go # gRPC state query handlers -│ ├── inflation.go # Main coin minting calculations logic of the module +│ ├── inflation.go # Main coin minting calculations logic of the module │ ├── keeper.go # Store keeper that handles the business logic of the module and has access to a specific subtree of the state tree. │ ├── migrations.go # The module migration handler │ ├── mint_info.go # Store state handlers of the module @@ -61,8 +61,8 @@ coinomics/ Islomic Coin [Whitepaper](https://islamiccoin.net/whitepaper) describes a minting mechanism in details. Briefly, ISLM supply is limited to 100 billion coins. Inflation is calculated as a percentage of total bonded coins -which is a parameter `RewardCoefficient` controlled by governance and is initially set to `7.78%` -(i.e. expected to generate ~7% yield for staked ISLM). +which is a parameter `RewardCoefficient` controlled by governance and is initially set to `7.78%` +(i.e. expected to generate ~7% yield for staked ISLM). In each block, newly minted coins (rewards) are calculated as: ``` @@ -77,7 +77,7 @@ Only `KeyPrefixPrevBlockTS` in previous block needs to be tracked in state for t Value of `KeyPrefixMaxSupply` is assumed to be constant and doesn't change during blocks mining. | | Description | Key | Value | Store | -| -------------------- | ------------------------------- | ----------- | ------------------ | ----- | +|----------------------|---------------------------------|-------------|--------------------|-------| | KeyPrefixPrevBlockTS | Timestamp of the previous block | `[]byte{1}` | `[]byte{sdk.Int}` | KV | | KeyPrefixMaxSupply | Maximum total ISLM supply | `[]byte{2}` | `[]byte{sdk.Coin}` | KV | @@ -99,8 +99,8 @@ We introduce two parameters : `EnableCoinomics`and `RewardCoefficient`. `EnableCoinomics` controls the module execution. - If `EnableCoinomics = false`, all calculations and coin minting will be disabled and module will return without further computation. -- If `RewardCoefficient = 0`, the amount of coins to be minted is dynamically calculated, minted and allocated upon each block at `EndBlock`. - However, the result of these calculations always will be `zero` and no coins will be minted. +- If `RewardCoefficient = 0`, the amount of coins to be minted is dynamically calculated, minted and allocated upon each block at `EndBlock`. +However, the result of these calculations always will be `zero` and no coins will be minted. #### Enabling mint @@ -111,7 +111,7 @@ To enable coin minting, the following parameters should be set: #### Calculation -The `KeyPrefixPrevBlockTS` is initialized at the block height when `EnableCoinomics` has been set to `true` +The `KeyPrefixPrevBlockTS` is initialized at the block height when `EnableCoinomics` has been set to `true` to the `BlockTime` value of previous block. The coin mint is after calculated, minted and allocated according to the time elapsed since in the previous block. @@ -128,7 +128,7 @@ if EnableCoinomics == true { currentBlockTS, _ := sdk.NewDecFromStr(math.NewInt(ctx.BlockTime().UnixMilli()).String()) totalBonded, _ := sdk.NewDecFromStr(k.stakingKeeper.TotalBondedTokens(ctx).String()) rewardCoefficient := params.RewardCoefficient.Quo(sdk.NewDec(100)) - + blockMint := totalBonded.Mul(rewardCoefficient).Mul((currentBlockTS.Sub(prevBlockTS)).Quo(yearInMillis)) } ``` @@ -153,7 +153,7 @@ type Keeper interface { The `x/coinomics` module contains the following parameters: | Key | Type | Default Values | Description | -| ----------------- | ------- | -------------- | -------------------------------------------- | +|-------------------|---------|----------------|----------------------------------------------| | MintDenom | string | `aISLM` | The denom of the coins to be minted | | EnableCoinomics | bool | `false` | Controls the execution of the module logic | | RewardCoefficient | sdk.Dec | 7.8 | The current staking Reward Coefficient value | @@ -239,7 +239,7 @@ reward_coefficient: "7.800000000000000000" #### Queries | Verb | Method | Description | -| ------ | ------------------------------------------- | --------------------------------- | +|--------|---------------------------------------------|-----------------------------------| | `gRPC` | `haqq.coinomics.v1.Query/MaxSupplyRequest` | Get the `MaxSupply` value | | `gRPC` | `haqq.coinomics.v1.Query/RewardCoefficient` | Get the `RewardCoefficient` value | | `gRPC` | `haqq.coinomics.v1.Query/Params` | Get the module params | diff --git a/docs/network/modules/epochs.md b/docs/network/modules/epochs.md index bd23a13..f611273 100644 --- a/docs/network/modules/epochs.md +++ b/docs/network/modules/epochs.md @@ -9,11 +9,11 @@ title: x/epochs This document specifies the internal `x/epochs` module of the HAQQ Network. -Often, when working with the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk), we would like to run certain +Often, when working with the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk), we would like to run certain pieces of code every so often. -The purpose of the `epochs` module is to allow other modules to maintain that they would like to be signaled -once in a time period. So, another module can specify it wants to execute certain code once a week, +The purpose of the `epochs` module is to allow other modules to maintain that they would like to be signaled +once in a time period. So, another module can specify it wants to execute certain code once a week, starting at UTC-time = x. `epochs` creates a generalized epoch interface to other modules so they can be more easily signaled upon such events. @@ -72,7 +72,7 @@ where `end time = start time + timer interval`. The `x/epochs` module keeps the following `objects in state`: | State Object | Description | Key | Value | Store | -| ------------ | ------------------- | -------------------- | ------------------- | ----- | +|--------------|---------------------|----------------------|---------------------|-------| | `EpochInfo` | Epoch info bytecode | `[]byte{identifier}` | `[]byte{epochInfo}` | KV | #### EpochInfo @@ -114,7 +114,7 @@ message EpochInfo { } ``` -The `epochs` module keeps these `EpochInfo` objects in state, which are initialized at genesis and are modified +The `epochs` module keeps these `EpochInfo` objects in state, which are initialized at genesis and are modified on begin blockers or end blockers. #### Genesis State @@ -137,14 +137,14 @@ The `x/epochs` module emits the following events: ### BeginBlocker | Type | Attribute Key | Attribute Value | -| ------------- | ---------------- | ---------------- | +|---------------|------------------|------------------| | `epoch_start` | `"epoch_number"` | `{epoch_number}` | | `epoch_start` | `"start_time"` | `{start_time}` | ### EndBlocker | Type | Attribute Key | Attribute Value | -| ----------- | ---------------- | ---------------- | +|-------------|------------------|------------------| | `epoch_end` | `"epoch_number"` | `{epoch_number}` | ## Keepers @@ -153,7 +153,7 @@ The `x/epochs` module only exposes one keeper, the epochs keeper, which can be u ### Epochs Keeper -Presently only one fully-permissioned epochs keeper is exposed, which has the ability to both read and write +Presently only one fully-permissioned epochs keeper is exposed, which has the ability to both read and write the `EpochInfo` for all epochs, and to iterate over all stored epochs. ```go @@ -213,7 +213,7 @@ func (k Keeper) BeforeEpochStart(ctx sdk.Context, identifier string, epochNumber ### Receiving Hooks -When other modules (outside of `x/epochs`) receive hooks, they need to filter the value `epochIdentifier`, +When other modules (outside of `x/epochs`) receive hooks, they need to filter the value `epochIdentifier`, and only do executions for a specific `epochIdentifier`. The filtered values from `epochIdentifier` could be stored in the `Params` of other modules, so they can be modified @@ -243,13 +243,13 @@ Because of this, the time allocated to each epoch will be `max(block_time x 2, e For example: if the `epoch_duration` is set to `1s`, and `block_time` is `5s`, actual epoch time should be `10s`. It is recommended to configure `epoch_duration` to be more than two times the `block_time`, to use this module correctly. -If there is a mismatch between the `epoch_duration` and the actual epoch time, as in the example above, then module +If there is a mismatch between the `epoch_duration` and the actual epoch time, as in the example above, then module logic could become invalid. ### Block-Time Drifts This implementation of the `x/epochs` module has block-time drifts based on the value of `block_time`. -For example: if we have an epoch of 100 units that ends at `t=100`, and we have a block at `t=97` and a block +For example: if we have an epoch of 100 units that ends at `t=100`, and we have a block at `t=97` and a block at `t=104` and `t=110`, this epoch ends at `t=104`, and the new epoch will start at `t=110`. There are time drifts here, varying about 1-2 blocks time, which will slow down epochs. diff --git a/docs/network/modules/erc20.md b/docs/network/modules/erc20.md index 55b8ad3..a95a734 100644 --- a/docs/network/modules/erc20.md +++ b/docs/network/modules/erc20.md @@ -12,18 +12,18 @@ This document specifies the internal `x/erc20` module of the HAQQ Network. The `x/erc20` module enables the HAQQ Network to support a trustless, on-chain bidirectional internal conversion of tokens between HAQQ EVM and Cosmos runtimes, specifically the [`x/evm`](../modules/evm) and [`x/bank`](../modules/bank) modules. This allows token holders on HAQQ to instantaneously convert their native Cosmos `sdk.Coins` (in this document -referred to as "Coin(s)") to ERC-20 (aka "Token(s)") and vice versa, while retaining fungibility with the original +referred to as "Coin(s)") to ERC-20 (aka "Token(s)") and vice versa, while retaining fungibility with the original asset on the issuing environment/runtime (EVM or Cosmos) and preserving ownership of the ERC-20 contract. This conversion functionality is fully governed by native ISLM token holders who manage the canonical `TokenPair` -registrations (ie, ERC20 ←→ Coin mappings). This governance functionality is implemented using the Cosmos-SDK +registrations (ie, ERC20 ←→ Coin mappings). This governance functionality is implemented using the Cosmos-SDK `gov` module with custom proposal types for registering and updating the canonical mappings respectively. Why is this important? Cosmos and the EVM are two runtimes that are not compatible by default. The native Cosmos Coins -cannot be used in applications that require the ERC-20 standard. Cosmos coins are held on the `x/bank` module +cannot be used in applications that require the ERC-20 standard. Cosmos coins are held on the `x/bank` module (with access to module methods like querying the supply or balances) and ERC-20 Tokens live on smart contracts. This problem is similar to [wETH](https://coinmarketcap.com/alexandria/article/what-is-wrapped-ethereum-weth), -with the difference, that it not only applies to gas tokens (like ISLM), but to all Cosmos Coins (IBC vouchers, +with the difference, that it not only applies to gas tokens (like ISLM), but to all Cosmos Coins (IBC vouchers, staking and gov coins, etc.) as well. With the `x/erc20` users on HAQQ can @@ -73,7 +73,7 @@ erc20/ ├── migrations │ └── v3 │ ├── types -│ │ └── params.go # Params struct for consensus version 3 of the module +│ │ └── params.go # Params struct for consensus version 3 of the module │ └── migration.go # Migration handler from consensus version 2 to 3 ├── spec │ └── *.md # The specifications of the module @@ -125,8 +125,8 @@ representing the ERC20 token for the token pair, giving the module ownership of #### Registration of an ERC20 token A proposal for an existing (i.e already deployed) ERC20 contract can be initiated too. -In this case, the ERC20 maintains the original owner of the contract and uses an escrow & mint / burn & unescrow -mechanism similar to the one defined by the +In this case, the ERC20 maintains the original owner of the contract and uses an escrow & mint / burn & unescrow +mechanism similar to the one defined by the [ICS20 - Fungible Token Transfer](https://github.com/cosmos/ibc/blob/master/spec/app/ics-020-fungible-token-transfer) specification. The token pair is composed of the original ERC20 token and a corresponding native Cosmos coin denomination. @@ -144,7 +144,7 @@ During the registration of a Cosmos Coin the following bank `Metadata` is used t - **Symbol** - **Decimals** -The native Cosmos Coin contains a more extensive metadata than the ERC20 and includes all necessary details +The native Cosmos Coin contains a more extensive metadata than the ERC20 and includes all necessary details for the conversion into a ERC20 Token, which requires no additional population of data. #### IBC voucher Metadata to ERC20 details @@ -152,8 +152,8 @@ for the conversion into a ERC20 Token, which requires no additional population o IBC vouchers should comply to the following standard: - **Name**: `{NAME} channel-{channel}` -- **Symbol**: `ibc{NAME}-{channel}` -- **Decimals**: derived from bank `Metadata` +- **Symbol**: `ibc{NAME}-{channel}` +- **Decimals**: derived from bank `Metadata` #### ERC20 details to Coin Metadata @@ -161,8 +161,8 @@ During the Registration of an ERC20 Token the Coin metadata is derived from the - **Description**: `Cosmos coin token representation of {contractAddress}` - **DenomUnits**: - - Coin: `0` - - ERC20: `{uint32(erc20Data.Decimals)}` + - Coin: `0` + - ERC20: `{uint32(erc20Data.Decimals)}` - **Base**: `{"erc20/%s", address}` - **Display**: `{erc20Data.Name}` - **Name**: `{types.CreateDenom(strContract)}` @@ -170,8 +170,8 @@ During the Registration of an ERC20 Token the Coin metadata is derived from the ### Token Pair Modifiers -A valid token pair can be modified through several governance proposals. The internal conversion of a token pair -can be toggled with `ToggleTokenConversionProposal`, so that the conversions between the token pair's tokens +A valid token pair can be modified through several governance proposals. The internal conversion of a token pair +can be toggled with `ToggleTokenConversionProposal`, so that the conversions between the token pair's tokens can be enabled or disabled. ### Token Conversion @@ -197,16 +197,16 @@ More sophisticated malicious implementations might also inherit code from custom include malicous behaviour. For an overview of more extensive examples, please review the `x/erc20` audit, section `IF-EVMOS-06: IERC20 Contracts may execute arbitrary code`. -As the `x/erc20` module allows any arbitrary ERC20 contract to be registered through governance, it is essential +As the `x/erc20` module allows any arbitrary ERC20 contract to be registered through governance, it is essential that the proposer or the voters manually verify during voting phase that the proposed contract uses the default `ERC20.sol` implementation. Here are our recommendations for the reviewing process: - - contract solidity code should be verified and accessable (e.g. using an explorer) - contract should be audited by a reputable auditor - inherited contracts need to be verified for correctness + ## State ### State Objects @@ -214,7 +214,7 @@ Here are our recommendations for the reviewing process: The `x/erc20` module keeps the following objects in state: | State Object | Description | Key | Value | Store | -| ------------------ | ---------------------------------------------- | --------------------------- | ------------------- | ----- | +|--------------------|------------------------------------------------|-----------------------------|---------------------|-------| | `TokenPair` | Token Pair bytecode | `[]byte{1} + []byte(id)` | `[]byte{tokenPair}` | KV | | `TokenPairByERC20` | Token Pair id bytecode by erc20 contract bytes | `[]byte{2} + []byte(erc20)` | `[]byte(id)` | KV | | `TokenPairByDenom` | Token Pair id bytecode by denom string | `[]byte{3} + []byte(denom)` | `[]byte(id)` | KV | @@ -242,12 +242,12 @@ The unique identifier of a `TokenPair` is obtained by obtaining the SHA256 hash and the Coin denomination using the following function: ```tsx -tokenPairId = sha256(erc20 + '|' + denom); +tokenPairId = sha256(erc20 + "|" + denom) ``` #### Token Origin -The `ConvertCoin` and `ConvertERC20` functionalities use the owner field to check whether the token being +The `ConvertCoin` and `ConvertERC20` functionalities use the owner field to check whether the token being used is a native Coin or a native ERC20. The field is based on the token registration proposal type (`RegisterCoinProposal` = 1, `RegisterERC20Proposal` = 2). @@ -301,6 +301,7 @@ type GenesisState struct { } ``` + ## State Transitions The `x/erc20` module allows for two types of registration state transitions. @@ -325,12 +326,12 @@ Note that the native ISLM coin cannot be registered, as any coin including "evm" on the EVM based on the ERC20Mintable ([ERC20Mintable by openzeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20)) interface - - Initial supply: 0 - - Token details (Name, Symbol, Decimals, etc) are derived from the bank module `Metadata` field on the proposal content. + - Initial supply: 0 + - Token details (Name, Symbol, Decimals, etc) are derived from the bank module `Metadata` field on the proposal content. #### 2. Register ERC20 -A user registers a ERC20 token contract that is already deployed on the EVM module. +A user registers a ERC20 token contract that is already deployed on the EVM module. Once the proposal passes (i.e. is approved by governance), the ERC20 module creates a Cosmos coin representation of the ERC20 token. 1. User submits a `RegisterERC20Proposal` @@ -363,20 +364,20 @@ and thus granting it the permission to call the `mint()` and `burnFrom()` method - There shouldn't exist any native Cosmos Coin ERC20 Contract (eg ISLM, Atom, Osmo ERC20 contracts) that is not owned by the governance - Token/Coin supply is maintained at all times: - - Total Coin supply = Coins + Escrowed Coins - - Total Token supply = Escrowed Coins = Minted Tokens + - Total Coin supply = Coins + Escrowed Coins + - Total Token supply = Escrowed Coins = Minted Tokens ##### 1.1 Coin to ERC20 1. User submits `ConvertCoin` Tx 2. Check if conversion is allowed for the pair, sender and recipient - - global parameter is enabled - - token pair is enabled - - sender tokens are not vesting (checked in the bank module) - - recipient address is not blacklisted + - global parameter is enabled + - token pair is enabled + - sender tokens are not vesting (checked in the bank module) + - recipient address is not blacklisted 3. If Coin is a native Cosmos Coin and Token Owner is `ModuleAccount` - 1. Escrow Cosmos coin by sending them to the `erc20` module account - 2. Call `mint()` ERC20 tokens from the `ModuleAccount` address and send minted tokens to recipient address + 1. Escrow Cosmos coin by sending them to the `erc20` module account + 2. Call `mint()` ERC20 tokens from the `ModuleAccount` address and send minted tokens to recipient address 4. Check if token balance increased by amount ##### 1.2 ERC20 to Coin @@ -384,11 +385,11 @@ and thus granting it the permission to call the `mint()` and `burnFrom()` method 1. User submits a `ConvertERC20` Tx 2. Check if conversion is allowed for the pair, sender and recipient (see [1.1 Coin to ERC20](#11-coin-to-erc20)) 3. If token is a ERC20 and Token Owner is `ModuleAccount` - 1. Call `burnCoins()` on ERC20 to burn ERC20 tokens from the user balance - 2. Send Coins (previously escrowed, see [1.1 Coin to ERC20](#11-coin-to-erc20)) from module to the recipient address. + 1. Call `burnCoins()` on ERC20 to burn ERC20 tokens from the user balance + 2. Send Coins (previously escrowed, see [1.1 Coin to ERC20](#11-coin-to-erc20)) from module to the recipient address. 4. Check if - - Coin balance increased by amount - - Token balance decreased by amount + - Coin balance increased by amount + - Token balance decreased by amount #### 2. Registered ERC20 @@ -401,23 +402,23 @@ The mechanism described below follows the same model as the ICS20 standard, by u ##### Invariants - ERC20 Token supply on the EVM runtime is maintained at all times: - - Escrowed ERC20 + Minted Cosmos Coin representation of ERC20 = Burned Cosmos Coin representation of ERC20 + - Unescrowed ERC20 - - Convert 10 ERC20 → Coin, the total supply increases by 10. Mint on Cosmos side, no changes on EVM - - Convert 10 Coin → ERC20, the total supply decreases by 10. Burn on Cosmos side , no changes of supply on EVM - - Total ERC20 token supply = Non Escrowed Tokens + Escrowed Tokens (on Module account address) - - Total Coin supply for the native ERC20 = Escrowed ERC20 Tokens on module account (i.e balance) = Minted Coins + - Escrowed ERC20 + Minted Cosmos Coin representation of ERC20 = Burned Cosmos Coin representation of ERC20 + + Unescrowed ERC20 + - Convert 10 ERC20 → Coin, the total supply increases by 10. Mint on Cosmos side, no changes on EVM + - Convert 10 Coin → ERC20, the total supply decreases by 10. Burn on Cosmos side , no changes of supply on EVM + - Total ERC20 token supply = Non Escrowed Tokens + Escrowed Tokens (on Module account address) + - Total Coin supply for the native ERC20 = Escrowed ERC20 Tokens on module account (i.e balance) = Minted Coins ##### 2.1 ERC20 to Coin 1. User submits a `ConvertERC20` Tx 2. Check if conversion is allowed for the pair, sender and recipient (See [1.1 Coin to ERC20](#11-coin-to-erc20)) 3. If token is a ERC20 and Token Owner is **not** `ModuleAccount` - 1. Escrow ERC20 token by sending them to the `erc20` module account - 2. Mint Cosmos coins of the corresponding token pair denomination and send coins to the recipient address + 1. Escrow ERC20 token by sending them to the `erc20` module account + 2. Mint Cosmos coins of the corresponding token pair denomination and send coins to the recipient address 4. Check if - - Coin balance increased by amount - - Token balance decreased by amount + - Coin balance increased by amount + - Token balance decreased by amount 5. Fail if unexpected `Approval` event found in logs to prevent malicious contract behaviour ##### 2.2 Coin to ERC20 @@ -425,12 +426,13 @@ The mechanism described below follows the same model as the ICS20 standard, by u 1. User submits `ConvertCoin` Tx 2. Check if conversion is allowed for the pair, sender and recipient 3. If coin is a native Cosmos coin and Token Owner is **not** `ModuleAccount` - 1. Escrow Cosmos Coins by sending them to the `erc20` module account - 2. Unlock escrowed ERC20 from the module address by sending it to the recipient - 3. Burn escrowed Cosmos coins + 1. Escrow Cosmos Coins by sending them to the `erc20` module account + 2. Unlock escrowed ERC20 from the module address by sending it to the recipient + 3. Burn escrowed Cosmos coins 4. Check if token balance increased by amount 5. Fail if unexpected `Approval` event found in logs to prevent malicious contract behaviour + ## Transactions This section defines the `sdk.Msg` concrete types that result in the state transitions defined on the previous section. @@ -456,12 +458,12 @@ The proposal content stateless validation fails if: - Title is invalid (length or char) - Description is invalid (length or char) - Metadata is invalid - - Name and Symbol are not blank - - Base and Display denominations are valid coin denominations - - Base and Display denominations are present in the `DenomUnit` slice - - Base denomination has exponent 0 - - Denomination units are sorted in ascending order - - Denomination units not duplicated + - Name and Symbol are not blank + - Base and Display denominations are valid coin denominations + - Base and Display denominations are present in the `DenomUnit` slice + - Base denomination has exponent 0 + - Denomination units are sorted in ascending order + - Denomination units not duplicated ### `RegisterERC20Proposal` @@ -553,7 +555,7 @@ The `erc20` module implements transaction hooks from the EVM in order to trigger ### EVM Hooks -The EVM hooks allows users to convert ERC20s to Cosmos Coins by sending an Ethereum tx transfer +The EVM hooks allows users to convert ERC20s to Cosmos Coins by sending an Ethereum tx transfer to the module account address. This enables native conversion of tokens via Metamask and EVM-enabled wallets for both token pairs that have been registered through a native Cosmos coin or an ERC20 token. Note that additional coin/token balance checks for sender and receiver to prevent malicious contract behaviour @@ -566,19 +568,20 @@ to the transaction is not available in the hook. 2. Check if the ERC20 Token that was transferred from the sender is a native ERC20 or a native Cosmos Coin by looking at the [Ethereum event logs](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378#:~:text=A%20log%20record%20can%20be,or%20a%20change%20of%20ownership.&text=Each%20log%20record%20consists%20of,going%20on%20in%20an%20event) 3. If the token contract address corresponds to the ERC20 representation of a native Cosmos Coin - 1. Call `burn()` ERC20 method from the `ModuleAccount`. - Note that this is the same as 1.2, but since the tokens are already on the ModuleAccount balance, - we burn the tokens from the module address instead of calling `burnFrom()`. - Also note that we don't need to mint because [1.1 coin to erc20](#state-transitions) escrows the coin - 2. Transfer Cosmos Coin to the bech32 account address of the sender hex address + 1. Call `burn()` ERC20 method from the `ModuleAccount`. + Note that this is the same as 1.2, but since the tokens are already on the ModuleAccount balance, + we burn the tokens from the module address instead of calling `burnFrom()`. + Also note that we don't need to mint because [1.1 coin to erc20](#state-transitions) escrows the coin + 2. Transfer Cosmos Coin to the bech32 account address of the sender hex address #### Registered ERC20: ERC20 to Coin 1. User transfers coins to the`ModuleAccount` to escrow them 2. Check if the ERC20 Token that was transferred is a native ERC20 or a native cosmos coin 3. If the token contract address is a native ERC20 token - 1. Mint Cosmos Coin - 2. Transfer Cosmos Coin to the bech32 account address of the sender hex + 1. Mint Cosmos Coin + 2. Transfer Cosmos Coin to the bech32 account address of the sender hex + ## Events @@ -587,28 +590,28 @@ The `x/erc20` module emits the following events: ### Register Coin Proposal | Type | Attribute Key | Attribute Value | -| --------------- | --------------- | ----------------- | +|-----------------|-----------------|-------------------| | `register_coin` | `"cosmos_coin"` | `{denom}` | | `register_coin` | `"erc20_token"` | `{erc20_address}` | ### Register ERC20 Proposal | Type | Attribute Key | Attribute Value | -| ---------------- | --------------- | ----------------- | +|------------------|-----------------|-------------------| | `register_erc20` | `"cosmos_coin"` | `{denom}` | | `register_erc20` | `"erc20_token"` | `{erc20_address}` | ### Toggle Token Conversion | Type | Attribute Key | Attribute Value | -| ------------------------- | --------------- | ----------------- | +|---------------------------|-----------------|-------------------| | `toggle_token_conversion` | `"erc20_token"` | `{erc20_address}` | | `toggle_token_conversion` | `"cosmos_coin"` | `{denom}` | ### Convert Coin | Type | Attribute Key | Attribute Value | -| -------------- | --------------- | ---------------------------- | +|----------------|-----------------|------------------------------| | `convert_coin` | `"sender"` | `{msg.Sender}` | | `convert_coin` | `"receiver"` | `{msg.Receiver}` | | `convert_coin` | `"amount"` | `{msg.Coin.Amount.String()}` | @@ -618,7 +621,7 @@ The `x/erc20` module emits the following events: ### Convert ERC20 | Type | Attribute Key | Attribute Value | -| --------------- | --------------- | ----------------------- | +|-----------------|-----------------|-------------------------| | `convert_erc20` | `"sender"` | `{msg.Sender}` | | `convert_erc20` | `"receiver"` | `{msg.Receiver}` | | `convert_erc20` | `"amount"` | `{msg.Amount.String()}` | @@ -630,7 +633,7 @@ The `x/erc20` module emits the following events: The erc20 module contains the following parameters: | Key | Type | Default Value | -| --------------- | ---- | ------------- | +|-----------------|------|---------------| | `EnableErc20` | bool | `true` | | `EnableEVMHook` | bool | `true` | @@ -641,14 +644,14 @@ When the parameter is disabled, it will prevent all token pair registration and ### Enable EVM Hook -The `EnableEVMHook` parameter enables the EVM hook to convert an ERC20 token to a Cosmos Coin by transferring -the Tokens through a `MsgEthereumTx` to the `ModuleAddress` Ethereum address. +The `EnableEVMHook` parameter enables the EVM hook to convert an ERC20 token to a Cosmos Coin by transferring +the Tokens through a `MsgEthereumTx` to the `ModuleAddress` Ethereum address. ## Clients ### CLI -Find below a list of `haqqd` commands added with the `x/erc20` module. +Find below a list of `haqqd` commands added with the `x/erc20` module. You can obtain the full list by using the `haqqd -h` command. A CLI command can look like this: @@ -659,7 +662,7 @@ haqqd query erc20 params #### Queries | Command | Subcommand | Description | -| --------------- | ------------- | ------------------------------ | +|-----------------|---------------|--------------------------------| | `query` `erc20` | `params` | Get erc20 params | | `query` `erc20` | `token-pair` | Get registered token pair | | `query` `erc20` | `token-pairs` | Get all registered token pairs | @@ -667,7 +670,7 @@ haqqd query erc20 params #### Transactions | Command | Subcommand | Description | -| ------------ | --------------- | ------------------------------ | +|--------------|-----------------|--------------------------------| | `tx` `erc20` | `convert-coin` | Convert a Cosmos Coin to ERC20 | | `tx` `erc20` | `convert-erc20` | Convert a ERC20 to Cosmos Coin | @@ -691,24 +694,24 @@ Where METADATA_FILE contains (example): { "metadata": [ { - "description": "The native staking and governance token of the Osmosis chain", - "denom_units": [ - { - "denom": "ibc/", - "exponent": 0, - "aliases": ["ibcuosmo"] - }, - { - "denom": "OSMO", - "exponent": 6 - } - ], - "base": "ibc/", - "display": "OSMO", - "name": "Osmo", - "symbol": "OSMO" - } - ] + "description": "The native staking and governance token of the Osmosis chain", + "denom_units": [ + { + "denom": "ibc/", + "exponent": 0, + "aliases": ["ibcuosmo"] + }, + { + "denom": "OSMO", + "exponent": 6 + } + ], + "base": "ibc/", + "display": "OSMO", + "name": "Osmo", + "symbol": "OSMO" + } + ] } ``` @@ -742,7 +745,7 @@ haqqd tx gov submit-legacy-proposal param-change PROPOSAL_FILE [flags] #### Queries | Verb | Method | Description | -| ------ | --------------------------------- | ------------------------------ | +|--------|-----------------------------------|--------------------------------| | `gRPC` | `evmos.erc20.v1.Query/Params` | Get erc20 params | | `gRPC` | `evmos.erc20.v1.Query/TokenPair` | Get registered token pair | | `gRPC` | `evmos.erc20.v1.Query/TokenPairs` | Get all registered token pairs | @@ -753,7 +756,7 @@ haqqd tx gov submit-legacy-proposal param-change PROPOSAL_FILE [flags] #### Transactions | Verb | Method | Description | -| ------ | ---------------------------------- | ------------------------------ | +|--------|------------------------------------|--------------------------------| | `gRPC` | `evmos.erc20.v1.Msg/ConvertCoin` | Convert a Cosmos Coin to ERC20 | | `gRPC` | `evmos.erc20.v1.Msg/ConvertERC20` | Convert a ERC20 to Cosmos Coin | | `GET` | `/evmos/erc20/v1/tx/convert_coin` | Convert a Cosmos Coin to ERC20 | diff --git a/docs/network/modules/evm.md b/docs/network/modules/evm.md index c61a8bc..913f95f 100644 --- a/docs/network/modules/evm.md +++ b/docs/network/modules/evm.md @@ -9,7 +9,7 @@ title: x/evm This document defines the specification of the Ethereum Virtual Machine (EVM) as a Cosmos SDK module. -Since the introduction of Ethereum in 2015, the ability to control digital assets through +Since the introduction of Ethereum in 2015, the ability to control digital assets through [**smart contracts**](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html) has attracted a large community of developers to build decentralized applications on the Ethereum Virtual Machine (EVM). This community is continuously creating extensive tooling and introducing standards, which are further increasing @@ -17,7 +17,7 @@ the adoption rate of EVM compatible technology. The growth of EVM-based chains (e.g. Ethereum), however, has uncovered several scalability challenges that are often referred to as the [trilemma of decentralization, security, and scalability](https://vitalik.ca/general/2021/04/07/sharding.html). -Developers are frustrated by high gas fees, slow transaction speed & throughput, and chain-specific governance +Developers are frustrated by high gas fees, slow transaction speed & throughput, and chain-specific governance that can only undergo slow change because of its wide range of deployed applications. A solution is required that eliminates these concerns for developers, who build applications within a familiar EVM environment. @@ -30,7 +30,7 @@ and horizontal scalability via [IBC](https://ibcprotocol.org/). :::note The `x/evm` module previously was a part of the [ethermint library](https://pkg.go.dev/github.com/evmos/ethermint), -but has been merged into the Evmos repository lately and got protected by new LICENCE. Therefore, we decided +but has been merged into the Evmos repository lately and got protected by new LICENCE. Therefore, we decided to merge the latest common version into the HAQQ repository. ::: @@ -70,7 +70,7 @@ evm/ │ └── statedb.go # Functions from types/statedb with a passed in sdk.Context ├── migrations │ └── * # Migrations for the module between given consensus versions -├── statedb +├── statedb │ ├── journal.go # Ethereum Journal of state transitions │ ├── state_object.go # EVM state object │ └── statedb.go # Implementation of the StateDb interface @@ -102,22 +102,22 @@ evm/ The Ethereum Virtual Machine (EVM) is a computation engine which can be thought of as one single entity maintained by thousands of connected computers (nodes) running an Ethereum client. -As a virtual machine ([VM](https://en.wikipedia.org/wiki/Virtual_machine)), the EVM is responsible for computing +As a virtual machine ([VM](https://en.wikipedia.org/wiki/Virtual_machine)), the EVM is responsible for computing changes to the state deterministically regardless of its environment (hardware and OS). This means that every node has to get the exact same result given an identical starting state and transaction (tx). -The EVM is considered to be the part of the Ethereum protocol that handles the deployment and execution +The EVM is considered to be the part of the Ethereum protocol that handles the deployment and execution of [smart contracts](https://ethereum.org/en/developers/docs/smart-contracts/). To make a clear distinction: -- The Ethereum protocol describes a blockchain, in which all Ethereum accounts and smart contracts live. +* The Ethereum protocol describes a blockchain, in which all Ethereum accounts and smart contracts live. It has only one canonical state (a data structure, which keeps all accounts) at any given block in the chain. -- The EVM, however, is the [state machine](https://en.wikipedia.org/wiki/Finite-state_machine) +* The EVM, however, is the [state machine](https://en.wikipedia.org/wiki/Finite-state_machine) that defines the rules for computing a new valid state from block to block. - It is an isolated runtime, which means that code running inside the EVM has no access to network, filesystem, + It is an isolated runtime, which means that code running inside the EVM has no access to network, filesystem, or other processes (not external APIs). -The `x/evm` module implements the EVM as a Cosmos SDK module. It allows users to interact with the EVM by submitting +The `x/evm` module implements the EVM as a Cosmos SDK module. It allows users to interact with the EVM by submitting Ethereum txs and executing their containing messages on the given state to evoke a state transition. #### State @@ -132,10 +132,10 @@ by executing transactions in a block using the EVM. A new block of txs can be de There are two types of accounts that can be stored in state at a given address: -- **Externally Owned Account (EOA)**: Has nonce (tx counter) and balance -- **Smart Contract**: Has nonce, balance, (immutable) code hash, storage root (another Merkle Patricia Trie) +* **Externally Owned Account (EOA)**: Has nonce (tx counter) and balance +* **Smart Contract**: Has nonce, balance, (immutable) code hash, storage root (another Merkle Patricia Trie) -Smart contracts are just like regular accounts on the blockchain, which additionally store executable code +Smart contracts are just like regular accounts on the blockchain, which additionally store executable code in an Ethereum-specific binary format, known as **EVM bytecode**. They are typically written in an Ethereum high level language, such as Solidity, which is compiled down to EVM bytecode and deployed on the blockchain by submitting a transaction using an Ethereum client. @@ -144,27 +144,27 @@ and deployed on the blockchain by submitting a transaction using an Ethereum cli The EVM operates as a stack-based machine. It's main architecture components consist of: -- Virtual ROM: contract code is pulled into this read only memory when processing txs -- Machine state (volatile): changes as the EVM runs and is wiped clean after processing each tx - - Program counter (PC) - - Gas: keeps track of how much gas is used - - Stack and Memory: compute state changes -- Access to account storage (persistent) +* Virtual ROM: contract code is pulled into this read only memory when processing txs +* Machine state (volatile): changes as the EVM runs and is wiped clean after processing each tx + * Program counter (PC) + * Gas: keeps track of how much gas is used + * Stack and Memory: compute state changes +* Access to account storage (persistent) #### State Transitions with Smart Contracts Typically smart contracts expose a public ABI, which is a list of supported ways a user can interact with a contract. -To interact with a contract and invoke a state transition, a user will submit a tx carrying any amount of gas +To interact with a contract and invoke a state transition, a user will submit a tx carrying any amount of gas and a data payload formatted according to the ABI, specifying the type of interaction and any additional parameters. When the tx is received, the EVM executes the smart contracts' EVM bytecode using the tx payload. #### Executing EVM bytecode A contract's EVM bytecode consists of basic operations (add, multiply, store, etc...), called **Opcodes**. -Each Opcode execution requires gas that needs to be paid with the tx. The EVM is therefore considered quasi-turing +Each Opcode execution requires gas that needs to be paid with the tx. The EVM is therefore considered quasi-turing complete, as it allows any arbitrary computation, but the amount of computations during a contract execution is limited to the amount of gas provided in the tx. -Each Opcode's [**gas cost**](https://www.evm.codes/) reflects the cost of running these operations on actual +Each Opcode's [**gas cost**](https://www.evm.codes/) reflects the cost of running these operations on actual computer hardware (e.g. `ADD = 3gas` and `SSTORE = 100gas`). To calculate the gas consumption of a tx, the gas cost is multiplied by the **gas price**, which can change depending on the demand of the network at the time. @@ -172,16 +172,16 @@ If the network is under heavy load, you might have to pay a higher gas price to If the gas limit is hit (out of gas exception) no changes to the Ethereum state are applied, except that the sender's nonce increments and their balance goes down to pay for wasting the EVM's time. -Smart contracts can also call other smart contracts. Each call to a new contract creates a new instance +Smart contracts can also call other smart contracts. Each call to a new contract creates a new instance of the EVM (including a new stack and memory). Each call passes the sandbox state to the next EVM. If the gas runs out, all state changes are discarded. Otherwise, they are kept. For further reading, please refer to: -- [EVM](https://eth.wiki/concepts/evm/evm) -- [EVM Architecture](https://cypherpunks-core.github.io/ethereumbook/13evm.html#evm_architecture) -- [What is Ethereum](https://ethdocs.org/en/latest/introduction/what-is-ethereum.html#what-is-ethereum) -- [Opcodes](https://www.ethervm.io/) +* [EVM](https://eth.wiki/concepts/evm/evm) +* [EVM Architecture](https://cypherpunks-core.github.io/ethereumbook/13evm.html#evm_architecture) +* [What is Ethereum](https://ethdocs.org/en/latest/introduction/what-is-ethereum.html#what-is-ethereum) +* [Opcodes](https://www.ethervm.io/) ### HAQQ as Geth implementation @@ -197,7 +197,7 @@ in order to be Web3 and EVM compatible. #### JSON-RPC JSON-RPC is a stateless, lightweight remote procedure call (RPC) protocol. Primarily this specification defines -several data structures and the rules around their processing. It is transport agnostic in that the concepts +several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments. It uses JSON (RFC 4627) as a data format. @@ -205,7 +205,7 @@ It uses JSON (RFC 4627) as a data format. The JSON-RPC method [`eth_call`](../../develop/api/ethereum-json-rpc/methods#eth_call) allows you to execute messages against contracts. -Usually, you need to send a transaction to a Geth node to include it in the mempool, then nodes gossip between +Usually, you need to send a transaction to a Geth node to include it in the mempool, then nodes gossip between each other and eventually the transaction is included in a block and gets executed. `eth_call` however lets you send data to a contract and see what happens without committing a transaction. @@ -241,8 +241,8 @@ The HAQQ implementation is similar and makes use of the gRPC query client which #### StateDB The `StateDB` interface from [go-ethereum](https://github.com/ethereum/go-ethereum/blob/master/core/vm/interface.go) -represents an EVM database for full state querying. EVM state transitions are enabled by this interface, -which in the `x/evm` module is implemented by the `Keeper`. +represents an EVM database for full state querying. EVM state transitions are enabled by this interface, +which in the `x/evm` module is implemented by the `Keeper`. The implementation of this interface is what makes HAQQ EVM compatible. ### Consensus Engine @@ -287,7 +287,7 @@ The `x/evm` module keeps the following objects in state: #### State | | Description | Key | Value | Store | -| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ------------------- | --------- | +|-------------|------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------|---------------------|-----------| | Code | Smart contract bytecode | `[]byte{1} + []byte(address)` | `[]byte{code}` | KV | | Storage | Smart contract storage | `[]byte{2} + [32]byte{key}` | `[32]byte(value)` | KV | | Block Bloom | Block bloom filter, used to accumulate the bloom filter of current block, emitted to events at end blocker. | `[]byte{1} + []byte(tx.Hash)` | `protobuf([]Log)` | Transient | @@ -305,37 +305,37 @@ within the IAVL tree and take care of caching and storing nested states. // github.com/ethereum/go-ethereum/core/vm/interface.go type StateDB interface { CreateAccount(common.Address) - + SubBalance(common.Address, *big.Int) AddBalance(common.Address, *big.Int) GetBalance(common.Address) *big.Int - + GetNonce(common.Address) uint64 SetNonce(common.Address, uint64) - + GetCodeHash(common.Address) common.Hash GetCode(common.Address) []byte SetCode(common.Address, []byte) GetCodeSize(common.Address) int - + AddRefund(uint64) SubRefund(uint64) GetRefund() uint64 - + GetCommittedState(common.Address, common.Hash) common.Hash GetState(common.Address, common.Hash) common.Hash SetState(common.Address, common.Hash, common.Hash) - + Suicide(common.Address) bool HasSuicided(common.Address) bool - + // Exist reports whether the given account exists in state. // Notably this should also return true for suicided accounts. Exist(common.Address) bool // Empty returns whether the given account is empty. Empty // is defined according to EIP161 (balance = nonce = code = 0). Empty(common.Address) bool - + PrepareAccessList(sender common.Address, dest *common.Address, precompiles []common.Address, txAccesses types.AccessList) AddressInAccessList(addr common.Address) bool SlotInAccessList(addr common.Address, slot common.Hash) (addressOk bool, slotOk bool) @@ -345,13 +345,13 @@ type StateDB interface { // AddSlotToAccessList adds the given (address,slot) to the access list. This operation is safe to perform // even if the feature/fork is not active yet AddSlotToAccessList(addr common.Address, slot common.Hash) - + RevertToSnapshot(int) Snapshot() int - + AddLog(*types.Log) AddPreimage(common.Hash, []byte) - + ForEachStorage(common.Address, func(common.Hash, common.Hash) bool) error } ``` @@ -423,22 +423,22 @@ To check account existence use `Exist()` and `Empty()`. - `Exist()` returns true if the given account exists in store or if it has been marked as suicided. - `Empty()` returns true if the address meets the following conditions: - - nonce is 0 - - balance amount for evm denom is 0 - - account code hash is empty + - nonce is 0 + - balance amount for evm denom is 0 + - account code hash is empty #### EIP2930 functionality Supports a transaction type that contains an [access list](https://eips.ethereum.org/EIPS/eip-2930), a list of addresses -and storage keys, that the transaction plans to access. The access list state is kept in memory and discarded after +and storage keys, that the transaction plans to access. The access list state is kept in memory and discarded after the transaction committed. - `PrepareAccessList()` handles the preparatory steps for executing a state transition in regard to both EIP-2929 and EIP-2930. This method should only be called if Yolov3/Berlin/2929+2930 is applicable at the current number. - - Add sender to access list (EIP-2929) - - Add destination to access list (EIP-2929) - - Add precompiles to access list (EIP-2929) - - Add the contents of the optional tx access list (EIP-2930) + - Add sender to access list (EIP-2929) + - Add destination to access list (EIP-2929) + - Add precompiles to access list (EIP-2929) + - Add the contents of the optional tx access list (EIP-2930) - `AddressInAccessList()` returns true if the address is registered. - `SlotInAccessList()` checks if the address and the slots are registered. - `AddAddressToAccessList()` adds the given address to the access list. @@ -450,7 +450,7 @@ the transaction committed. The EVM uses state-reverting exceptions to handle errors. Such an exception will undo all changes made to the state in the current call (and all its sub-calls), and the caller could handle the error and don't propagate. -You can use `Snapshot()` to identify the current state with a revision and revert the state to a given revision +You can use `Snapshot()` to identify the current state with a revision and revert the state to a given revision with `RevertToSnapshot()` to support this feature. - `Snapshot()` creates a new snapshot and returns the identifier. @@ -464,14 +464,14 @@ and to revert to a snapshot it just undoes the journal logs after the snapshot i #### Ethereum Transaction logs With `AddLog()` you can append the given Ethereum `Log` to the list of logs associated with the transaction hash kept -in the current state. This function also fills in the tx hash, block hash, tx index and log index fields before +in the current state. This function also fills in the tx hash, block hash, tx index and log index fields before setting the log to store. ### Keeper The EVM module `Keeper` grants access to the EVM module state and implements `statedb.Keeper` interface to support the `StateDB` implementation. -The Keeper contains a store key that allows the DB to write to a concrete subtree of the multistore that is only +The Keeper contains a store key that allows the DB to write to a concrete subtree of the multistore that is only accessible by the EVM module. Instead of using a trie and database for querying and persistence (the `StateDB` implementation), HAQQ uses the Cosmos `KVStore` (key-value store) and Cosmos SDK `Keeper` to facilitate state transitions. @@ -494,10 +494,10 @@ type Keeper struct { // - storing Bloom filters by block height. Needed for the Web3 API. // For the full list, check the module specification storeKey sdk.StoreKey - + // key to access the transient store, which is reset on every block during Commit transientKey sdk.StoreKey - + // module specific parameter space that can be configured through governance paramSpace paramtypes.Subspace // access to account state @@ -508,16 +508,16 @@ type Keeper struct { stakingKeeper types.StakingKeeper // fetch EIP1559 base fee and parameters feeMarketKeeper types.FeeMarketKeeper - + // chain ID number obtained from the context's chain id eip155ChainID *big.Int - + // Tracer used to collect execution traces from the EVM transaction execution tracer string // trace EVM state transition execution. This value is obtained from the `--trace` flag. // For more info check https://geth.ethereum.org/docs/dapp/tracing debug bool - + // EVM Hooks for tx post-processing hooks types.EvmHooks } @@ -563,10 +563,10 @@ type GenesisAccount struct { ## State Transitions -The `x/evm` module allows for users to submit Ethereum transactions (`Tx`) and execute their containing messages +The `x/evm` module allows for users to submit Ethereum transactions (`Tx`) and execute their containing messages to evoke state transitions on the given state. -Users submit transactions client-side to broadcast it to the network. When the transaction is included in a block +Users submit transactions client-side to broadcast it to the network. When the transaction is included in a block during consensus, it is executed server-side. We highly recommend to understand the basics of the [CometBFT consensus engine](https://docs.cometbft.com/v0.37/introduction/what-is-cometbft#intro-to-abci) to understand the State Transitions in detail. @@ -577,17 +577,17 @@ to understand the State Transitions in detail. 👉 This is based on the `eth_sendTransaction` JSON-RPC ::: -1. A user submits a transaction via one of the available JSON-RPC endpoints using an Ethereum-compatible client +1. A user submits a transaction via one of the available JSON-RPC endpoints using an Ethereum-compatible client or wallet (eg Metamask, WalletConnect, Ledger, etc): - `eth` (public) namespace: - - `eth_sendTransaction` - - `eth_sendRawTransaction` + - `eth_sendTransaction` + - `eth_sendRawTransaction` - `personal` (private) namespace: - - `personal_sendTransaction` -2. An instance of `MsgEthereumTx` is created after populating the RPC transaction using `SetTxDefaults` to fill - missing tx arguments with default values + - `personal_sendTransaction` +2. An instance of `MsgEthereumTx` is created after populating the RPC transaction using `SetTxDefaults` to fill + missing tx arguments with default values 3. The `Tx` fields are validated (stateless) using `ValidateBasic()` -4. The `Tx` is **signed** using the key associated with the sender address and the latest ethereum hard +4. The `Tx` is **signed** using the key associated with the sender address and the latest ethereum hard fork (`London`, `Berlin`, etc) from the `ChainConfig` 5. The `Tx` is **built** from the msg fields using the Cosmos Config builder 6. The `Tx` is **broadcast** in [sync mode](https://docs.cosmos.network/main/run-node/txs.html#broadcasting-a-transaction) @@ -599,50 +599,50 @@ to understand the State Transitions in detail. ### Server-Side -Once a block (containing the `Tx`) has been committed during consensus, it is applied to the application in a series +Once a block (containing the `Tx`) has been committed during consensus, it is applied to the application in a series of ABCI msgs server-side. Each `Tx` is handled by the application by calling [`RunTx`](https://docs.cosmos.network/main/core/baseapp.html#runtx). After a stateless validation on each `sdk.Msg` in the `Tx`, the `AnteHandler` confirms whether the `Tx` is an Ethereum -or SDK transaction. As an Ethereum transaction it's containing msgs are then handled by the `x/evm` module to update +or SDK transaction. As an Ethereum transaction it's containing msgs are then handled by the `x/evm` module to update the application's state. #### AnteHandler -The `anteHandler` is run for every transaction. It checks if the `Tx` is an Ethereum transaction and routes it -to an internal ante handler. Here, `Tx`s are handled using `EthereumTx` extension options to process them differently -than normal Cosmos SDK transactions. The `antehandler` runs through a series of options and their `AnteHandle` +The `anteHandler` is run for every transaction. It checks if the `Tx` is an Ethereum transaction and routes it +to an internal ante handler. Here, `Tx`s are handled using `EthereumTx` extension options to process them differently +than normal Cosmos SDK transactions. The `antehandler` runs through a series of options and their `AnteHandle` functions for each `Tx`: -- `EthSetUpContextDecorator()` is adapted from `SetUpContextDecorator` from cosmos-sdk, it ignores gas consumption +- `EthSetUpContextDecorator()` is adapted from `SetUpContextDecorator` from cosmos-sdk, it ignores gas consumption by setting the gas meter to infinite - `EthValidateBasicDecorator(evmKeeper)` validates the fields of an Ethereum type Cosmos `Tx` msg - `EthSigVerificationDecorator(evmKeeper)` validates that the registered chain id is the same as the one on the message, - and that the signer address matches the one defined on the message. It's not skipped for `RecheckTx`, because it - set `From` address which is critical from other ante handler to work. Failure in `RecheckTx` will prevent tx + and that the signer address matches the one defined on the message. It's not skipped for `RecheckTx`, because it + set `From` address which is critical from other ante handler to work. Failure in `RecheckTx` will prevent tx to be included into block, especially when `CheckTx` succeed, in which case user won't see the error message. - `EthAccountVerificationDecorator(ak, bankKeeper, evmKeeper)` - will verify, that the sender balance is greater than the total transaction cost. The account will be set to store + will verify, that the sender balance is greater than the total transaction cost. The account will be set to store if it doesn't exist, i.e cannot be found on store. This `AnteHandler` decorator will fail if: - - any of the msgs is not a `MsgEthereumTx` - - from address is empty - - account balance is lower than the transaction cost + - any of the msgs is not a `MsgEthereumTx` + - from address is empty + - account balance is lower than the transaction cost - `EthNonceVerificationDecorator(ak)` validates that the transaction nonces are valid and equivalent to the sender account’s current nonce. -- `EthGasConsumeDecorator(evmKeeper)` validates that the Ethereum tx message has enough to cover intrinsic - gas (during `CheckTx` only) and that the sender has enough balance to pay for the gas cost. Intrinsic gas for - a transaction is the amount of gas that the transaction uses before the transaction is executed. The gas is +- `EthGasConsumeDecorator(evmKeeper)` validates that the Ethereum tx message has enough to cover intrinsic + gas (during `CheckTx` only) and that the sender has enough balance to pay for the gas cost. Intrinsic gas for + a transaction is the amount of gas that the transaction uses before the transaction is executed. The gas is a constant value plus any cost incurred by additional bytes of data supplied with the transaction. This AnteHandler decorator will fail if: - - the transaction contains more than one message - - the message is not a `MsgEthereumTx` - - sender account cannot be found - - transaction's gas limit is lower than the intrinsic gas - - user doesn't have enough balance to deduct the transaction fees (`gas_limit * gas_price`) - - transaction or block gas meter runs out of gas -- `CanTransferDecorator(evmKeeper, feeMarketKeeper)` creates an EVM from the message and calls the `BlockContext` + - the transaction contains more than one message + - the message is not a `MsgEthereumTx` + - sender account cannot be found + - transaction's gas limit is lower than the intrinsic gas + - user doesn't have enough balance to deduct the transaction fees (`gas_limit * gas_price`) + - transaction or block gas meter runs out of gas +- `CanTransferDecorator(evmKeeper, feeMarketKeeper)` creates an EVM from the message and calls the `BlockContext` `CanTransfer` function to see if the address can execute the transaction. -- `EthIncrementSenderSequenceDecorator(ak)` handles incrementing the sequence of the signer (i.e sender). - If the transaction is a contract creation, the nonce will be incremented during the transaction execution +- `EthIncrementSenderSequenceDecorator(ak)` handles incrementing the sequence of the signer (i.e sender). + If the transaction is a contract creation, the nonce will be incremented during the transaction execution and not within this AnteHandler decorator. The options `authante.NewMempoolFeeDecorator()`, `authante.NewTxTimeoutHeightDecorator()` @@ -651,26 +651,26 @@ Click [here](https://docs.cosmos.network/main/basics/gas-fees.html#antehandler) #### EVM module -After authentication through the `antehandler`, each `sdk.Msg` (in this case `MsgEthereumTx`) in the `Tx`is delivered +After authentication through the `antehandler`, each `sdk.Msg` (in this case `MsgEthereumTx`) in the `Tx`is delivered to the Msg Handler in the `x/evm` module and runs through the following the steps: 1. Convert `Msg` to an ethereum `Tx` type 2. Apply `Tx` with `EVMConfig` and attempt to perform a state transition, that will only be persisted (committed) to the underlying KVStore if the transaction does not fail: - 1. Confirm that `EVMConfig` is created - 2. Create the ethereum signer using chain config value from `EVMConfig` - 3. Set the ethereum transaction hash to the (impermanent) transient store so that it's also available on the StateDB functions - 4. Generate a new EVM instance - 5. Confirm that EVM params for contract creation (`EnableCreate`) and contract execution (`EnableCall`) are enabled - 6. Apply message. If `To` address is `nil`, create new contract using code as deployment code. - Else call contract at given address with the given input as parameters - 7. Calculate gas used by the evm operation + 1. Confirm that `EVMConfig` is created + 2. Create the ethereum signer using chain config value from `EVMConfig` + 3. Set the ethereum transaction hash to the (impermanent) transient store so that it's also available on the StateDB functions + 4. Generate a new EVM instance + 5. Confirm that EVM params for contract creation (`EnableCreate`) and contract execution (`EnableCall`) are enabled + 6. Apply message. If `To` address is `nil`, create new contract using code as deployment code. + Else call contract at given address with the given input as parameters + 7. Calculate gas used by the evm operation 3. If `Tx` applied successfully - 1. Execute EVM `Tx` postprocessing hooks. If hooks return error, revert the whole `Tx` - 2. Refund gas according to Ethereum gas accounting rules - 3. Update block bloom filter value using the logs generated from the tx - 4. Emit SDK events for the transaction fields and tx logs + 1. Execute EVM `Tx` postprocessing hooks. If hooks return error, revert the whole `Tx` + 2. Refund gas according to Ethereum gas accounting rules + 3. Update block bloom filter value using the logs generated from the tx + 4. Emit SDK events for the transaction fields and tx logs ## Transactions @@ -678,10 +678,10 @@ This section defines the `sdk.Msg` concrete types that result in the state trans ## `MsgEthereumTx` -An EVM state transition can be achieved by using the `MsgEthereumTx`. This message encapsulates an Ethereum -transaction data (`TxData`) as a `sdk.Msg`. It contains the necessary transaction data fields. Note, that +An EVM state transition can be achieved by using the `MsgEthereumTx`. This message encapsulates an Ethereum +transaction data (`TxData`) as a `sdk.Msg`. It contains the necessary transaction data fields. Note, that the `MsgEthereumTx` implements both the [`sdk.Msg`](https://github.com/cosmos/cosmos-sdk/blob/v0.39.2/types/tx_msg.go#L7-L29) -and [`sdk.Tx`](https://github.com/cosmos/cosmos-sdk/blob/v0.39.2/types/tx_msg.go#L33-L41) interfaces. Normally, +and [`sdk.Tx`](https://github.com/cosmos/cosmos-sdk/blob/v0.39.2/types/tx_msg.go#L33-L41) interfaces. Normally, SDK messages only implement the former, while the latter is a group of messages bundled together. ```go @@ -707,10 +707,10 @@ This message field validation is expected to fail if: The transaction execution is expected to fail if: - Any of the custom `AnteHandler` Ethereum decorators checks fail: - - Minimum gas amount requirements for transaction - - Tx sender account doesn't exist or hasn't enough balance for fees - - Account sequence doesn't match the transaction `Data.AccountNonce` - - Message signature verification fails + - Minimum gas amount requirements for transaction + - Tx sender account doesn't exist or hasn't enough balance for fees + - Account sequence doesn't match the transaction `Data.AccountNonce` + - Message signature verification fails - EVM contract creation (i.e `evm.Create`) fails, or `evm.Call` fails #### Conversion @@ -724,7 +724,7 @@ func (msg MsgEthereumTx) AsTransaction() *ethtypes.Transaction { if err != nil { return nil } - + return ethtypes.NewTx(txData.AsEthereumData()) } @@ -742,12 +742,12 @@ func (tx *Transaction) AsMessage(s Signer, baseFee *big.Int) (Message, error) { accessList: tx.AccessList(), isFake: false, } - + // If baseFee provided, set gasPrice to effectiveGasPrice. if baseFee != nil { msg.gasPrice = math.BigMin(msg.gasPrice.Add(msg.gasTipCap, baseFee), msg.gasFeeCap) } - + var err error msg.from, err = Sender(s, tx) @@ -757,10 +757,10 @@ func (tx *Transaction) AsMessage(s Signer, baseFee *big.Int) (Message, error) { #### Signing -In order for the signature verification to be valid, the `TxData` must contain the `v | r | s` values from the `Signer`. +In order for the signature verification to be valid, the `TxData` must contain the `v | r | s` values from the `Signer`. Sign calculates a `secp256k1` ECDSA signature and signs the transaction. It takes a keyring signer and the `chainID` to sign an Ethereum transaction according to EIP155 standard. This method mutates the transaction as it populates -the `V`, `R`, `S` fields of the Transaction's Signature. The function will fail if the sender address is not defined +the `V`, `R`, `S` fields of the Transaction's Signature. The function will fail if the sender address is not defined for the msg or if the sender is not registered on the keyring. ```go @@ -798,7 +798,7 @@ func (msg *MsgEthereumTx) Sign(ethSigner ethtypes.Signer, keyringSigner keyring. ### TxData The `MsgEthereumTx` supports the 3 valid Ethereum transaction data types from go-ethereum: `LegacyTx`, `AccessListTx` -and `DynamicFeeTx`. These types are defined as protobuf messages and packed into a `proto.Any` interface type +and `DynamicFeeTx`. These types are defined as protobuf messages and packed into a `proto.Any` interface type in the `MsgEthereumTx` field. - `LegacyTx`: [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md) transaction type @@ -878,7 +878,7 @@ This message field validation is expected to fail if: - `GasTipCap` is invalid (`nil` , negative or overflows int256) - `GasFeeCap` is invalid (`nil` , negative or overflows int256) - `GasFeeCap` is less than `GasTipCap` -- `Fee` (gas price \* gas limit) is invalid (overflows int256) +- `Fee` (gas price * gas limit) is invalid (overflows int256) - `Amount` is invalid (negative or overflows int256) - `To` address is invalid (non-valid ethereum hex address) - `ChainID` is `nil` @@ -924,7 +924,7 @@ This message field validation is expected to fail if: ## ABCI The Application Blockchain Interface (ABCI) allows the application to interact with the CometBFT Consensus engine. -The application maintains several ABCI connections with CometBFT. The most relevant for the `x/evm` is the +The application maintains several ABCI connections with CometBFT. The most relevant for the `x/evm` is the [Consensus connection at Commit](https://docs.cometbft.com/v0.37/spec/abci/abci++_app_requirements#consensus-connection-requirements). This connection is responsible for block execution and calls the functions `InitChain` (containing `InitGenesis`), `BeginBlock`, `DeliverTx`, `EndBlock`, `Commit` . `InitChain` is only called the first time a new blockchain is started @@ -937,7 +937,7 @@ In particular, it sets the parameters and genesis accounts (state and code). ### ExportGenesis -The `ExportGenesis` ABCI function exports the genesis state of the EVM module. In particular, it retrieves all +The `ExportGenesis` ABCI function exports the genesis state of the EVM module. In particular, it retrieves all the accounts with their bytecode, balance and storage, the transaction logs, and the EVM parameters and chain configuration. ### BeginBlock @@ -956,9 +956,9 @@ The EVM module `EndBlock` logic occurs after executing all the state transitions The main objective of this function is to: - Emit Block bloom events - - This is due for web3 compatibility as the Ethereum headers contain this type as a field. - The JSON-RPC service uses this event query to construct an Ethereum header from a CometBFT header. - - The block bloom filter value is obtained from the transient store and then emitted + - This is due for web3 compatibility as the Ethereum headers contain this type as a field. + The JSON-RPC service uses this event query to construct an Ethereum header from a CometBFT header. + - The block bloom filter value is obtained from the transient store and then emitted ## Hooks @@ -970,8 +970,8 @@ This supports EVM contracts to call native cosmos modules by 2. recognizing those logs in the native tx processing code, and 3. converting them to native module calls. -To do this, the interface includes a `PostTxProcessing` hook that registers custom `Tx` hooks in the `EvmKeeper`. -These `Tx` hooks are processed after the EVM state transition is finalized and doesn't fail. +To do this, the interface includes a `PostTxProcessing` hook that registers custom `Tx` hooks in the `EvmKeeper`. +These `Tx` hooks are processed after the EVM state transition is finalized and doesn't fail. Note that there are no default hooks implemented in the EVM module. ```go @@ -991,7 +991,7 @@ func (k *Keeper) PostTxProcessing(ctx sdk.Context, msg core.Message, receipt *et if k.hooks == nil { return nil } - + return k.hooks.PostTxProcessing(k.Ctx(), msg, receipt) } ``` @@ -1000,7 +1000,7 @@ It's executed in the same cache context as the EVM transaction, if it returns an if the hook implementor doesn't want to revert the tx, they can always return `nil` instead. The error returned by the hooks is translated to a VM error `failed to process native logs`, the detailed error message -is stored in the return value. The message is sent to native modules asynchronously, there's no way for the caller +is stored in the return value. The message is sent to native modules asynchronously, there's no way for the caller to catch and recover the error. ### Use Case: Call Native ERC20 Module on HAQQ @@ -1052,28 +1052,28 @@ func (k Keeper) PostTxProcessing( } eventID := log.Topics[0] // event ID - + event, err := erc20.EventByID(eventID) if err != nil { // invalid event for ERC20 continue } - + if event.Name != types.ERC20EventTransfer { h.k.Logger(ctx).Info("emitted event", "name", event.Name, "signature", event.Sig) continue } - + transferEvent, err := erc20.Unpack(event.Name, log.Data) if err != nil { h.k.Logger(ctx).Error("failed to unpack transfer event", "error", err.Error()) continue } - + if len(transferEvent) == 0 { continue } - + tokens, ok := transferEvent[0].(*big.Int) // safety check and ignore if amount not positive if !ok || tokens == nil || tokens.Sign() != 1 { @@ -1082,19 +1082,19 @@ func (k Keeper) PostTxProcessing( // check that the contract is a registered token pair contractAddr := log.Address - + id := h.k.GetERC20Map(ctx, contractAddr) - + if len(id) == 0 { // no token is registered for the caller contract continue } - + pair, found := h.k.GetTokenPair(ctx, id) if !found { continue } - + // check that conversion for the pair is enabled if !pair.Enabled { // continue to allow transfers for the ERC20 in case the token pair is disabled @@ -1104,7 +1104,7 @@ func (k Keeper) PostTxProcessing( ) continue } - + // ignore as the burning always transfers to the zero address to := common.BytesToAddress(log.Topics[2].Bytes()) if !bytes.Equal(to.Bytes(), types.ModuleAddress.Bytes()) { @@ -1113,10 +1113,10 @@ func (k Keeper) PostTxProcessing( // check that the event is Burn from the ERC20Burnable interface // NOTE: assume that if they are burning the token that has been registered as a pair, they want to mint a Cosmos coin - + // create the corresponding sdk.Coin that is paired with ERC20 coins := sdk.Coins{{Denom: pair.Denom, Amount: sdk.NewIntFromBigInt(tokens)}} - + // Mint the coin only if ERC20 is external switch pair.ContractOwner { case types.OWNER_MODULE: @@ -1126,7 +1126,7 @@ func (k Keeper) PostTxProcessing( default: err = types.ErrUndefinedOwner } - + if err != nil { h.k.Logger(ctx).Debug( "failed to process EVM hook for ER20 -> coin conversion", @@ -1134,11 +1134,11 @@ func (k Keeper) PostTxProcessing( ) continue } - + // Only need last 20 bytes from log.topics from := common.BytesToAddress(log.Topics[1].Bytes()) recipient := sdk.AccAddress(from.Bytes()) - + // transfer the tokens from ModuleAccount to sender address if err := h.k.bankKeeper.SendCoinsFromModuleToAccount(ctx, types.ModuleName, recipient, coins); err != nil { h.k.Logger(ctx).Debug( @@ -1168,7 +1168,7 @@ The EVM module emits events of the relevant transaction fields, as well as the t ### MsgEthereumTx | Type | Attribute Key | Attribute Value | -| ----------- | ------------------ | --------------------- | +|-------------|--------------------|-----------------------| | ethereum_tx | `"amount"` | `{amount}` | | ethereum_tx | `"recipient"` | `{hex_address}` | | ethereum_tx | `"contract"` | `{hex_address}` | @@ -1186,7 +1186,7 @@ Additionally, the EVM module emits an event during `EndBlock` for the filter que ### ABCI | Type | Attribute Key | Attribute Value | -| ----------- | ------------- | -------------------- | +|-------------|---------------|----------------------| | block_bloom | `"bloom"` | `string(bloomBytes)` | ## Parameters @@ -1196,7 +1196,7 @@ The evm module contains the following parameters: ### Params | Key | Type | Default Value | -| -------------- | ----------- | --------------- | +|----------------|-------------|-----------------| | `EVMDenom` | string | `"aISLM"` | | `EnableCreate` | bool | `true` | | `EnableCall` | bool | `true` | @@ -1209,7 +1209,7 @@ The evm denomination parameter defines the token denomination used on the EVM st For example, on Ethereum, the `evm_denom` would be `ETH`. In the case of HAQQ, the default denomination is the **atto ISLM**. In terms of precision, `ISLM` and `ETH` share the same value, -_i.e._ `1 ISLM = 10^18 atto ISLM` and `1 ETH = 10^18 wei`. +*i.e.* `1 ISLM = 10^18 atto ISLM` and `1 ETH = 10^18 wei`. :::note SDK applications that want to import the EVM module as a dependency will need to set their own `evm_denom` (i.e not `"aISLM"`). @@ -1254,7 +1254,7 @@ By default, all block configuration fields but `ConstantinopleBlock`, are enable #### ChainConfig Defaults | Name | Default Value | -| ------------------- | -------------------------------------------------------------------- | +|---------------------|----------------------------------------------------------------------| | HomesteadBlock | 0 | | DAOForkBlock | 0 | | DAOForkSupport | `true` | @@ -1349,7 +1349,7 @@ please refer to [API](../../develop/api/ethereum-json-rpc/methods) #### Queries | Verb | Method | Description | -| ------ | ---------------------------------------------------- | -------------------------------------------------------------------------- | +|--------|------------------------------------------------------|----------------------------------------------------------------------------| | `gRPC` | `ethermint.evm.v1.Query/Account` | Get an Ethereum account | | `gRPC` | `ethermint.evm.v1.Query/CosmosAccount` | Get an Ethereum account's Cosmos Address | | `gRPC` | `ethermint.evm.v1.Query/ValidatorAccount` | Get an Ethereum account's from a validator consensus Address | @@ -1376,6 +1376,6 @@ please refer to [API](../../develop/api/ethereum-json-rpc/methods) #### Transactions | Verb | Method | Description | -| ------ | --------------------------------- | ------------------------------- | +|--------|-----------------------------------|---------------------------------| | `gRPC` | `ethermint.evm.v1.Msg/EthereumTx` | Submit an Ethereum transactions | -| `POST` | `/ethermint/evm/v1/ethereum_tx` | Submit an Ethereum transactions | +| `POST` | `/ethermint/evm/v1/ethereum_tx` | Submit an Ethereum transactions | \ No newline at end of file diff --git a/docs/network/modules/feemarket.md b/docs/network/modules/feemarket.md index dfe1334..367afb4 100644 --- a/docs/network/modules/feemarket.md +++ b/docs/network/modules/feemarket.md @@ -11,7 +11,7 @@ This document specifies the `x/feemarket` module which allows to define a global This module has been designed to support EIP1559 in cosmos-sdk. -The `MempoolFeeDecorator` in `x/auth` module needs to be overwritten to check the `baseFee` along with +The `MempoolFeeDecorator` in `x/auth` module needs to be overwritten to check the `baseFee` along with the `minimal-gas-prices` allowing to implement a global fee mechanism which vary depending on the network activity. For more reference to EIP1559: @@ -53,7 +53,7 @@ feemarket/ ├── migrations │ └── v4 │ ├── types -│ │ └── params.go # Params struct for consensus version 4 of the module +│ │ └── params.go # Params struct for consensus version 4 of the module │ └── migration.go # Migration handler from consensus version 3 to 4 ├── types │ ├── codec.go # Type registration for encoding @@ -92,22 +92,22 @@ With EIP-1559 enabled, the transaction fee is calculated with fee = (baseFee + priorityTip) * gasLimit ``` -where `baseFee` is the fixed-per-block network fee per gas and `priorityTip` is an additional fee per gas +where `baseFee` is the fixed-per-block network fee per gas and `priorityTip` is an additional fee per gas that can be set optionally. Note, that both the base fee and the priority tip are gas prices. To submit a transaction with EIP-1559, the signer needs to specify the `gasFeeCap`, which is the maximum fee per gas -they are willing to pay in total. Optionally, the `priorityTip` can be specified, which covers both +they are willing to pay in total. Optionally, the `priorityTip` can be specified, which covers both the priority fee and the block's network fee per gas (aka: base fee). :::tip -The Cosmos SDK uses a different terminology for `gas` than Ethereum. What is called `gasLimit` on Ethereum -is called `gasWanted` on Cosmos. You might encounter both terminologies on HAQQ since it builds Ethereum +The Cosmos SDK uses a different terminology for `gas` than Ethereum. What is called `gasLimit` on Ethereum +is called `gasWanted` on Cosmos. You might encounter both terminologies on HAQQ since it builds Ethereum on top of the SDK, e.g. when using different wallets like Keplr for Cosmos and Metamask for Ethereum. ::: ### Base Fee The base fee per gas (aka base fee) is a global gas price defined at the consensus level. It is stored as a module -parameter and is adjusted at the end of each block based on the total gas used in the previous block +parameter and is adjusted at the end of each block based on the total gas used in the previous block and gas target (`block gas limit / elasticity multiplier`): - it increases when blocks are above the gas target, @@ -122,9 +122,9 @@ In EIP-1559, the `max_priority_fee_per_gas`, often referred to as `tip`, is an a to the `baseFee` in order to incentivize transaction prioritization. The higher the tip, the more likely the transaction is included in the block. -Until the Cosmos SDK version v0.46, however, there is no notion of transaction prioritization. +Until the Cosmos SDK version v0.46, however, there is no notion of transaction prioritization. Thus, the tip for an EIP-1559 transaction on HAQQ Network should be zero -(`MaxPriorityFeePerGas` JSON-RPC endpoint returns `0`). Have a look at the mempool +(`MaxPriorityFeePerGas` JSON-RPC endpoint returns `0`). Have a look at the mempool docs to read more about how to leverage transaction prioritization. ### Effective Gas price @@ -139,7 +139,7 @@ min(baseFee + gasTipCap, gasFeeCap) ### Local vs. Global Minimum Gas Prices -Minimum gas prices are used to discard spam transactions in the network, by raising the cost of transactions +Minimum gas prices are used to discard spam transactions in the network, by raising the cost of transactions to the point that it is not economically viable for the spammer. This is achieved by defining a minimum gas price for accepting txs in the mempool for both Cosmos and EVM transactions. A transaction is discarded from the mempool if it doesn't provide at least one of the two types of min gas prices: @@ -168,15 +168,17 @@ This is implemented, so that the base fee can't drop to gas prices that would no to be accepted in the mempool, because of a higher `MinGasPrice`. ::: + ## State The `x/feemarket` module keeps in the state variable needed to the fee calculation: Only `BlockGasUsed` in previous block needs to be tracked in state for the next base fee calculation. -| | Description | Key | Value | Store | -| ------------ | --------------------- | ----------- | ------------------ | ----- | -| BlockGasUsed | gas used in the block | `[]byte{1}` | `[]byte{gas_used}` | KV | +| | Description | Key | Value | Store | +| ----------- | ------------------------------ | ---------------| ------------------- | --------- | +| BlockGasUsed | gas used in the block | `[]byte{1}` | `[]byte{gas_used}` | KV | + ## Begin block @@ -259,13 +261,13 @@ The `x/feemarket` module emits the following events: ### BeginBlocker | Type | Attribute Key | Attribute Value | -| ---------- | ------------- | --------------- | +|------------|---------------|-----------------| | fee_market | base_fee | `baseGasPrices` | ### EndBlocker | Type | Attribute Key | Attribute Value | -| --------- | ------------- | --------------- | +|-----------|---------------|-----------------| | block_gas | height | `blockHeight` | | block_gas | amount | `blockGasUsed` | @@ -274,7 +276,7 @@ The `x/feemarket` module emits the following events: The `x/feemarket` module contains the following parameters: | Key | Type | Default Values | Description | -| ------------------------ | ------- | -------------- | ----------------------------------------------------------------------------------------------------------------------- | +|--------------------------|---------|----------------|-------------------------------------------------------------------------------------------------------------------------| | NoBaseFee | bool | false | control the base fee adjustment | | BaseFeeChangeDenominator | uint32 | 8 | bounds the amount the base fee that can change between blocks | | ElasticityMultiplier | uint32 | 2 | bounds the threshold which the base fee will increase or decrease depending on the total gas used in the previous block | @@ -363,7 +365,7 @@ value: "2" #### Queries | Verb | Method | Description | -| ------ | --------------------------------------- | ---------------------- | +|--------|-----------------------------------------|------------------------| | `gRPC` | `ethermint.feemarket.v1.Query/Params` | Get the module params | | `gRPC` | `ethermint.feemarket.v1.Query/BaseFee` | Get the block base fee | | `gRPC` | `ethermint.feemarket.v1.Query/BlockGas` | Get the block gas used | @@ -373,7 +375,7 @@ value: "2" ## AnteHandlers -The `x/feemarket` module provides `AnteDecorator`s that are recursively chained together into a single +The `x/feemarket` module provides `AnteDecorator`s that are recursively chained together into a single [`Antehandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/docs/architecture/adr-010-modular-antehandler.md). These decorators perform basic validity checks on an Ethereum or Cosmos SDK transaction, such that it could be thrown out of the transaction Mempool. @@ -391,10 +393,10 @@ Rejects Cosmos SDK transactions with transaction fees lower than `MinGasPrice * Rejects EVM transactions with transactions fees lower than `MinGasPrice * GasLimit`. - For `LegacyTx` and `AccessListTx`, the `GasPrice * GasLimit` is used. -- For EIP-1559 (_aka._ `DynamicFeeTx`), the `EffectivePrice * GasLimit` is used. +- For EIP-1559 (*aka.* `DynamicFeeTx`), the `EffectivePrice * GasLimit` is used. :::note -For dynamic transactions, if the `feemarket` formula results in a `BaseFee` +For dynamic transactions, if the `feemarket` formula results in a `BaseFee` that lowers `EffectivePrice < MinGasPrices`, the users must increase the `GasTipCap` (priority fee) until `EffectivePrice > MinGasPrices`. Transactions with `MinGasPrices * GasLimit < transaction fee < EffectiveFee` are rejected by the `feemarket` `AnteHandle`. diff --git a/docs/network/modules/ibc.md b/docs/network/modules/ibc.md index 8d1202b..e30e228 100644 --- a/docs/network/modules/ibc.md +++ b/docs/network/modules/ibc.md @@ -16,7 +16,7 @@ If you're not familiar with the [IBC protocol](https://www.ibcprotocol.dev) and ::: This wrapper allows IBC (ICS20) transfers for the registered ERC-20 tokens by automatic conversion between EVM -and native Cosmos representations. It coupled with [x/erc20](erc20.md) and [x/evm](evm.md) modules. +and native Cosmos representations. It coupled with [x/erc20](erc20.md) and [x/evm](evm.md) modules. ## References diff --git a/docs/network/modules/index.md b/docs/network/modules/index.md index c579f01..8b93b14 100644 --- a/docs/network/modules/index.md +++ b/docs/network/modules/index.md @@ -39,4 +39,4 @@ HAQQ Network uses the following Cosmos SDK modules: HAQQ Network uses the following the IBC modules for the SDK: - [interchain-accounts](https://ibc.cosmos.network/main/apps/interchain-accounts/overview.html) -- [transfer](https://ibc.cosmos.network/main/apps/transfer/overview.html) — Basic IBC transfers functionalities +- [transfer](https://ibc.cosmos.network/main/apps/transfer/overview.html) — Basic IBC transfers functionalities \ No newline at end of file diff --git a/docs/network/modules/liquidvesting.md b/docs/network/modules/liquidvesting.md index 1a4d7f3..756a236 100644 --- a/docs/network/modules/liquidvesting.md +++ b/docs/network/modules/liquidvesting.md @@ -18,7 +18,7 @@ The `x/liquidvesting` module offers new capabilities for user-managed vesting wi Upon creation, `aLIQUIDX` tokens are automatically registered on the EVM layer as `ERC20` tokens. Each issuance of these partially liquid tokens generates a new unique partially liquid token. :::note -The user interface and user experience of `x/liquidvesting` module is presented in [Vesting DApp](https://vesting.haqq.network/) you can read more +The user interface and user experience of `x/liquidvesting` module is presented in [Vesting DApp](https://vesting.haqq.network/) you can read more [here](/learn/ecosystem/vesting/#liquid-vesting-functionality). ::: @@ -34,7 +34,8 @@ The user interface and user experience of `x/liquidvesting` module is presented 8. **[Transitions](#transitions)** 9. **[Parameters](#parameters)** 10. **[Clients](#clients)** -11. **[Shedule amount modification](#shedule-amount-modification)** +11. **[Shedule amount modification](#shedule-amount-modification )** + ## References @@ -57,32 +58,32 @@ liquidvesting/ ├── keeper │ ├── denom.go # Creation and management aLIQUIDX denoms │ ├── grpc_query.go # gRPC state query handlers -│ ├── keeper.go # Store keeper that handles the business logic of the module and has access to a specific subtree of the state tree. +│ ├── keeper.go # Store keeper that handles the business logic of the module and has access to a specific subtree of the state tree. │ ├── msg_server.go # Tx handlers │ └── params.go # Parameter getter and setter ├── types -│ ├── codec.go # Type registration for encoding -│ ├── denom.go # Denom types description +│ ├── codec.go # Type registration for encoding +│ ├── denom.go # Denom types description │ ├── errors.go # Module-specific errors -│ ├── genesis.go # Genesis state for the module -│ ├── interfaces.go # The interfaces describing the components of the required modules -│ ├── keys.go # Store keys and utility functions -│ ├── msg.go # Module transaction messages +│ ├── genesis.go # Genesis state for the module +│ ├── interfaces.go # The interfaces describing the components of the required modules +│ ├── keys.go # Store keys and utility functions +│ ├── msg.go # Module transaction messages │ ├── params.go # Module parameters that can be customized with governance parameter change proposals -│ └──schedule.go # Interaction with the vesting schedule -├── genesis.go # ABCI InitGenesis and ExportGenesis functionality -├── handler.go # Message routing -└── module.go # Module setup for the module manager +│ └──schedule.go # Interaction with the vesting schedule +├── genesis.go # ABCI InitGenesis and ExportGenesis functionality +├── handler.go # Message routing +└── module.go # Module setup for the module manager ``` ## Concepts `aLIQUIDX` are semi-liquid tokens registered on both the Cosmos and EVM layers as ERC20 tokens. These tokens are unrestricted, meaning they can be freely bought and sold. + Users with vesting accounts and locked 1,000 ISLM tokens can make their locked ISLM tokens liquid - convert loked aISLM to liquid tokens `aLIQUIDX` . For every token creation, an exact amount of `aISLM` (minimal denomination is 10^18 aISLM equals 1 `ISLM`) is deducted from the user's vested balance corresponding to the number of aLIQUIDX tokens created. Each creation of `aLIQUIDX` tokens generates a new denomination and a new token—such as `aLIQUID1`, `aLIQUID2`, etc. A specific schedule assigned to the module by the creator of the token is associated with each of these denominations. Thus, each `aLIQUIDX` has its own unique schedule which may differ from another `aLIQUIDY` if `X != Y`. After creation, any user can exchange their `aLIQUIDX` tokens back into aISLM according to the schedule of that specific token. The exchange can be for all tokens at once or just a portion. ### Liquidation - If vesting account contains only locked tokens user can use `Liquidate` transaction and next things will happen: 1. Specified amount amount of locked ISLM token will be transfered from a user vesting account to `x/liquidvesting` module account @@ -94,13 +95,12 @@ The minimum creation threshold of 1,000 ISLM tokens is set to reduce the number **The primary purpose of `aLIQUIDX` is to enable p2p market for locked ISLM tokens.** -#### Liquid token +#### Liquid token Liquid token represents arbitrary amount of ISLM token locked in vesting. For each liquidate transaction new unique liquid token will be created. Liquid token has vesting unlock schedule, it derives from original vesting account schedule which liquid token created from. ### Redeem - Once user has any liquid token on its account, it can be redeemed to locked ISLM token. Once user uses `Redeem` transaction next things will happen: 1. Liquid token amount specified for redeem will be burnt @@ -123,9 +123,9 @@ If Users A and B transfer/sell 1,000 aLIQUID1 and 1,000 aLIQUID2 to User C, then The `x/liquidvesting` module keeps the following objects in state: -| State Object | Description | Key | Value | Store | -| ------------ | --------------------- | ------------------------------- | --------------- | ----- | -| `Denom` | Liquid token bytecode | `[]byte{1} + []byte(baseDenom)` | `[]byte{denom}` | KV | +| State Object | Description | Key | Value | Store | +|--------------|-----------------------|---------------------------------|-----------------| ------ | +| `Denom` | Liquid token bytecode | `[]byte{1} + []byte(baseDenom)` | `[]byte{denom}` | KV | #### Denom @@ -161,7 +161,6 @@ Original denom is keeping track of which denom liquid token derives from. In mos Defines start of unlock schedule bound to luqid token. Always match token creation date #### End time - Defines the date when liquid token schedule ends #### LockupPeriods @@ -198,9 +197,9 @@ type GenesisState struct { 1. User submits `MsgLiquidate` 2. Checks if liquidation allowed for account and amount - - tokens on target account are fully vested - - specified amount is more than minimum liquidation amount param - - specified amount is less or equal to locked token amount + - tokens on target account are fully vested + - specified amount is more than minimum liquidation amount param + - specified amount is less or equal to locked token amount 3. Calculate new schedules for account and for liquid token 4. Update target account with new schedule 5. Escrow locked token to module account @@ -213,8 +212,8 @@ type GenesisState struct { 1. User submits `MsgRedeem` 2. Checks if redeem possible - - Specified liquid token does exist - - Check user's account has sufficient amount of liquid token to redeem + - Specified liquid token does exist + - Check user's account has sufficient amount of liquid token to redeem 3. Burn specified liquid token amount 4. Subtract burnt liquid token amount from liquid token schedule 5. Transfer ISLM to target account @@ -269,9 +268,9 @@ Message stateless validation fails if: The `x/liquidvesting` module contains the following parameters: -| Key | Type | Default Value | -| -------------------------- | ----------- | ------------- | -| `MinimumLiquidationAmount` | sdkmath.Int | `1000*10^18` | +| Key | Type | Default Value | +|----------------------------|-------------|---------------------| +| `MinimumLiquidationAmount` | sdkmath.Int | `1000*10^18` | ### Minimum liquidation amount @@ -281,7 +280,7 @@ The `MinimumLiquidationAmount` parameter defines minimum amount of locked token ### CLI -Find below a list of `haqqd` commands added with the `x/liquidvesting` module. You can obtain the full list by using the `haqqd -h` command. A CLI command can look like this: +Find below a list of `haqqd` commands added with the `x/liquidvesting` module. You can obtain the full list by using the `haqqd -h` command. A CLI command can look like this: ```bash haqqd query liquidvesting params @@ -290,14 +289,14 @@ haqqd query liquidvesting params #### Queries | Command | Subcommand | Description | -| ----------------------- | ---------- | ------------------------------ | +|-------------------------|------------|--------------------------------| | `query` `liquidvesting` | `denom` | Get liquid token | | `query` `liquidvesting` | `denoms` | Get all existing liquid tokens | #### Transactions | Command | Subcommand | Description | -| -------------------- | ----------- | ------------------------------------------------- | +|----------------------|-------------|---------------------------------------------------| | `tx` `liquidvesting` | `liquidate` | Liquidates arbitrary amount of locked ISLM tokens | | `tx` `liquidvesting` | `redeem` | Redeem liquid token to ISLM | @@ -306,7 +305,7 @@ haqqd query liquidvesting params #### Queries | Verb | Method | Description | -| ------ | ------------------------------------ | ------------------------------ | +| ------ |--------------------------------------| ------------------------------ | | `gRPC` | `haqq.liquidvesting.v1.Query/Denom` | Get liquid token | | `gRPC` | `haqq.liquidvesting.v1.Query/Denoms` | Get all existing liquid tokens | | `GET` | `/haqq/liquidvesting/v1/denom` | Get liquid token | @@ -315,21 +314,18 @@ haqqd query liquidvesting params #### Transactions | Verb | Method | Description | -| ------ | ------------------------------------- | ------------------------------------------------- | +|--------|---------------------------------------| ------------------------------------------------- | | `gRPC` | `haqq.liquidvesting.v1.Msg/Liquidate` | Liquidates arbitrary amount of locked ISLM tokens | | `gRPC` | `haqq.liquidvesting.v1.Msg/Redeem` | Redeem liquid token to ISLM | | `POST` | `/haqq/liquidvesting/v1/tx/liquidate` | Liquidates arbitrary amount of locked ISLM tokens | | `POST` | `/haqq/liquidvesting/v1/tx/redeem` | Redeem liquid token to ISLM | -## Shedule amount modification +## Shedule amount modification This section describes in details how `x/liquidvesting` module handles operation with schedule mutation. Examples are provided. - ### Liquidation - -For example we have an account this account has 3 days of vesting so each day represented as a period and has amount which be unlocked once period is passed. +For example we have an account this account has 3 days of vesting so each day represented as a period and has amount which be unlocked once period is passed. Let's imagine every period has different amount 10,20 and 30 respectively - ``` 10,20,30 ``` @@ -337,34 +333,28 @@ Let's imagine every period has different amount 10,20 and 30 respectively So total amount locked in this schedule is 60. We want to liquidate 20 tokens from this schedule. We will subtract portion of this amount from every period proportionally to total sum. For the first period : - - 10 - first period amount - 20 - liquidation amount - 60 - total amount -Formula is 10 - 10\*20/60 -> 10 - 200/60 -> 10 - 3 = 7 +Formula is 10 - 10*20/60 -> 10 - 200/60 -> 10 - 3 = 7 Important note in above calculations. We have step 200/60 and this division has a remainder. We will track this remainder but won't use it to calculate new period. If we perform the same operation for every period we will get: - ``` 7,14,20 ``` - The sum of new periods is 41 but expected sum is 40 because we were subtracting 20 from periods with sum of 60. So calculate diff between sum of new periods and expected sum and it is 1. Now having the diff we subtract it from last period. So we get: - ``` 7,14,19 ``` - These are our new periods. These new periods will be the new schedule of vesting account targeted by liquidation. Now we need to know periods for newly created liquid token. and this is simply a diff between original periods and decreased periods - ``` 10,20,30 - original amount in periods 7,14,19 - decreased amount in periods 3,6,11 - liquid token amount in periods -``` +``` \ No newline at end of file diff --git a/docs/network/modules/vesting.md b/docs/network/modules/vesting.md index 7358d6c..e571181 100644 --- a/docs/network/modules/vesting.md +++ b/docs/network/modules/vesting.md @@ -9,11 +9,11 @@ title: x/vesting This document specifies the internal `x/vesting` module of the HAQQ Network. -The `x/vesting` module introduces the `ClawbackVestingAccount`, a new vesting account type that implements +The `x/vesting` module introduces the `ClawbackVestingAccount`, a new vesting account type that implements the Cosmos SDK [`VestingAccount`](https://docs.cosmos.network/main/modules/auth/vesting#vesting-account-types) interface. This account is used to allocate tokens that are subject to vesting, lockup, and clawback. -The `ClawbackVestingAccount` allows any two parties to agree on a future rewarding schedule, where tokens are granted +The `ClawbackVestingAccount` allows any two parties to agree on a future rewarding schedule, where tokens are granted permissions over time. The parties can use this account to enforce legal contracts or commit to mutual long-term interests. In this commitment, vesting is the mechanism for gradually earning permission to transfer and delegate allocated tokens. @@ -22,7 +22,7 @@ transactions from the account. Both vesting and lockup are defined in schedules At any time, the funder of a `ClawbackVestingAccount` can perform a clawback to retrieve unvested tokens. The circumstances under which a clawback should be performed can be agreed upon in a contract (e.g. smart contract). -For HAQQ, the `ClawbackVestingAccount` is used to allocate tokens to users via airdrops, core team members and advisors to incentivize +For HAQQ, the `ClawbackVestingAccount` is used to allocate tokens to users via airdrops, core team members and advisors to incentivize long-term participation in the project. ## Contents @@ -61,7 +61,7 @@ vesting/ │ ├── keeper.go # Store keeper that handles the business logic of the module and has access to a specific subtree of the state tree. │ └── msg_server.go # Tx handlers ├── types -│ ├── clawback_vesting_account.go # Utility functions for the ClawbackVestingAccount struct +│ ├── clawback_vesting_account.go # Utility functions for the ClawbackVestingAccount struct │ ├── codec.go # Type registration for encoding │ ├── errors.go # Module-specific errors │ ├── events.go # Events exposed to the CometBFT PubSub/Websocket @@ -78,8 +78,8 @@ vesting/ ### Vesting -Vesting describes the process of converting `unvested` into `vested` tokens without transferring the ownership -of those tokens. In an unvested state, tokens cannot be transferred to other accounts, delegated to validators, +Vesting describes the process of converting `unvested` into `vested` tokens without transferring the ownership +of those tokens. In an unvested state, tokens cannot be transferred to other accounts, delegated to validators, or used for governance. A vesting schedule describes the amount and time at which tokens are vested. The duration until which the first tokens are vested is called the `cliff`. @@ -94,11 +94,11 @@ it is possible to delegate them to validators, but not transfer them to other ac The following table summarizes the actions that are allowed for tokens that are subject to the combination of vesting and lockup: | Token Status | Transfer | Delegate | Vote | Eth Txs that spend ISLM\*\* | Eth Txs that don't spend ISLM (amount=0)\*\* | -| ----------------------- | :------: | :------: | :--: | :-------------------------: | :------------------------------------------: | -| `locked` & `unvested` | ❌ | ❌ | ❌ | ❌ | ✅ | -| `locked` & `vested` | ❌ | ✅ | ✅ | ❌ | ✅ | -| `unlocked` & `unvested` | ❌ | ❌ | ❌ | ❌ | ✅ | -| `unlocked` & `vested`\* | ✅ | ✅ | ✅ | ✅ | ✅ | +|-------------------------|:--------:|:--------:|:----:|:---------------------------:|:--------------------------------------------:| +| `locked` & `unvested` | ❌ | ❌ | ❌ | ❌ | ✅ | +| `locked` & `vested` | ❌ | ✅ | ✅ | ❌ | ✅ | +| `unlocked` & `unvested` | ❌ | ❌ | ❌ | ❌ | ✅ | +| `unlocked` & `vested`\* | ✅ | ✅ | ✅ | ✅ | ✅ | \* Staking rewards are unlocked and vested @@ -106,12 +106,12 @@ The following table summarizes the actions that are allowed for tokens that are ### Schedules -Vesting and lockup schedules specify the amount and time at which tokens are vested or unlocked. They are defined +Vesting and lockup schedules specify the amount and time at which tokens are vested or unlocked. They are defined as [`periods`](https://docs.cosmos.network/main/modules/auth/vesting#period) where each period has its own length and amount. A typical vesting schedule for instance would be defined starting with a one-year period to represent the vesting cliff, followed by several monthly vesting periods until the total allocated vesting amount is vested. -Vesting or lockup schedules can be easily created with Agoric’s +Vesting or lockup schedules can be easily created with Agoric’s [`vestcalc`](https://github.com/agoric-labs/cosmos-sdk/tree/Agoric/x/auth/vesting/cmd/vestcalc) tool. E.g. to calculate a four-year vesting schedule with a one year cliff, starting in January 2022, you can run vestcalc with: @@ -138,7 +138,7 @@ Accounts are exposed externally as an interface and stored internally as a clawb An instance that implements the [Vesting Account](https://docs.cosmos.network/main/modules/auth/vesting#vesting-account-types) interface. -It provides an account that can hold contributions subject to lockup, or vesting which is subject to clawback +It provides an account that can hold contributions subject to lockup, or vesting which is subject to clawback of unvested tokens, or a combination (tokens vest, but are still locked). ```go @@ -179,12 +179,12 @@ Defines the vesting schedule relative to the start time. ### Genesis State -The `x/vesting` module allows the definition of `ClawbackVestingAccounts` at genesis. In this case, the account balance +The `x/vesting` module allows the definition of `ClawbackVestingAccounts` at genesis. In this case, the account balance must be logged in the SDK `bank` module balances or automatically adjusted through the `add-genesis-account` CLI command. ## State Transitions -The `x/vesting` module allows for state transitions that create and update a clawback vesting account +The `x/vesting` module allows for state transitions that create and update a clawback vesting account with `CreateClawbackVestingAccount` or perform a clawback of unvested funds with `Clawback`. ### Create Clawback Vesting Account @@ -194,27 +194,28 @@ Additionally, new grants can be added to existing clawback vesting accounts with 1. Funder submits a `MsgCreateClawbackVestingAccount` through one of the clients. 2. Check if - 1. the vesting account address is not blocked - 2. there is at least one vesting or lockup schedule provided. - If one of them is absent, default to instant vesting or unlock schedule. - 3. lockup and vesting total amounts are equal + 1. the vesting account address is not blocked + 2. there is at least one vesting or lockup schedule provided. + If one of them is absent, default to instant vesting or unlock schedule. + 3. lockup and vesting total amounts are equal 3. Create or update a clawback vesting account and send coins from the funder to the vesting account - 1. if the clawback vesting account already exists and `--merge` is set to true, - add a grant to the existing total vesting amount and update the vesting and lockup schedules. - 2. else create a new clawback vesting account + 1. if the clawback vesting account already exists and `--merge` is set to true, + add a grant to the existing total vesting amount and update the vesting and lockup schedules. + 2. else create a new clawback vesting account ### Convert Into Vesting Account + ### Clawback The funding address is the only address that can perform the clawback. 1. Funder submits a `MsgClawback` through one of the clients. 2. Check if - 1. a destination address is given and default to funder address if not - 2. the destination address is not blocked - 3. the account exists and is a clawback vesting account - 4. account funder is same as in msg + 1. a destination address is given and default to funder address if not + 2. the destination address is not blocked + 3. the account exists and is a clawback vesting account + 4. account funder is same as in msg 3. Transfer unvested tokens from the clawback vesting account to the destination address, update the lockup schedule and remove future vesting events. @@ -224,9 +225,9 @@ The funding address of an existing clawback vesting account can be updated only 1. Funder submits a `MsgUpdateVestingFunder` through one of the clients. 2. Check if - 1. the new funder address is not blocked - 2. the vesting account exists and is a clawback vesting account - 3. account funder is same as in msg + 1. the new funder address is not blocked + 2. the vesting account exists and is a clawback vesting account + 3. account funder is same as in msg 3. Update the vesting account funder with the new funder address. ### Convert Vesting Account @@ -235,8 +236,8 @@ Once all tokens are vested, the vesting account can be converted to an `ETHAccou 1. Owner of vesting account submits a `MsgConvertVestingAccount` through one of the clients. 2. Check if - 1. the vesting account exists and is a clawback vesting account - 2. the vesting account's vesting and locked schedules have concluded + 1. the vesting account exists and is a clawback vesting account + 2. the vesting account's vesting and locked schedules have concluded 3. Convert the vesting account to an `EthAccount` ## Transactions @@ -271,8 +272,8 @@ The msg content stateless validation fails if: - `FromAddress` or `ToAddress` are invalid - `LockupPeriods` and `VestingPeriods` - - include a period with a non-positive length or amount - - do not describe the same total amount + - include a period with a non-positive length or amount + - do not describe the same total amount ### `ConvertIntoVestingAccount` @@ -307,8 +308,8 @@ The msg content stateless validation fails if: - `FromAddress` or `ToAddress` are invalid - `LockupPeriods` and `VestingPeriods` - - include a period with a non-positive length or amount - - do not describe the same total amount + - include a period with a non-positive length or amount + - do not describe the same total amount ### `Clawback` @@ -360,14 +361,15 @@ The msg content stateless validation fails if: - `VestingAddress` is invalid + ## AnteHandlers -The `x/vesting` module provides `AnteDecorator`s that are recursively chained together into a single +The `x/vesting` module provides `AnteDecorator`s that are recursively chained together into a single [`Antehandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/docs/architecture/adr-010-modular-antehandler.md). -These decorators perform basic validity checks on an Ethereum or SDK transaction, such that it could be thrown +These decorators perform basic validity checks on an Ethereum or SDK transaction, such that it could be thrown out of the transaction Mempool. -Note that the `AnteHandler` is called on both `CheckTx` and `DeliverTx`, as CometBFT proposers presently have +Note that the `AnteHandler` is called on both `CheckTx` and `DeliverTx`, as CometBFT proposers presently have the ability to include in their proposed block transactions that fail `CheckTx`. ### Decorators @@ -386,7 +388,7 @@ Validates if a transaction contains a staking delegation of unvested coins. This #### `EthVestingTransactionDecorator` Validates if a clawback vesting account is permitted to perform Ethereum transactions, based on if it has its vesting -schedule has surpassed the vesting cliff and first lockup period. Also, validates if the account has sufficient +schedule has surpassed the vesting cliff and first lockup period. Also, validates if the account has sufficient unlocked tokens to execute the transaction. This AnteHandler decorator will fail if: - the message is not a `MsgEthereumTx` @@ -403,7 +405,7 @@ The `x/vesting` module emits the following events: ### Create Clawback Vesting Account | Type | Attibute Key | Attibute Value | -| --------------------------------- | -------------- | --------------------------------- | +|-----------------------------------|----------------|-----------------------------------| | `create_clawback_vesting_account` | `"from"` | `{msg.FromAddress}` | | `create_clawback_vesting_account` | `"coins"` | `{vestingCoins.String()}` | | `create_clawback_vesting_account` | `"start_time"` | `{msg.StartTime.String()}` | @@ -413,7 +415,7 @@ The `x/vesting` module emits the following events: ### Clawback | Type | Attibute Key | Attibute Value | -| ---------- | --------------- | ---------------------- | +|------------|-----------------|------------------------| | `clawback` | `"funder"` | `{msg.FromAddress}` | | `clawback` | `"account"` | `{msg.AccountAddress}` | | `clawback` | `"destination"` | `{msg.DestAddress}` | @@ -421,7 +423,7 @@ The `x/vesting` module emits the following events: ### Update Clawback Vesting Account Funder | Type | Attibute Key | Attibute Value | -| ----------------------- | -------------- | ------------------------ | +|-------------------------|----------------|--------------------------| | `update_vesting_funder` | `"funder"` | `{msg.FromAddress}` | | `update_vesting_funder` | `"account"` | `{msg.VestingAddress}` | | `update_vesting_funder` | `"new_funder"` | `{msg.NewFunderAddress}` | @@ -431,7 +433,7 @@ The `x/vesting` module emits the following events: A user can query the HAQQ `x/vesting` module using the CLI, gRPC, or REST. :::note -Due to namespace conflict with native Evmos vesting module HAQQ `x/vesting` module has been implemented using +Due to namespace conflict with native Evmos vesting module HAQQ `x/vesting` module has been implemented using `haqqvesting` namespace instead. ::: @@ -450,7 +452,7 @@ Must provide a lockup periods file (`--lockup`), a vesting periods file (`--vest If both files are given, they must describe schedules for the same total amount. If one file is omitted, it will default to a schedule that immediately unlocks or vests the entire amount. The described amount of coins -will be transferred from the `--from` address to the vesting account. Unvested coins may be "clawed back" +will be transferred from the `--from` address to the vesting account. Unvested coins may be "clawed back" by the funder with the clawback command. Coins may not be transferred out of the account if they are locked or unvested. Only vested coins may be staked. For an example of how to set this see [this link](https://github.com/evmos/evmos/pull/303). @@ -480,7 +482,7 @@ Allows users to create a new vesting account funded with an allocation of tokens Must provide a lockup periods file (`--lockup`), a vesting periods file (`--vesting`), or both. If both files are given, they must describe schedules for the same total amount. If one file is omitted, -it will default to a schedule that immediately unlocks or vests the entire amount. The described amount of coins +it will default to a schedule that immediately unlocks or vests the entire amount. The described amount of coins will be transferred from the `--from` address to the vesting account. Unvested coins may be "clawed back" by the funder with the clawback command. Coins may not be transferred out of the account if they are locked or unvested. Only vested coins may be staked. For an example of how to set this see [this link](https://github.com/evmos/evmos/pull/303). @@ -546,14 +548,14 @@ haqqd tx haqqvesting convert VESTING_ACCOUNT_ADDRESS [flags] #### Queries | Verb | Method | Description | -| ------ | ------------------------------------- | -------------------------------------- | +|--------|---------------------------------------|----------------------------------------| | `gRPC` | `haqq.vesting.v1.Query/Balances` | Gets locked, unvested and vested coins | | `GET` | `/haqq/vesting/v1/balances/{address}` | Gets locked, unvested and vested coins | #### Transactions | Verb | Method | Description | -| ------ | ----------------------------------------------------- | ------------------------------------------------------ | +|--------|-------------------------------------------------------|--------------------------------------------------------| | `gRPC` | `haqq.vesting.v1.Msg/CreateClawbackVestingAccount` | Creates clawback vesting account | | `gRPC` | `haqq.vesting.v1.Msg/ConvertIntoVestingAccount` | Convert existing account into clawback vesting account | | `gRPC` | `haqq.vesting.v1.Msg/Clawback` | Performs clawback | diff --git a/docs/network/run-a-ibc-relayer.md b/docs/network/run-a-ibc-relayer.md index 749d78c..374c96d 100644 --- a/docs/network/run-a-ibc-relayer.md +++ b/docs/network/run-a-ibc-relayer.md @@ -11,6 +11,7 @@ An IBC (Inter-Blockchain Communication) Relayer is a crucial component in the Co Hermes is an open-source Rust implementation of a relayer for the Inter-Blockchain Communication Protocol (IBC). Hermes is widely used in production by relayer operators. It offers excellent logging and debugging options, but compared to the Go relayer, it may require more detailed knowledge of IBC to use properly. It is the one we recommend you use. + ## About Hermes An IBC relayer is an off-chain process responsible for relaying IBC datagrams between any two chains. It does so by scanning chain states, building transactions based on these states, and submitting the transactions to the chains involved in the network. @@ -32,50 +33,41 @@ We recommend start from the basic instructions from Hermes - [here.](https://her For instructions on how to install Rust on your machine, please follow the official [Rust Installation Notes.](https://www.rust-lang.org/tools/install). The provided instructions will install the entire Rust toolchain, including rustc, cargo, and rustup, required to build the project. Hermes requires Rust 1.76.0. - ```bash rustc --version ``` -Also check `cargo` - +Also check `cargo` ```bash cargo version ``` -### Install - +### Install ```bash cargo install ibc-relayer-cli --bin hermes --locked ``` If you have not installed Rust and Cargo via rustup.rs, you may need to add the $HOME/.cargo/bin directory to your PATH environment variable. For most shells, this can be done by adding the following line to your .bashrc or .zshrc configuration file: - ```bash export PATH="$HOME/.cargo/bin:$PATH" ``` - ### Check - ```bash hermes version ``` +Congratulations you've installed Hermes. -Congratulations you've installed Hermes. - -## Docker +## Docker We have prepared a Docker file for building Hermes, the IBC relayer, to facilitate its setup and deployment. You can obtain the Docker file and the full Docker Compose project using the links below: - -- [Hermes Docker File](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/hermes.Dockerfile) -- [Hermes Docker Compose File](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/docker-compose.yml) +* [Hermes Docker File](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/hermes.Dockerfile) +* [Hermes Docker Compose File](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/docker-compose.yml) We also recommend using Docker Compose for managing your Hermes deployment. The full repository containing the Docker Compose project can be found here: [HAQQ Hermes Docker Project](https://github.com/haqq-network/hermes-docker) ## Config - -You can and should use the official documentation to configure it. The configuration from the example can be used as an [example.](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/config.yaml) -The key feature is `address_type derivation = 'ethermint'` and `ethermint.crypto.v1.ethsecp256k1.PubKey'` which need to be specified in the network settings, as in the example below. +You can and should use the official documentation to configure it. The configuration from the example can be used as an [example.](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/config.yaml) +The key feature is `address_type derivation = 'ethermint'` and `ethermint.crypto.v1.ethsecp256k1.PubKey'` which need to be specified in the network settings, as in the example below. ```yaml [[chains]] @@ -126,7 +118,7 @@ derivation = 'ethermint' proto_type = { pk_type = '/ethermint.crypto.v1.ethsecp256k1.PubKey' } ``` -You can see the settings of other networks in the [GitHub example](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/config.yaml) or in the documentation of other networks. + You can see the settings of other networks in the [GitHub example](https://raw.githubusercontent.com/haqq-network/hermes-docker/master/config.yaml) or in the documentation of other networks. ## Keys setup @@ -135,16 +127,17 @@ Pay special attention to the HD-Path for Networks haqq_11235-1 and kava_2222-10. ```bash hermes keys add --chain haqq_11235-1 --mnemonic-file /root/.hermes/.mnemonic --hd-path "m/44'/60'/0'/0/0" hermes keys add --chain kava_2222-10 --mnemonic-file /root/.hermes/.mnemonic --hd-path "m/44'/459'/0'/0/0" -hermes keys add --chain stride-1 --mnemonic-file /root/.hermes/.mnemonic -hermes keys add --chain axelar-dojo-1 --mnemonic-file /root/.hermes/.mnemonic -hermes keys add --chain osmosis-1 --mnemonic-file /root/.hermes/.mnemonic -hermes keys add --chain noble-1 --mnemonic-file /root/.hermes/.mnemonic +hermes keys add --chain stride-1 --mnemonic-file /root/.hermes/.mnemonic +hermes keys add --chain axelar-dojo-1 --mnemonic-file /root/.hermes/.mnemonic +hermes keys add --chain osmosis-1 --mnemonic-file /root/.hermes/.mnemonic +hermes keys add --chain noble-1 --mnemonic-file /root/.hermes/.mnemonic hermes keys add --chain cosmoshub-4 --mnemonic-file /root/.hermes/.mnemonic ``` -## Commands +## Commands + +Note: you can get channels from the configuration or from the documentation [here.](../../develop/ibc/) -Note: you can get channels from the configuration or from the documentation [here.](../../develop/ibc/) Clear the channel with the following: @@ -153,7 +146,6 @@ hermes clear packets --chain haqq_11235-1 --channel channel-7 --port transfer ``` Get the channels with the following: - ```bash hermes query channels --chain haqq_11235-1 -``` +``` \ No newline at end of file diff --git a/docs/network/run-a-validator.md b/docs/network/run-a-validator.md index 2c62636..a1688c2 100644 --- a/docs/network/run-a-validator.md +++ b/docs/network/run-a-validator.md @@ -8,7 +8,7 @@ Learn how to setup and run a validator node :::tip Pre-requisite Readings -- [Run a Node](run-node/index.md) +- [Run a Node](run-node/mainnet.md) - [Validator Overview](index.mdx) - [Validator Security](configuration/security.md) @@ -46,6 +46,7 @@ haqqd tx staking create-validator \ --node https://rpc.tm.testedge2.haqq.network:443 ``` + ### To create your validator on **Mainnet** ```sh @@ -98,7 +99,7 @@ The `commission-rate` value must adhere to the following invariants: - Must not exceed the validator's `commission-max-change-rate` which is maximum % point change rate **per day**. In other words, a validator can only change its commission once per day and within `commission-max-change-rate` bounds. - ::: +::: ## View Validator Description @@ -223,7 +224,7 @@ We are currently using version `1.7.8` on Mainnet. This error can also occur if you run the validator from a period when blocks were produced on a different version of the binary. -From this point, we recommend starting the node using statesync. More information you can find [here](run-node/index.md) +From this point, we recommend starting the node using statesync. More information you can find [here](run-node/mainnet.md) ### Unknown problems diff --git a/docs/network/run-node/mainnet-from-archive.md b/docs/network/run-node/mainnet-from-archive.md index 83f3d4f..9ae0ab9 100644 --- a/docs/network/run-node/mainnet-from-archive.md +++ b/docs/network/run-node/mainnet-from-archive.md @@ -2,7 +2,7 @@ sidebar_position: 2 --- -# Mainnet Full Node from Archive +# Mainnet Full Node from Archive ## Overview @@ -13,31 +13,29 @@ Sources of all scripts are here [`github`](https://github.com/haqq-network/mainn _*Battle tested on [Ubuntu LTS 22.04](https://spinupwp.com/doc/what-does-lts-mean-ubuntu/#:~:text=The%20abbreviation%20stands%20for%20Long,extended%20period%20over%20regular%20releases)*_ -## Setup +## Setup ### APT - ```sh sudo apt update && sudo apt upgrade -y sudo apt install curl git make gcc liblz4-tool build-essential jq -y sudo apt install snapd -y && sudo snap install lz4 -y ``` -Script repository +Script repository ```sh git clone https://github.com/haqq-network/mainnet ``` -### Go +### Go Need version 1.21 https://go.dev/doc/install Don't forget: - ```sh -./mainnet/install_go.sh +./mainnet/install_go.sh export PATH=$PATH:/usr/local/go/bin ``` @@ -47,20 +45,18 @@ Checking go version ``` -### Install latest HAQQ node +### Install latest HAQQ node ```sh cd $HOME git clone -b v1.7.8 https://github.com/haqq-network/haqq cd haqq && make install ``` - -Checking +Checking ```sh haqqd -v ``` - haqqd version "1.7.8" 3058d8f0485747aa5eacb352330d6bc1a867a838 ### Сonfig HAQQ node @@ -79,28 +75,24 @@ curl -OL https://raw.githubusercontent.com/haqq-network/mainnet/master/addrbook. mv addrbook.json $HOME/.haqqd/config/addrbook.json ``` + ## Config for full node ```sh cd .haqqd/config ``` - ## app.toml - ``` pruning = "nothing" ``` - ## config.toml - ``` [statesync] enable = false ``` -## Download and install archive - -go to - https://storage.googleapis.com/haqq-archive-snapshots/ -and see the latest available snapshots. We take snapshots every 2 days. +## Download and install archive +go to - https://storage.googleapis.com/haqq-archive-snapshots/ -and see the latest available snapshots. We take snapshots every 2 days. ``` @@ -115,32 +107,32 @@ go to - https://storage.googleapis.com/haqq-archive-snapshots/ -and see the late ``` -haqqd-2024-05-27-02-00-01.lz4 - last one from the example, and link to archive will be https://storage.googleapis.com/haqq-archive-snapshots/haqqd-2024-05-27-02-00-01.lz4 +haqqd-2024-05-27-02-00-01.lz4 - last one from the example, and link to archive will be https://storage.googleapis.com/haqq-archive-snapshots/haqqd-2024-05-27-02-00-01.lz4 + ``` wget -O haqqd-2023-07-13-02-00-01.lz4 https://storage.googleapis.com/haqq-archive-snapshots/haqqd-2024-05-27-02-00-01.lz4 haqqd tendermint unsafe-reset-all --home $HOME/.haqqd --keep-addr-book -lz4 -c -d haqqd-2023-07-13-02-00-01.lz4 | tar -x -C $HOME/.haqqd +lz4 -c -d haqqd-2023-07-13-02-00-01.lz4 | tar -x -C $HOME/.haqqd ``` -### Checks +### Checks ```sh haqqd start ``` + ## Service setup 1. Install cosmovisor bin - ```sh go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@latest ``` 2. Create cosmovisor folders - ```sh mkdir $HOME/.haqqd/cosmovisor && \ mkdir -p $HOME/.haqqd/cosmovisor/genesis/bin && \ @@ -148,13 +140,11 @@ mkdir -p $HOME/.haqqd/cosmovisor/upgrades ``` 3. Copy node binary into Cosmovisor folder - ```sh cp /root/go/bin/haqqd $HOME/.haqqd/cosmovisor/genesis/bin ``` 4. Create haqqd cosmovisor service - ```sh nano /etc/systemd/system/haqqd.service ``` @@ -188,12 +178,12 @@ systemctl start haqqd.service ``` 6. Check logs - ```sh journalctl -fu haqqd ``` + ## Helpful links -- https://quicksync.io/networks/osmosis.html +- https://quicksync.io/networks/osmosis.html - https://polkachu.com/tendermint_snapshots/haqq diff --git a/docs/network/run-node/mainnet-from-snapshot.md b/docs/network/run-node/mainnet-from-snapshot.md index a453b73..34af659 100644 --- a/docs/network/run-node/mainnet-from-snapshot.md +++ b/docs/network/run-node/mainnet-from-snapshot.md @@ -2,7 +2,7 @@ sidebar_position: 1 --- -# Mainnet from Snapshot +# Mainnet from Snapshot ## Overview @@ -80,7 +80,6 @@ After that need to download a haqq node snapshot from one of our providers: - [Publicnode](https://publicnode.com/snapshots) Example download command via aria2(via polkachu): - ```ruby aria2c https://snapshots.polkachu.com/snapshots/haqq/haqq_12345540.tar.lz4 ``` @@ -88,19 +87,15 @@ aria2c https://snapshots.polkachu.com/snapshots/haqq/haqq_12345540.tar.lz4 And decompress to HAQQD_DIR and start node(archive name is just for example use actual name from provider) Example for Polkachu format: - ```sh lz4 -c -d haqq_12345540.tar.lz4 | tar -x -C $HAQQD_DIR ``` - Example for Publicnode format: - ```sh lz4 -c -d haqq-pruned-12345957-12345967.tar.lz4 | tar -x -C $HAQQD_DIR ``` After decompress you can try to start the node: - ```sh haqqd start ``` diff --git a/docs/network/run-node/testnet.md b/docs/network/run-node/testnet.md index 2b8792f..7799801 100644 --- a/docs/network/run-node/testnet.md +++ b/docs/network/run-node/testnet.md @@ -30,12 +30,12 @@ https://github.com/haqq-network/haqq/releases/tag/v1.7.5 - `Go 1.21+` Easy Go compiler installation: - ```sh bash <(curl -s https://raw.githubusercontent.com/haqq-network/mainnet/master/install_go.sh) && \ source $HOME/.bash_profile ``` + Build from source: ```sh diff --git a/docs/user-guides/connect-your-wallet/index.mdx b/docs/user-guides/connect-your-wallet/index.mdx index 3b07b82..84fccb1 100644 --- a/docs/user-guides/connect-your-wallet/index.mdx +++ b/docs/user-guides/connect-your-wallet/index.mdx @@ -8,11 +8,11 @@ slug: '/wallet' HAQQ Network supports both Cosmos and ERC-20 coins. There are several wallets that work with the network. Some of these wallets support Ledger connectivity. Consult the table below for more information. We recommend official HAQQ Wallet, Metamask and Keplr wallets. These three wallets also work with the Ledger. For more information about Ledger, proceed to [here](./connect-your-wallet/ledger). -| Wallet | Supported | Ledger | Detail | -| ------------------------------------------ | --------- | ------ | ----------------------------------------------------------------------------------------- | -| [HAQQ Wallet](https://haqq.network/wallet) | ✅ | ✅ | Mobile iOS & Android. Our own mobile wallet | -| [Metamask](https://metamask.io/) | ✅ | ✅ | Mobile & Browsers. Supports ERC-20 tokens, and registered Cosmos coins on EVM layer | -| [Keplr](https://www.keplr.app/) | ✅ | ✅ | Mobile & Browsers. Supports Cosmos coins, and registered ERC20 on the Cosmos layer ERC-20 | -| [Ledger](https://www.ledger.com/) | ✅ | ✅ | Desktop & Mobile. Supported on Metamask, Keplr, and CLI | -| [Leap](https://www.leapwallet.io) | ✅ | ✅ | Desktop browsers. Supports Cosmos coins, and registered ERC20 on the Cosmos layer ERC-20 | -| [Haqabi Wallet](https://haqabi.com/) | ✅ | ❌ | Mobile iOS & Android. Support Haqq network by default without any additional settings | +| Wallet | Supported | Ledger | Detail | +|--------------------------------------------|-----------|--------|-------------------------------------------------------------------------| +| [HAQQ Wallet](https://haqq.network/wallet) | ✅ | ✅ | Mobile iOS & Android. Our own mobile wallet | +| [Metamask](https://metamask.io/) | ✅ | ✅ | Mobile & Browsers. Supports ERC-20 tokens, and registered Cosmos coins on EVM layer | +| [Keplr](https://www.keplr.app/) | ✅ | ✅ | Mobile & Browsers. Supports Cosmos coins, and registered ERC20 on the Cosmos layer ERC-20 | +| [Ledger](https://www.ledger.com/) | ✅ | ✅ | Desktop & Mobile. Supported on Metamask, Keplr, and CLI | +| [Leap](https://www.leapwallet.io) | ✅ | ✅ | Desktop browsers. Supports Cosmos coins, and registered ERC20 on the Cosmos layer ERC-20 | +| [Haqabi Wallet](https://haqabi.com/) | ✅ | ❌ | Mobile iOS & Android. Support Haqq network by default without any additional settings | diff --git a/docs/user-guides/crosschainswap.mdx b/docs/user-guides/crosschainswap.mdx index 768b7a7..24b121e 100644 --- a/docs/user-guides/crosschainswap.mdx +++ b/docs/user-guides/crosschainswap.mdx @@ -23,7 +23,7 @@ Skip products, such as the Skip API, are used by various projects, including Nob ## Preparation :::danger -Recipient addresses MUST be your personal wallets, not the addresses of exchanges! +Recipient addresses MUST be your personal wallets, not the addresses of exchanges! ::: 1. [Install Keplr](/user-guides/connect-your-wallet/Keplr/) and add both the Noble and HAQQ networks. @@ -32,7 +32,6 @@ Recipient addresses MUST be your personal wallets, not the addresses of exchange :::tip Obtaining a Bech32 Address in HAQQ Wallet In the HAQQ Wallet, you can retrieve your wallet address in both EVM and Bech32 formats (the latter is used in Cosmos networks). To do this, click the three dots next to your wallet address and select "Copy Bech32 Address." -
![haqqwallet-get-bech32](/img/user_guides/haqqwallet-get-bech32.jpeg)
@@ -40,7 +39,6 @@ In the HAQQ Wallet, you can retrieve your wallet address in both EVM and Bech32 :::tip Obtaining a Bech32 Address on HAQQ via EVM Address If you have the recipient's address in EVM format on the HAQQ Network, you can convert it to a Bech32 address using the web app for vesting. Visit this URL: https://shell.haqq.network/utils/address-conversion insert your EVM address and copy the bech32 address starting with "haqq1...." -
![address-conversion](/img/user_guides/address-conversion.png)
@@ -56,60 +54,32 @@ If you have the recipient's address in EVM format on the HAQQ Network, you can c 6. Click on "Swap" 7. Review the tokens and networks. If everything looks correct, click "Set Destination Address." 8. Set the recipient address on the HAQQ Network using Keplr or manually paste the Bech32 address. - :::note The sender and recipient addresses must not be the same. - ::: - -
- skip-destination - {' '} - -
+:::note The sender and recipient addresses must not be the same. +::: +
+ skip-destination +
9. Review the operation one more time. If everything is correct, click "Confirm swap." 10. Skip will request permission to deduct the amount you wish to transfer. Verify the amount and confirm the operation. - ![skip-approve](/img/user_guides/skip-approve.png) +![skip-approve](/img/user_guides/skip-approve.png) -11. After 10-15 seconds, Skip will request the transfer transaction. Confirm it. +12. After 10-15 seconds, Skip will request the transfer transaction. Confirm it.
- skip-tx - {' '} - + skip-tx
-13. Next, you will see a screen indicating the EVM bridging finality time, which is approximately 16 minutes. - -
- skip-confirm - {' '} - -
+13. Next, you will see a screen indicating the EVM bridging finality time, which is approximately 16 minutes. +
+ skip-confirm +
14. At this point, you can safely leave the page. Your tokens will be credited to your wallet on the HAQQ Network in about 16 minutes. 15. The current transfer status will be displayed on the page. 16. Once the transfer is complete, the successful status and transaction details will be shown. -
- skip-final - {' '} - -
+
+ skip-final +
+ + diff --git a/docs/user-guides/index.mdx b/docs/user-guides/index.mdx index 4ad6941..d428456 100644 --- a/docs/user-guides/index.mdx +++ b/docs/user-guides/index.mdx @@ -32,4 +32,4 @@ Seek legal advice if you intend to run a validator. Discuss the finer details of being a validator on our community chat: - [HAQQ Network Discord](https://discord.gg/CDtXuQG3Vd) -- [Islamic Coin Discord](https://discord.gg/aZMm8pekhZ) +- [Islamic Coin Discord](https://discord.gg/aZMm8pekhZ) \ No newline at end of file diff --git a/docs/user-guides/nft.md b/docs/user-guides/nft.md index 7ba8f9d..09d6dc5 100644 --- a/docs/user-guides/nft.md +++ b/docs/user-guides/nft.md @@ -1,9 +1,8 @@ --- sidebar_position: 9 -title: First Smart Contract - NFT +title: First Smart Contract - NFT --- - -# Creating Your First NFT Smart Contract on HAQQ Network- A Beginner's Guide +# Creating Your First NFT Smart Contract on HAQQ Network- A Beginner's Guide ## Intro @@ -24,20 +23,23 @@ Follow the [Metamask](../user-guides/connect-your-wallet/Metamask/#connect-to-te You can get free ISLM tokens on HAQQ testedge2 in [faucet here](../../develop/faucet/#request-tokens-on-web) ::: + ## Create smart contract with OpenZeppelin > Founded in 2015, OpenZeppelin is the world leader in securing blockchain applications and smart contracts. Its bedrock open source Contract Libraries are a public good and industry standard for smart contract development. OpenZeppelin’s professional expertise, unified with the Defender developer security platform, integrates through clients’ development lifecycles, so teams can plan, code, audit, deploy and operate projects faster and more safely. +> + -1. Open - OpenZeppelin - https://wizard.openzeppelin.com/ +1. Open - OpenZeppelin - https://wizard.openzeppelin.com/ 2. Select ERC721 - NFT - ![open-zeppelin-start](/img/user_guides/open-zeppelin-start.png) +![open-zeppelin-start](/img/user_guides/open-zeppelin-start.png) 3. If you want the NFT to be with an image or metadata, select - URI Storage 4. If you want mint NFT after deploy, select - Mintable, and ease way - Auto Increment Ids 5. Allow users to delete - Burn 6. Set your Name and Symbol 7. Can other users mint - delete onlyOwner? Or just the author? - stay safe with onlyOwner -8. Cool - Your smart contract Created - ![open-zeppelin-finish](/img/user_guides/open-zeppelin-finish.png) +8. Cool - Your smart contract Created +![open-zeppelin-finish](/img/user_guides/open-zeppelin-finish.png) As you may have noticed, thanks to the libraries from OpenZeppelin and their contract wizard, you can create new contracts with just a few clicks of the mouse. This is incredibly convenient and provides a foundational level that you can build upon with your own custom logic. For example, you could allow minting by anyone but introduce a minting fee that is directly transferred to the contract creator. @@ -95,7 +97,7 @@ contract NFTExample is ERC721, ERC721URIStorage, ERC721Burnable, Ownable { ## Deploy with Remix -The next step will be to compile the smart contract code and deploy it to the network. For this, we will use the functionality provided by Remix. Additionally, you will need to connect your EVM wallet to Remix. +The next step will be to compile the smart contract code and deploy it to the network. For this, we will use the functionality provided by Remix. Additionally, you will need to connect your EVM wallet to Remix. Remix IDE is part of the Remix Project, a rich toolset that can be used for the entire journey of contract development by users of any knowledge level. Remix IDE is used for the entire journey of smart contract development by users at every knowledge level. It requires no setup, fosters a fast development cycle, and has a rich set of plugins with intuitive GUIs. The IDE comes in two flavors (web app or desktop app). We will use Remix Online IDE, see: https://remix.ethereum.org @@ -104,55 +106,69 @@ We **strongly** recommend using a separate wallet for development purposes from ::: 1. In OpenZeppilin click - Open in Remix - ![remix-start](/img/user_guides/remix-start.png) +![remix-start](/img/user_guides/remix-start.png) 2. Config Solidity Compiler - Select **Solidity 8.20** and **EVM** compile **Paris** - :::info - We recommend using **Solidity 8.19** but to simplify the example now, choose **8.20** - ::: - :::warning - **Must use - EVM compile Paris** - ::: - ![remix-solidity-compiler](/img/user_guides/remix-solidity-compiler.png) +:::info +We recommend using **Solidity 8.19** but to simplify the example now, choose **8.20** +::: +:::warning +**Must use - EVM compile Paris** +::: +![remix-solidity-compiler](/img/user_guides/remix-solidity-compiler.png) 3. Compile contract - click on Compile button 4. Go to - Deploy & run transactions 5. Connect your wallet 6. Select HAQQ Testedge2 network in your wallet. -7. Set up inichial owener - your wallet addr - ![remix-deploy-setup](/img/user_guides/remix-deploy-setup.png) +7. Set up inichial owener - your wallet addr +![remix-deploy-setup](/img/user_guides/remix-deploy-setup.png) 8. Click on Deploy 9. Confirm TX - ![remix-confirm-tx](/img/user_guides/remix-confirm-tx.png) +![remix-confirm-tx](/img/user_guides/remix-confirm-tx.png) 10. See tx status - ![remix-tx-status](/img/user_guides/remix-tx-status.png) +![remix-tx-status](/img/user_guides/remix-tx-status.png) 11. Cool - Your contract Deployed. 12. You can see in interface your contract addr and now we start interact with your contract on haqq chain + ## Mint with Remix Remix is not only a tool for compiling and deploying contracts; you can also interact with and debug contracts on the network using it. Let's go ahead and release your first NFT through your own smart contract. 1. See your smart contract available methods - ![remix-mint-start](/img/user_guides/remix-mint-start.png) +![remix-mint-start](/img/user_guides/remix-mint-start.png) 2. Open Mint methods - ![remix-mint](/img/user_guides/remix-mint.png) -3. Setup mint - 1. to address insert your address - 2. url - paste the image address with the base url in mind - what does that mean - the path to the image should be BaseUrl + Url - for example the link to the image is https://vorobevsa.com/haqq.png BaseUrl = https://vorobevsa.com - then the url is /test.png -4. Transact +![remix-mint](/img/user_guides/remix-mint.png) +3. Setup mint + 1. to address insert your address + 2. url - paste the image address with the base url in mind - what does that mean - the path to the image should be BaseUrl + Url - for example the link to the image is https://vorobevsa.com/haqq.png BaseUrl = https://vorobevsa.com - then the url is /test.png +4. Transact 5. Sing TX 6. Use method token URI and see your link from NFT - ![remix-token-uri](/img/user_guides/remix-token-uri.png) +![remix-token-uri](/img/user_guides/remix-token-uri.png) 7. Seath TX by hash in [explorer for HAQQ TestEdge2](https://explorer.testedge2.haqq.network) - ![explorer-tx](/img/user_guides/explorer-tx.png) -8. Click on your token id - 1 in example - ![explorer-mint-tx](/img/user_guides/explorer-mint-tx.png) -9. See your token and image - ![explorer-nft](/img/user_guides/explorer-nft.png) +![explorer-tx](/img/user_guides/explorer-tx.png) +25. Click on your token id - 1 in example +![explorer-mint-tx](/img/user_guides/explorer-mint-tx.png) +27. See your token and image +![explorer-nft](/img/user_guides/explorer-nft.png) ## Next steps Here's what you can study next: -1. NFT Metadata:In the example, we considered that TokenURI immediately returns an image, this is the simplest example, but the best application would be to use NFT Metadata. If you will use Metadata - The TokenURI does not directly deliver an image, but a JSON file containing metadata. This metadata can include not only a link to the image but also a wealth of information about the NFT and its applications. A good article on metadata is available on [OpenSea metadata-standards](https://docs.opensea.io/docs/metadata-standards). For example, on our network, check out the NFT ["Fruits of Jannah"](https://explorer.haqq.network/token/0xe5C15B68cfE3182c106f60230A1bE377ceaad483/instance/1?tab=metadata). -2. Changing Smart Contract Logic: By modifying the smart contract, you can make minting paid or add new functionalities. For instance, you can transform NFTs into SBT (Soulbound Tokens) by restricting the transfer function. Here’s a detailed article about SBT - [Understanding Soulbound Tokens(SBTs)](https://haqq.network/blog/soulbound-tokens), and [HAQQ Crypto Academy Certificate](https://explorer.haqq.network/token/0x22CC1c235892d84453AAe398237449530e653bd3) as an example from our network. +1. NFT Metadata:In the example, we considered that TokenURI immediately returns an image, this is the simplest example, but the best application would be to use NFT Metadata. If you will use Metadata - The TokenURI does not directly deliver an image, but a JSON file containing metadata. This metadata can include not only a link to the image but also a wealth of information about the NFT and its applications. A good article on metadata is available on [OpenSea metadata-standards](https://docs.opensea.io/docs/metadata-standards). For example, on our network, check out the NFT ["Fruits of Jannah"](https://explorer.haqq.network/token/0xe5C15B68cfE3182c106f60230A1bE377ceaad483/instance/1?tab=metadata). +2. Changing Smart Contract Logic: By modifying the smart contract, you can make minting paid or add new functionalities. For instance, you can transform NFTs into SBT (Soulbound Tokens) by restricting the transfer function. Here’s a detailed article about SBT - [Understanding Soulbound Tokens(SBTs)](https://haqq.network/blog/soulbound-tokens), and [HAQQ Crypto Academy Certificate](https://explorer.haqq.network/token/0x22CC1c235892d84453AAe398237449530e653bd3) as an example from our network. 3. Future Developments and Applications of NFTs: The further development and application of NFTs are limited only by your imagination. We are excited to see new uses for NFTs on our network and encourage you to explore innovative ways to leverage this technology. Your creativity could lead to the next big advancement in the world of digital assets. + + + + + + + + + + + + + diff --git a/src/components/chain-config-value/chain-config-value.tsx b/src/components/chain-config-value/chain-config-value.tsx index 3b1d3d5..b57087c 100644 --- a/src/components/chain-config-value/chain-config-value.tsx +++ b/src/components/chain-config-value/chain-config-value.tsx @@ -2,22 +2,12 @@ import React from 'react'; import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; import { MainnetConfig, TestnetConfig } from '@site/src/utils/chain-config'; -export function ChainConfigValue({ - chain, - keyword, -}: { - chain: string; - keyword: string; -}) { +export function ChainConfigValue({ chain, keyword }: { chain: string, keyword: string }) { switch (chain) { case 'main': - return MainnetConfig[keyword] ? ( - {MainnetConfig[keyword]} - ) : null; + return MainnetConfig[keyword] ? {MainnetConfig[keyword]} : null; case 'test': - return TestnetConfig[keyword] ? ( - {TestnetConfig[keyword]} - ) : null; + return TestnetConfig[keyword] ? {TestnetConfig[keyword]} : null; default: return null; } diff --git a/src/components/homepage-features/homepage-features.tsx b/src/components/homepage-features/homepage-features.tsx index b4733bb..bb6fd28 100644 --- a/src/components/homepage-features/homepage-features.tsx +++ b/src/components/homepage-features/homepage-features.tsx @@ -11,131 +11,129 @@ import { IntroducionIcon } from '../icons/introduciton-icon'; export default function HomepageFeatures() { return (
-
-
-
-

- HAQQ Documentation -

-

- HAQQ is a scalable and interoperable Ethereum, built on - Proof-of-Stake with fast-finality. -

+
+
+
+

HAQQ Documentation

+

+ HAQQ is a scalable and interoperable Ethereum, built on + Proof-of-Stake with fast-finality. +

+
+ +
+
+ Getting Started
+

+ Read all about HAQQ or dive straight into the code with guides. +

-
-
- Getting Started +
+
+ + } + /> +
-

- Read all about HAQQ or dive straight into the code with guides. -

- -
-
- - } - /> - -
-
- - } - /> - -
+
+ + } + /> +
+
-
-
- Explore HAQQ -
-

- Get familiar with HAQQ and explore its main concepts. -

+
+
+ Explore HAQQ +
+

+ Get familiar with HAQQ and explore its main concepts. +

-
-
- - } - /> - -
-
- - } - /> - -
-
- - } - /> - -
-
- - } - /> - -
-
- - } - /> - -
+
+
+ + } + /> + +
+
+ + } + /> + +
+
+ + } + /> + +
+
+ + } + /> + +
+
+ + } + /> +
-
+
+
); } diff --git a/src/css/custom.css b/src/css/custom.css index e97df4e..e1b1fe6 100644 --- a/src/css/custom.css +++ b/src/css/custom.css @@ -4,8 +4,7 @@ @font-face { font-family: 'Clash Display'; - src: - url('/fonts/ClashDisplay-Medium.woff2') format('woff2'), + src: url('/fonts/ClashDisplay-Medium.woff2') format('woff2'), url('/fonts/ClashDisplay-Medium.woff') format('woff'); font-weight: 500; font-style: normal; @@ -13,8 +12,7 @@ @font-face { font-family: 'HK Guise'; - src: - url('/fonts/hk_guise_medium-webfont.woff2') format('woff2'), + src: url('/fonts/hk_guise_medium-webfont.woff2') format('woff2'), url('/fonts/hk_guise_medium-webfont.woff') format('woff'); font-weight: 500; font-style: normal; @@ -22,8 +20,7 @@ @font-face { font-family: 'HK Guise'; - src: - url('/fonts/hk_guise_regular-webfont.woff2') format('woff2'), + src: url('/fonts/hk_guise_regular-webfont.woff2') format('woff2'), url('/fonts/hk_guise_regular-webfont.woff') format('woff'); font-weight: 400; font-style: normal;