# MAAL Network Details

Details on how to access and add MAAL network

MAAL Chain is an EVM based blockchain.

MaalChain Mainnet & Testnet, both are listed on chainlist.org. Go to the links below to add it to MetaMask wallet from Chainlist\
\
Mainnet: <https://chainlist.org/chain/786>

Testnet: <https://chainlist.org/chain/7860>

### MaalChain TestNet

RPC-URL:&#x20;

Use one of the following:

{% embed url="<https://node1.maalscan.io>" %}

Chain ID: 7860

Token Symbol: MAAL

Block explorer: <https://testnet.maalscan.io>

*Note: Check the screenshot below*

<figure><img src="/files/kDBYDpBteEaXMwjhkQi8" alt=""><figcaption><p>Adding MaalChain testnet to MetaMask</p></figcaption></figure>

Head over to our test-net faucet from the link below to claim test MAAL Coins to help you start your development journey on MaalChain test-net.

{% embed url="<https://faucet-testnet.maalscan.io>" %}

### MAAL MainNet

RPC-URL: \
Use any one of the following:

{% embed url="<https://node1-mainnet.maalscan.io>" fullWidth="true" %}

{% embed url="<https://node2-mainnet.maalscan.io>" %}

{% embed url="<https://node3-mainnet.maalscan.io>" %}

Chain ID: 786

Token Symbol: MAAL

Block explorer: <https://maalscan.io>

*Note: Check the screenshot below*

<div data-full-width="false"><figure><img src="/files/7JokvQZw9yWp35beDkE5" alt=""><figcaption><p>Adding MaalChain Mainnet to MetaMask</p></figcaption></figure></div>


# How to connect to MAAL Chain

You can use our public rpc-urls to connect to our blockchain and interact with it.

For RPC URLs for our testnet and mainnet [visit](/)

When interacting with our own blockchain built on the Polygon (formerly Matic) network, you can use various JSON-RPC endpoints to send transactions, broadcast them, and receive transaction-related information. Here are some common JSON-RPC endpoints you can use with Web3.js to interact with our blockchain:

1. **Send Transaction:** To send a transaction to our blockchain, you typically use the `eth_sendTransaction` method. You'll need to construct a transaction object and sign it with the sender's private key.
2. **Broadcast Transaction:** After constructing and signing a transaction, you can broadcast it using the `eth_sendRawTransaction` method. This sends the signed transaction data to the network for processing.
3. **Get Transaction Receipt:** To retrieve information about a specific transaction, including its status and other details, you can use the `eth_getTransactionReceipt` method. This returns a receipt object containing information about the transaction's execution.
4. **Get Transaction by Hash:** If you want to get detailed information about a transaction using its transaction hash, you can use the `eth_getTransactionByHash` method.
5. **Get Transaction Count:** To retrieve the number of transactions sent from a specific address, you can use the `eth_getTransactionCount` method.

Here's how you might use these endpoints with Web3.js (javascript):

```javascript
const Web3 = require('web3');

const rpcUrl = 'https://node1-mainnet.maalscan.io';
const web3 = new Web3(new Web3.providers.HttpProvider(rpcUrl));

// Construct and send a transaction
const senderAddress = '0x...'; // Your sender's address
const privateKey = '0x...'; // Your sender's private key
const receiverAddress = '0x...'; // Receiver's address
const valueToSend = web3.utils.toWei('0.1', 'ether');

const nonce = await web3.eth.getTransactionCount(senderAddress);
const gasPrice = await web3.eth.getGasPrice();

const txObject = {
  nonce: nonce,
  to: receiverAddress,
  value: valueToSend,
  gasPrice: gasPrice,
  gas: 21000, // Gas limit for standard transactions
};

const signedTx = await web3.eth.accounts.signTransaction(txObject, privateKey);
const txHash = await web3.eth.sendSignedTransaction(signedTx.rawTransaction);
console.log('Transaction Hash:', txHash);

// Get transaction receipt
const receipt = await web3.eth.getTransactionReceipt(txHash);
console.log('Transaction Receipt:', receipt);

// Get transaction details by hash
const txDetails = await web3.eth.getTransactionByHash(txHash);
console.log('Transaction Details:', txDetails);

// Get transaction count of an address
const transactionCount = await web3.eth.getTransactionCount(senderAddress);
console.log('Transaction Count:', transactionCount);
```

Please replace the placeholders (`'0x...'`) with actual addresses and keys. Also, remember that interacting with real blockchains involves real value transactions and security considerations, so exercise caution and test thoroughly before using this code in a production environment.


# ETH APIs

API endpoints and methods for interacting with the MAALCHAIN

### eth\_chainId[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_chainid) <a href="#eth_chainid" id="eth_chainid"></a>

Returns the currently configured chain id, a value used in replay-protected transaction signing as introduced by EIP-155.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters) <a href="#parameters" id="parameters"></a>

* None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns) <a href="#returns" id="returns"></a>

* QUANTITY - big integer of the current chain id.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example) for testnet <a href="#example" id="example"></a>

```
curl  https://node1.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
```

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example) for mainnet <a href="#example" id="example"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
```

### eth\_syncing[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_syncing) <a href="#eth_syncing" id="eth_syncing"></a>

Returns information about the sync status of the node

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-1) <a href="#parameters-1" id="parameters-1"></a>

* None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-1) <a href="#returns-1" id="returns-1"></a>

\* Boolean (FALSE) - if the node isn't syncing (which means it has fully synced)

\* Object - an object with sync status data if the node is syncing

* startingBlock: QUANTITY - The block at which the import started (will only be reset, after the sync reached his head)
* currentBlock: QUANTITY - The current block, same as eth\_blockNumber
* highestBlock: QUANTITY - The estimated highest block

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-1) <a href="#example-1" id="example-1"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
```

### eth\_getBlockByNumber[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getblockbynumber) <a href="#eth_getblockbynumber" id="eth_getblockbynumber"></a>

Returns block information by number.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-2) <a href="#parameters-2" id="parameters-2"></a>

* QUANTITY|TAG - integer of a block number, or the string "latest"
* Boolean - If true it returns the full transaction objects, if false only the hashes of the transactions.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-2) <a href="#returns-2" id="returns-2"></a>

Object - A block object, or null when no block was found:

* number: QUANTITY - the block number.
* hash: DATA, 32 Bytes - hash of the block.
* parentHash: DATA, 32 Bytes - hash of the parent block.
* nonce: DATA, 8 Bytes - hash of the generated proof-of-work.
* sha3Uncles: DATA, 32 Bytes - SHA3 of the uncles data in the block.
* logsBloom: DATA, 256 Bytes - the bloom filter for the logs of the block.
* transactionsRoot: DATA, 32 Bytes - the root of the transaction trie of the block.
* stateRoot: DATA, 32 Bytes - the root of the final state trie of the block.
* receiptsRoot: DATA, 32 Bytes - the root of the receipts trie of the block.
* miner: DATA, 20 Bytes - the address of the beneficiary to whom the mining rewards were given.
* difficulty: QUANTITY - integer of the difficulty for this block.
* totalDifficulty: QUANTITY - integer of the total difficulty of the chain until this block.
* extraData: DATA - the “extra data” field of this block.
* size: QUANTITY - integer the size of this block in bytes.
* gasLimit: QUANTITY - the maximum gas allowed in this block.
* gasUsed: QUANTITY - the total used gas by all transactions in this block.
* timestamp: QUANTITY - the unix timestamp for when the block was collated.
* transactions: Array - Array of transaction objects, or 32 Bytes transaction hashes depending on the last given parameter.
* uncles: Array - Array of uncle hashes.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-2) <a href="#example-2" id="example-2"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest", true],"id":1}'
```

### eth\_getBlockByHash[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getblockbyhash) <a href="#eth_getblockbyhash" id="eth_getblockbyhash"></a>

Returns block information by hash.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-3) <a href="#parameters-3" id="parameters-3"></a>

* DATA , 32 Bytes - Hash of a block.
* Boolean - If true it returns the full transaction objects, if false only the hashes of the transactions.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-3) <a href="#returns-3" id="returns-3"></a>

Object - A block object, or null when no block was found:

* number: QUANTITY - the block number.
* hash: DATA, 32 Bytes - hash of the block.
* parentHash: DATA, 32 Bytes - hash of the parent block.
* nonce: DATA, 8 Bytes - hash of the generated proof-of-work.
* sha3Uncles: DATA, 32 Bytes - SHA3 of the uncles data in the block.
* logsBloom: DATA, 256 Bytes - the bloom filter for the logs of the block.
* transactionsRoot: DATA, 32 Bytes - the root of the transaction trie of the block.
* stateRoot: DATA, 32 Bytes - the root of the final state trie of the block.
* receiptsRoot: DATA, 32 Bytes - the root of the receipts trie of the block.
* miner: DATA, 20 Bytes - the address of the beneficiary to whom the mining rewards were given.
* difficulty: QUANTITY - integer of the difficulty for this block.
* totalDifficulty: QUANTITY - integer of the total difficulty of the chain until this block.
* extraData: DATA - the “extra data” field of this block.
* size: QUANTITY - integer the size of this block in bytes.
* gasLimit: QUANTITY - the maximum gas allowed in this block.
* gasUsed: QUANTITY - the total used gas by all transactions in this block.
* timestamp: QUANTITY - the unix timestamp for when the block was collated.
* transactions: Array - Array of transaction objects, or 32 Bytes transaction hashes depending on the last given parameter.
* uncles: Array - Array of uncle hashes.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-3) <a href="#example-3" id="example-3"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",false],"id":1}'
```

### eth\_blockNumber[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_blocknumber) <a href="#eth_blocknumber" id="eth_blocknumber"></a>

Returns the number of the most recent block.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-4) <a href="#parameters-4" id="parameters-4"></a>

None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-4) <a href="#returns-4" id="returns-4"></a>

* QUANTITY - integer of the current block number the client is on.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-4) <a href="#example-4" id="example-4"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
```

### eth\_gasPrice[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_gasprice) <a href="#eth_gasprice" id="eth_gasprice"></a>

Returns the current price of gas in wei. If minimum gas price is enforced by setting the `--price-limit` flag, this endpoint will return the value defined by this flag as minimum gas price.

***

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-5) <a href="#parameters-5" id="parameters-5"></a>

None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-5) <a href="#returns-5" id="returns-5"></a>

* QUANTITY - integer of the current gas price in wei.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-5) <a href="#example-5" id="example-5"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'
```

### eth\_getBalance[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getbalance) <a href="#eth_getbalance" id="eth_getbalance"></a>

Returns the balance of the account of the given address.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-6) <a href="#parameters-6" id="parameters-6"></a>

* DATA, 20 Bytes - address to check for balance.
* QUANTITY|TAG - integer block number, or the string "latest"

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-6) <a href="#returns-6" id="returns-6"></a>

* QUANTITY - integer of the current balance in wei.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-6) <a href="#example-6" id="example-6"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
```

### eth\_sendRawTransaction[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_sendrawtransaction) <a href="#eth_sendrawtransaction" id="eth_sendrawtransaction"></a>

Creates new message call transaction or a contract creation for signed transactions.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-7) <a href="#parameters-7" id="parameters-7"></a>

* DATA - The signed transaction data.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-7) <a href="#returns-7" id="returns-7"></a>

* DATA, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-7) <a href="#example-7" id="example-7"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"],"id":1}'
```

### eth\_getTransactionByHash[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_gettransactionbyhash) <a href="#eth_gettransactionbyhash" id="eth_gettransactionbyhash"></a>

Returns the information about a transaction requested by transaction hash.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-8) <a href="#parameters-8" id="parameters-8"></a>

* DATA, 32 Bytes - hash of a transaction

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-8) <a href="#returns-8" id="returns-8"></a>

Object - A transaction object, or null when no transaction was found:

* blockHash: DATA, 32 Bytes - hash of the block where this transaction was in.
* blockNumber: QUANTITY - block number where this transaction was in.
* from: DATA, 20 Bytes - address of the sender.
* gas: QUANTITY - gas provided by the sender.
* gasPrice: QUANTITY - gas price provided by the sender in Wei.
* hash: DATA, 32 Bytes - hash of the transaction.
* input: DATA - the data send along with the transaction.
* nonce: QUANTITY - the number of transactions made by the sender prior to this one.
* to: DATA, 20 Bytes - address of the receiver. null when its a contract creation transaction.
* transactionIndex: QUANTITY - integer of the transactions index position in the block.
* value: QUANTITY - value transferred in Wei.
* v: QUANTITY - ECDSA recovery id
* r: DATA, 32 Bytes - ECDSA signature r
* s: DATA, 32 Bytes - ECDSA signature s

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-8) <a href="#example-8" id="example-8"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
```

### eth\_getTransactionReceipt[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_gettransactionreceipt) <a href="#eth_gettransactionreceipt" id="eth_gettransactionreceipt"></a>

Returns the receipt of a transaction by transaction hash.

Note That the receipt is not available for pending transactions.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-9) <a href="#parameters-9" id="parameters-9"></a>

* DATA, 32 Bytes - hash of a transaction

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-9) <a href="#returns-9" id="returns-9"></a>

Object - A transaction receipt object, or null when no receipt was found:

* transactionHash : DATA, 32 Bytes - hash of the transaction.
* transactionIndex: QUANTITY - integer of the transactions index position in the block.
* blockHash: DATA, 32 Bytes - hash of the block where this transaction was in.
* blockNumber: QUANTITY - block number where this transaction was in.
* from: DATA, 20 Bytes - address of the sender.
* to: DATA, 20 Bytes - address of the receiver. null when its a contract creation transaction.
* cumulativeGasUsed : QUANTITY - The total amount of gas used when this transaction was executed in the block.
* gasUsed : QUANTITY - The amount of gas used by this specific transaction alone.
* contractAddress : DATA, 20 Bytes - The contract address created, if the transaction was a contract creation, otherwise null.
* logs: Array - Array of log objects, which this transaction generated.
* logsBloom: DATA, 256 Bytes - Bloom filter for light clients to quickly retrieve related logs.

It also returns either :

* root : DATA 32 bytes - post-transaction stateroot (pre Byzantium)
* status: QUANTITY - either 1 (success) or 0 (failure)

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-9) <a href="#example-9" id="example-9"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238"],"id":1}'
```

### eth\_getTransactionCount[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_gettransactioncount) <a href="#eth_gettransactioncount" id="eth_gettransactioncount"></a>

Returns the number of transactions sent from an address.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-10) <a href="#parameters-10" id="parameters-10"></a>

* DATA, 20 Bytes - address.
* QUANTITY|TAG - integer block number, or the string "latest"

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-10) <a href="#returns-10" id="returns-10"></a>

* QUANTITY - integer of the number of transactions send from this address.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-10) <a href="#example-10" id="example-10"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
```

### eth\_getBlockTransactionCountByNumber[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getblocktransactioncountbynumber) <a href="#eth_getblocktransactioncountbynumber" id="eth_getblocktransactioncountbynumber"></a>

Returns the number of transactions in a block matching the given block number.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-11) <a href="#parameters-11" id="parameters-11"></a>

* QUANTITY|TAG - integer of a block number, or the string "latest"

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-11) <a href="#returns-11" id="returns-11"></a>

* QUANTITY - integer of the number of transactions in this block.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-11) <a href="#example-11" id="example-11"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["latest"],"id":1}'
```

### eth\_getLogs[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getlogs) <a href="#eth_getlogs" id="eth_getlogs"></a>

Returns an array of all logs matching a given filter object.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-12) <a href="#parameters-12" id="parameters-12"></a>

Object - The filter options:

* fromBlock: QUANTITY|TAG - (optional, default: "latest") Integer block number, or "latest" for the last mined block
* toBlock: QUANTITY|TAG - (optional, default: "latest") Integer block number, or "latest" for the last mined block
* address: DATA|Array, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
* topics: Array of DATA - (optional) Array of 32 Bytes DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with “or” options.
* blockhash: DATA, 32 Bytes - (optional, future) With the addition of EIP-234, blockHash will be a new filter option which restricts the logs returned to the single block with the 32-byte hash blockHash. Using blockHash is equivalent to fromBlock = toBlock = the block number with hash blockHash. If blockHash is present in the filter criteria, then neither fromBlock nor toBlock is allowed.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-12) <a href="#returns-12" id="returns-12"></a>

* QUANTITY - integer of the number of transactions send from this address.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-12) <a href="#example-12" id="example-12"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics": ["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":1}'
```

### eth\_getCode[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getcode) <a href="#eth_getcode" id="eth_getcode"></a>

Returns code at a given address.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-13) <a href="#parameters-13" id="parameters-13"></a>

* DATA, 20 Bytes - address
* QUANTITY|TAG - integer block number, or the string "latest"

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-13) <a href="#returns-13" id="returns-13"></a>

* DATA - the code from the given address.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-13) <a href="#example-13" id="example-13"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", "0x2"],"id":1}'
```

### eth\_call[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_call) <a href="#eth_call" id="eth_call"></a>

Executes a new message call immediately without creating a transaction on the blockchain.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-14) <a href="#parameters-14" id="parameters-14"></a>

Object - The transaction call object

* from: DATA, 20 Bytes - (optional) The address the transaction is sent from.
* to: DATA, 20 Bytes - The address the transaction is directed to.
* gas: QUANTITY - (optional) Integer of the gas provided for the transaction execution. eth\_call consumes zero gas, but this parameter may be needed by some executions.
* gasPrice: QUANTITY - (optional) Integer of the gasPrice used for each paid gas
* value: QUANTITY - (optional) Integer of the value sent with this transaction
* data: DATA - (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI in the Solidity documentation
* QUANTITY|TAG - integer block number, or the string "latest", see the default block paramete

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-14) <a href="#returns-14" id="returns-14"></a>

* DATA - the return value of executed contract.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-14) <a href="#example-14" id="example-14"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'
```

### eth\_getStorageAt[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getstorageat) <a href="#eth_getstorageat" id="eth_getstorageat"></a>

Returns the value from a storage position at a given address.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-15) <a href="#parameters-15" id="parameters-15"></a>

* DATA, 20 Bytes - address of the storage.
* QUANTITY - integer of the position in the storage.
* QUANTITY|TAG - integer block number, or the string "latest"

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-15) <a href="#returns-15" id="returns-15"></a>

* DATA - the value at this storage position.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-15) <a href="#example-15" id="example-15"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getStorageAt","params":["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"],"id":1}'
```

### eth\_estimateGas[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_estimategas) <a href="#eth_estimategas" id="eth_estimategas"></a>

Generates and returns an estimate of how much gas is necessary to allow the transaction to complete. The transaction will not be added to the blockchain. Note that the estimate may be significantly more than the amount of gas actually used by the transaction, for a variety of reasons including EVM mechanics and node performance.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-16) <a href="#parameters-16" id="parameters-16"></a>

Expect that all properties are optional.

Object - The transaction call object

* from: DATA, 20 Bytes - The address the transaction is sent from.
* to: DATA, 20 Bytes - The address the transaction is directed to.
* gas: QUANTITY - Integer of the gas provided for the transaction execution. eth\_call consumes zero gas, but this parameter may be needed by some executions.
* gasPrice: QUANTITY - Integer of the gasPrice used for each paid gas
* value: QUANTITY - Integer of the value sent with this transaction
* data: DATA - Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI in the Solidity documentation
* QUANTITY|TAG - integer block number, or the string "latest", see the default block paramete

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-16) <a href="#returns-16" id="returns-16"></a>

* QUANTITY - the amount of gas used.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-16) <a href="#example-16" id="example-16"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
```

### eth\_newFilter[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_newfilter) <a href="#eth_newfilter" id="eth_newfilter"></a>

Creates a filter object, based on filter options. To get all matching logs for specific filter, call eth\_getFilterLogs. To check if the state has changed, call eth\_getFilterChanges.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-17) <a href="#parameters-17" id="parameters-17"></a>

Object - The filter options:

* fromBlock: QUANTITY|TAG - (optional, default: "latest") Integer block number, or "latest" for the last mined block
* toBlock: QUANTITY|TAG - (optional, default: "latest") Integer block number, or "latest" for the last mined block
* address: DATA|Array, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
* topics: Array of DATA - (optional) Array of 32 Bytes DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with “or” options.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-17) <a href="#returns-17" id="returns-17"></a>

* QUANTITY - A filter id.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-17) <a href="#example-17" id="example-17"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":1}'
```

### eth\_newBlockFilter[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_newblockfilter) <a href="#eth_newblockfilter" id="eth_newblockfilter"></a>

Creates a filter in the node, to notify when a new block arrives. To check if the state has changed, call eth\_getFilterChanges.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-18) <a href="#parameters-18" id="parameters-18"></a>

None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-18) <a href="#returns-18" id="returns-18"></a>

1. QUANTITY - A filter id.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-18) <a href="#example-18" id="example-18"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":1}'
```

### eth\_getFilterLogs[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getfilterlogs) <a href="#eth_getfilterlogs" id="eth_getfilterlogs"></a>

Returns an array of all logs matching filter with given id.

ETH\_GETLOGS VS. ETH\_GETFILTERLOGS

These 2 methods will return the same results for same filter options:

1. eth\_getLogs with params \[options]
2. eth\_newFilter with params \[options], getting a \[filterId] back, then calling eth\_getFilterLogs with \[filterId]

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-19) <a href="#parameters-19" id="parameters-19"></a>

* QUANTITY - the filter id.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-19) <a href="#returns-19" id="returns-19"></a>

Array - Array of log objects, or an empty array

* For filters created with eth\_newFilter logs are objects with the following params:
  * removed: TAG - true when the log was removed, due to a chain reorganization. false if its a valid log.
  * logIndex: QUANTITY - integer of the log index position in the block. null when its pending log.
  * transactionIndex: QUANTITY - integer of the transactions index position log was created from. null when its pending log.
  * transactionHash: DATA, 32 Bytes - hash of the transactions this log was created from. null when its pending log.
  * blockHash: DATA, 32 Bytes - hash of the block where this log was in. null when its pending log.
  * blockNumber: QUANTITY - the block number where this log was in. null when its pending log.
  * address: DATA, 20 Bytes - address from which this log originated.
  * data: DATA - contains one or more 32 Bytes non-indexed arguments of the log.
  * topics: Array of DATA - Array of 0 to 4 32 Bytes DATA of indexed log arguments. (In solidity: The first topic is the hash of the signature of the event (e.g. Deposit(address,bytes32,uint256)), except you declared the event with the anonymous specifier.)

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-19) <a href="#example-19" id="example-19"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":1}'
```

### eth\_getFilterChanges[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_getfilterchanges) <a href="#eth_getfilterchanges" id="eth_getfilterchanges"></a>

Polling method for a filter, which returns an array of logs that occurred since the last poll.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-20) <a href="#parameters-20" id="parameters-20"></a>

* QUANTITY - the filter id.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-20) <a href="#returns-20" id="returns-20"></a>

Array - Array of log objects, or an empty array if nothing has changed since last poll.

* For filters created with eth\_newBlockFilter the return are block hashes (DATA, 32 Bytes), e.g. \["0x3454645634534..."].
* For filters created with eth\_newFilter logs are objects with the following params:
  * removed: TAG - true when the log was removed, due to a chain reorganization. false if its a valid log.
  * logIndex: QUANTITY - integer of the log index position in the block. null when its pending log.
  * transactionIndex: QUANTITY - integer of the transactions index position log was created from. null when its pending log.
  * transactionHash: DATA, 32 Bytes - hash of the transactions this log was created from. null when its pending log.
  * blockHash: DATA, 32 Bytes - hash of the block where this log was in. null when its pending log.
  * blockNumber: QUANTITY - the block number where this log was in. null when its pending log.
  * address: DATA, 20 Bytes - address from which this log originated.
  * data: DATA - contains one or more 32 Bytes non-indexed arguments of the log.
  * topics: Array of DATA - Array of 0 to 4 32 Bytes DATA of indexed log arguments. (In solidity: The first topic is the hash of the signature of the event (e.g. Deposit(address,bytes32,uint256)), except you declared the event with the anonymous specifier.)

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-20) <a href="#example-20" id="example-20"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":1}'
```

### eth\_uninstallFilter[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_uninstallfilter) <a href="#eth_uninstallfilter" id="eth_uninstallfilter"></a>

Uninstalls a filter with a given id. Should always be called when a watch is no longer needed. Additionally, filters timeout when they aren’t requested with eth\_getFilterChanges for some time.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-21) <a href="#parameters-21" id="parameters-21"></a>

* QUANTITY - The filter id.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-21) <a href="#returns-21" id="returns-21"></a>

* Boolean - true if the filter was successfully uninstalled, otherwise false.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-21) <a href="#example-21" id="example-21"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":1}'
```

### eth\_unsubscribe[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#eth_unsubscribe) <a href="#eth_unsubscribe" id="eth_unsubscribe"></a>

Subscriptions are cancelled with a regular RPC call with eth\_unsubscribe as a method and the subscription id as the first parameter. It returns a bool indicating if the subscription was cancelled successfully.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#parameters-22) <a href="#parameters-22" id="parameters-22"></a>

* SUBSCRIPTION ID

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#returns-22) <a href="#returns-22" id="returns-22"></a>

* UNSUBSCRIBED FLAG - true if the subscription was cancelled successful.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-eth/#example-22) <a href="#example-22" id="example-22"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_unsubscribe","params":["0x9cef478923ff08bf67fde6c64013158d"],"id":1}'
```


# NET

Get MAALCHAIN network details

### net\_version[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#net_version) <a href="#net_version" id="net_version"></a>

Returns the current network id.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#parameters) <a href="#parameters" id="parameters"></a>

None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#returns) <a href="#returns" id="returns"></a>

* String - The current network id.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#example) <a href="#example" id="example"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":83}'
```

### net\_listening[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#net_listening) <a href="#net_listening" id="net_listening"></a>

Returns true if a client is actively listening for network connections.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#parameters-1) <a href="#parameters-1" id="parameters-1"></a>

None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#returns-1) <a href="#returns-1" id="returns-1"></a>

* Boolean - true when listening, otherwise false.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#example-1) <a href="#example-1" id="example-1"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":83}'
```

### net\_peerCount[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#net_peercount) <a href="#net_peercount" id="net_peercount"></a>

Returns number of peers currently connected to the client.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#parameters-2) <a href="#parameters-2" id="parameters-2"></a>

None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#returns-2) <a href="#returns-2" id="returns-2"></a>

* QUANTITY - integer of the number of connected peers.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-net/#example-2) <a href="#example-2" id="example-2"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}'
```


# Web3

Web3 methods

### web3\_clientVersion[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#web3_clientversion) <a href="#web3_clientversion" id="web3_clientversion"></a>

Returns the current client version.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#parameters) <a href="#parameters" id="parameters"></a>

None

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#returns) <a href="#returns" id="returns"></a>

* String - The current client version

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#example) <a href="#example" id="example"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}'
```

### web3\_sha3[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#web3_sha3) <a href="#web3_sha3" id="web3_sha3"></a>

Returns Keccak-256 (not the standardized SHA3-256) of the given data.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#parameters-1) <a href="#parameters-1" id="parameters-1"></a>

* DATA - the data to convert into a SHA3 hash

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#returns-1) <a href="#returns-1" id="returns-1"></a>

* DATA - The SHA3 result of the given string.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-web3/#example-1) <a href="#example-1" id="example-1"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":1}'
```


# Tx Pool

Tx Pool methods

### txpool\_content[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#txpool_content) <a href="#txpool_content" id="txpool_content"></a>

Returns a list with the exact details of all the transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#parameters) <a href="#parameters" id="parameters"></a>

None

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#example) <a href="#example" id="example"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"txpool_content","params":[],"id":1}'
```

### txpool\_inspect[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#txpool_inspect) <a href="#txpool_inspect" id="txpool_inspect"></a>

Returns a list with a textual summary of all the transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only. This is a method specifically tailored to developers to quickly see the transactions in the pool and find any potential issues.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#parameters-1) <a href="#parameters-1" id="parameters-1"></a>

None

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#example-1) <a href="#example-1" id="example-1"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"txpool_inspect","params":[],"id":1}'
```

### txpool\_status[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#txpool_status) <a href="#txpool_status" id="txpool_status"></a>

Returns the number of transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#parameters-2) <a href="#parameters-2" id="parameters-2"></a>

None

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-txpool/#example-2) <a href="#example-2" id="example-2"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"txpool_status","params":[],"id":1}'
```


# Debug

Debug methods

To enable the debug route namespace, you need to modify the configuration and add the "debug" parameter as shown below:

```
[jsonrpc.http]
    enabled = true
    port = 10001
    host = "0.0.0.0"
    api = ["eth", "net", "web3", "txpool", "bor", "debug"]
```

### debug\_traceBlockByNumber[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#debug_traceblockbynumber) <a href="#debug_traceblockbynumber" id="debug_traceblockbynumber"></a>

Executes all transactions in the block specified by number with a tracer and returns the tracing result.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#parameters) <a href="#parameters" id="parameters"></a>

* QUANTITY|TAG - integer of a block number, or the string "latest"
* Object - The tracer options:
  * enableMemory: Boolean - (optional, default: false) The flag indicating enabling memory capture.
  * disableStack: Boolean - (optional, default: false) The flag indicating disabling stack capture.
  * disableStorage: Boolean - (optional, default: false) The flag indicating disabling storage capture.
  * enableReturnData: Boolean - (optional, default: false) The flag indicating enabling return data capture.
  * timeOut: String - (optional, default: "5s") The timeout for cancellation of execution.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#returns) <a href="#returns" id="returns"></a>

Array - Array of trace objects with the following fields:

* failed: Boolean - the tx is successful or not
* gas: QUANTITY - the total consumed gas in the tx
* returnValue: DATA - the return value of the executed contract call
* structLogs: Array - the trace result of each step with the following fields:
  * pc: QUANTITY - the current index in bytecode
  * op: String - the name of current executing operation
  * gas: QUANTITY - the available gas ßin the execution
  * gasCost: QUANTITY - the gas cost of the operation
  * depth: QUANTITY - the number of levels of calling functions
  * error: String - the error of the execution
  * stack: Array - array of values in the current stack
  * memory: Array - array of values in the current memory
  * storage: Object - mapping of the current storage
  * refund: QUANTITY - the total of current refund value

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#example) <a href="#example" id="example"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"debug_traceBlockByNumber","params":["latest"],"id":1}'
```

### debug\_traceBlockByHash[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#debug_traceblockbyhash) <a href="#debug_traceblockbyhash" id="debug_traceblockbyhash"></a>

Executes all transactions in the block specified by block hash with a tracer and returns the tracing result.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#parameters-1) <a href="#parameters-1" id="parameters-1"></a>

* DATA , 32 Bytes - Hash of a block.
* Object - The tracer options. See debug\_traceBlockByNumber for more details.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#returns-1) <a href="#returns-1" id="returns-1"></a>

Array - Array of trace objects. See debug\_traceBlockByNumber for more details.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#example-1) <a href="#example-1" id="example-1"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"debug_traceBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae"],"id":1}'
```

### debug\_traceBlock[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#debug_traceblock) <a href="#debug_traceblock" id="debug_traceblock"></a>

Executes all transactions in the block given from the first argument with a tracer and returns the tracing result.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#parameters-2) <a href="#parameters-2" id="parameters-2"></a>

* DATA - RLP Encoded block bytes
* Object - The tracer options. See debug\_traceBlockByNumber for more details.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#returns-2) <a href="#returns-2" id="returns-2"></a>

Array - Array of trace objects. See debug\_traceBlockByNumber for more details.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#example-2) <a href="#example-2" id="example-2"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"debug_traceBlock","params":["0xf9...."],"id":1}'
```

### debug\_traceTransaction[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#debug_tracetransaction) <a href="#debug_tracetransaction" id="debug_tracetransaction"></a>

Executes the transaction specified by transaction hash with a tracer and returns the tracing result.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#parameters-3) <a href="#parameters-3" id="parameters-3"></a>

* DATA , 32 Bytes - Hash of a transaction.
* Object - The tracer options. See debug\_traceBlockByNumber for more details.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#returns-3) <a href="#returns-3" id="returns-3"></a>

Object - Trace object. See debug\_traceBlockByNumber for more details.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#example-3) <a href="#example-3" id="example-3"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"debug_traceTransaction","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae"],"id":1}'
```

### debug\_traceCall[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#debug_tracecall) <a href="#debug_tracecall" id="debug_tracecall"></a>

Executes a new message call with a tracer and returns the tracing result.

#### Parameters[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#parameters-4) <a href="#parameters-4" id="parameters-4"></a>

* Object - The transaction call object
  * from: DATA, 20 Bytes - (optional) The address the transaction is sent from.
  * to: DATA, 20 Bytes - The address the transaction is directed to.
  * gas: QUANTITY - (optional) Integer of the gas provided for the transaction execution. eth\_call consumes zero gas, but this parameter may be needed by some executions.
  * gasPrice: QUANTITY - (optional) Integer of the gasPrice used for each paid gas
  * value: QUANTITY - (optional) Integer of the value sent with this transaction
  * data: DATA - (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI in the Solidity documentation
* QUANTITY|TAG - integer block number, or the string "latest"
* Object - The tracer options. See debug\_traceBlockByNumber for more details.

#### Returns[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#returns-4) <a href="#returns-4" id="returns-4"></a>

Object - Trace object. See debug\_traceBlockByNumber for more details.

#### Example[​](https://wiki.polygon.technology/docs/supernets/api/json-rpc-debug/#example-4) <a href="#example-4" id="example-4"></a>

```
curl  https://node1-mainnet.maalscan.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"debug_traceCall","params":[{"to": "0x1234", "data": "0x1234"}, "latest", {}],"id":1}'
```


# MAAL Contract Library

Libraries for smart contract development on MAAL blockchain

{% file src="/files/llJjFUdRPO0V2kANRXtH" %}
For creating fungible tokens on MAAL blockchain
{% endfile %}

{% file src="/files/QYCmAvUjfTCTIc0WAhiu" %}

{% file src="/files/C3dwubaC8mCM6RT4QREO" %}

{% file src="/files/ylKQaBm71BtdVuJ5KIwT" %}

{% file src="/files/VU8ewi1idQWPGS7H5wgB" %}

{% file src="/files/FYBeR6e6U6MdYe9NQdwm" %}

{% file src="/files/ZeqnnqhLKyquWaJuGXth" %}

{% file src="/files/2CmC4zfU8QYhSsEHQ6b8" %}

{% file src="/files/LYhgHhBnKQgwVGa9t6hY" %}

{% file src="/files/fXmW26I3Ijo3ugjB84mb" %}

{% file src="/files/d2Zkxc0RbdXsMqsHH6ZP" %}


# MaalChain Architecture

MAAL blockchain network is a blockchain application platform that provides Bridged Proof-of-Stake.

Architecturally, the beauty of MAAL blockchain is its elegant design, which features a generic validation layer separated from varying execution environments like full-blown EVM sidechains.

To enable decentralized governance on MaalChain, a Validator DAO is proposed which is detailed further in this doc under ["Maal Validator DAO"](/maal-validator-dao).&#x20;

Ethereum is the first basechain MAAL blockchain supports as it uses Polygon edge, and as Polygon intends to offer support for additional basechains to enable an interoperable decentralized Layer 2 blockchain platform, MAAL will also support those basechains.

MaalChain has a three-layer architecture:

1. IBFT Consensus Mechanism
2. Heimdall (Proof of Stake layer)
3. Bor (Block producer layer)

### IBFT Consensus Mechanism

IBFT ensures a single, deterministically defined order of transactions in the digital ledger. It additionally, ensures one block settlement finality. IBFT was proposed by Amis Technologies and later implemented by JP Morgan’s Quorum as one of the consensus mechanisms in **Geth**.

#### Key Advantages of IBFT <a href="#c1f0" id="c1f0"></a>

* **Immediate block finality**\
  IBFT allows one block for each block height since it can be added by elected block producer. This feature eradicates the possibility of any forking, uncle blocks and provides immediate confirmation of executed transactions.
* **Reduced time between blocks**\
  Since every block producer gets its chance to add block deterministically, the effort required to write and validate blocks is reduced significantly (as compared to PoW), greatly increasing the throughput of the chain.
* **High data integrity and fault tolerance**\
  IBFT based Blockchain deals with a consortium of BPs. This ensures that only trust-worthy BPs contribute who maintain the integrity of every new block. Additionally, a two-third majority of these BPs are required to sign any block prior to adding it to the blockchain, making forgery in block producing extremely difficult. As mentioned earlier, every member in this consortium of block producer gets its chance. That essentially means, that no block producer will get a chance to hold the power for a long time. This removed the chance of even any faulty block producer to influence the ledger for a long time.
* **Operationally flexible**\
  The consortium of BPs can be updated in time, ensures trustworthy BPs remain the member of the consortium.

### IBFT Consensus Model <a href="#id-4ef1" id="id-4ef1"></a>

* IBFT uses a pool of block producing nodes (**BPs**) operating on the Ledgerium Blockchain to determine if a proposed block is suitable for addition to the chain.
* One BP among the consortium of BPs will deterministically be selected as the **Proposer** and will propose a new candidate block to the consortium. Once, the supermajority (\~66%) is achieved by signing enough no of BPs, the new block will be added to the blockchain.
* Once the new block is added i.e. consensus round is completed, the role of the Proposer will move to the next in line BP.
* By adding a new block to the chain means, that state machine is updated across all the BPs and the new block is appended by every BP in their respective public state at the same block height.
* If not enough no of BPs has signed the block or reject the candidate block, the block will not be inserted and eventually, the Proposer role will be moved to the next BP in line and the process will start afresh.
* The IBFT consensus implements ‘Block Locking’ mechanism that essentially means, that once the block is inserted, it is finalised, and it cannot be altered later point in time.
* The **IBFT** consensus provides system integrity by ensuring that as long as more than 2/3 of the BPs are behaving correctly, the mining or the process of adding new block process continues unabated. This means F (the number of **faulty** nodes) can be tolerated by the system in order to consensus mechanism to function properly i.e. maximum 1/3 of the BPs are allowed to behave incorrectly (either due to being compromised or due to **faulty** code).

### Heimdall (Proof-of-Stake validator layer)[​](https://wiki.polygon.technology/docs/home/architecture/polygon-architecture#heimdall-proof-of-stake-validator-layer) <a href="#heimdall-proof-of-stake-validator-layer" id="heimdall-proof-of-stake-validator-layer"></a>

**Heimdall** is the PoS validator node that works in consonance with the Staking contracts on the network to enable the PoS mechanism on MAAL. We have implemented this by building on top of Polygon edge which further builds upon the Tendermint consensus engine with changes to the signature scheme and various data structures. It is responsible for block validation, block producer committee selection, checkpointing a representation of the sidechain blocks to Ethereum in our architecture and various other responsibilities.

Heimdall layer handles the aggregation of blocks produced by Bor into a merkle tree and publishing the merkle root periodically to the root chain. This periodic publishing are called `checkpoints`. For every few blocks on Bor, a validator (on the Heimdall layer):

1. Validates all the blocks since the last checkpoint
2. Creates a merkle tree of the block hashes
3. Publishes the merkle root to the main chain

Checkpoints are important for two reasons:

1. Providing finality on the Root Chain
2. Providing proof of burn in withdrawal of assets

A bird’s eye view of the process can be explained as:

* A subset of active validators from the pool are selected to act as block producers for a span. The Selection of each span will also be consented by at least 2/3 in power. These block producers are responsible for creating blocks and broadcasting it to the remaining of the network.
* A checkpoint includes the root of all blocks created during any given interval. All nodes validate the same and attach their signature to it.
* A selected proposer from the validator set is responsible for collecting all signatures for a particular checkpoint and committing the same on the main-chain.
* The responsibility of creating blocks and also proposing checkpoints is variably dependent on a validator’s stake ratio in the overall pool.

### Bor (Block Producer Layer)[​](https://wiki.polygon.technology/docs/home/architecture/polygon-architecture#bor-block-producer-layer) <a href="#bor-block-producer-layer" id="bor-block-producer-layer"></a>

Bor is Polygon block producer layer - the entity responsible for aggregating transactions into blocks.

Block producers are periodically shuffled via committee selection on Heimdall in durations termed as a `span` in MAAL. Blocks are produced at the **Bor** node and the sidechain VM is EVM-compatible. Blocks produced on Bor are also validated periodically by Heimdall nodes, and a checkpoint consisting of the Merkle tree hash of a set of blocks on Bor is committed to Ethereum periodically.


# What is Proof of Stake?

Proof of Stake (PoS) is a category of consensus algorithms for public blockchains that depend on a validator's economic stake in the network.

In proof of work (PoW) based public blockchains, the algorithm rewards participants who solve cryptographic puzzles to validate transactions and create new blocks. PoW blockchain examples: Bitcoin, current Ethereum.

In PoS-based public blockchains, a set of validators take turns proposing and voting on the next block. The weight of each validator's vote depends on the size of its deposit — stake. Significant advantages of PoS include security, reduced risk of centralization, and energy efficiency. PoS blockchain examples: Eth2.0, Polygon.

In general, a PoS algorithm looks as follows. The blockchain keeps track of a set of validators, and anyone who holds the blockchain's base cryptocurrency (in Ethereum's case, ether) can become a validator by sending a special type of transaction that locks up their ether into a deposit. The process of creating and agreeing to new blocks is then done through a consensus algorithm that all current validators can participate in.

There are many kinds of consensus algorithms, and many ways to assign rewards to validators who participate in the consensus algorithm, so there are many "flavors" of proof of stake. From an algorithmic perspective, there are two major types: chain-based PoS and BFT-style PoS.

In **chain-based proof of stake**, the algorithm pseudo-randomly selects a validator during each time slot (e.g. every period of 10 seconds might be a time slot), and assigns that validator the right to create a single block, and this block must point to some previous block (normally the block at the end of the previously longest chain), and so over time most blocks converge into a single constantly growing chain.

In **BFT-style proof of stake**, validators are **randomly** assigned the right to *propose* blocks, but *agreeing on which block is canonical* is done through a multi-round process where every validator sends a "vote" for some specific block during each round, and at the end of the process all (honest and online) validators permanently agree on whether or not any given block is part of the chain. Note that blocks may still be *chained together*; the key difference is that consensus on a block can come within one block, and does not depend on the length or size of the chain after it.

For more details, refer <https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ>.

<br>


# Who is a validator?

This seeks to explain the definition of a validator in Maal blockchain ecosystem.

A validator is a participant in the MaalChain network who locks up $MAAL coins in the Maal Validator DAO and takes active part in MaalChain governance via the DAO. Validators stake their $MAAL coins as collateral to work for the security of the network and in exchange for their service, earn rewards from the validator DAO. The onus of running the node on behalf of the validators lies with Maal Data Labs.

Rewards are distributed to all validators in DAO proportional to their Maal Coins staked half yearly distributed to the wallet which holds the Validator DAO NFT. User reward balance gets updated in the DAO contract which is referred to while claiming rewards.

For more details please refer to [Maal Validator DAO](/maal-validator-dao) section.


# Validator Nodes

A blockchain validator is someone who is responsible for validating transactions within a blockchain. On the MAAL blockchain network, participants have to be vetted by stakeholders to become a validator  in Maal Validator DAO by staking their Maal Coins to earn rewards and collect transaction fees.

### Technical node operations[​](https://wiki.polygon.technology/docs/maintain/validate/validator-responsibilities/#technical-node-operations) <a href="#technical-node-operations" id="technical-node-operations"></a>

The following technical node operations are done automatically by the nodes which are run by Maal Data Labs on behalf of validators in Maal Validator DAO:

* Block producer selection:
  * Select a subset of validators for the block producer set for each span
  * For each span, select the block producer set again on Heimdall and transmit the selection information to Bor periodically.
* Validating blocks on Bor:
  * For a set of Bor sidechain blocks, each validator independently reads block data for these blocks and validates the data on Heimdall
* Checkpoint submission:
  * A proposer is chosen among the validators for each Heimdall block. The checkpoint proposer creates the checkpoint of Bor block data, validates, and broadcasts the signed transaction for other validators to consent to.
  * If >2/3 of the active validators reach consensus on the checkpoint, the checkpoint submitted to the MAAL network.

### Operations[​](https://wiki.polygon.technology/docs/maintain/validate/validator-responsibilities/#operations) by nodes <a href="#operations" id="operations"></a>

**Maintain high uptime**[**​**](https://wiki.polygon.technology/docs/maintain/validate/validator-responsibilities/#maintain-high-uptime)

A node's uptime on the MAAL network is based on the number of checkpoint transactions that the validator node has signed.

Approximately every 30 minutes, a proposer submits a checkpoint transaction to the network. The checkpoint transaction must be signed by every validator on the MAAL network.

Failure to sign a checkpoint transaction results in the decrease of validator node performance.

The process of signing the checkpoint transactions is automated. To ensure validator node is signing all valid checkpoint transactions, the organisation concerned must maintain and monitor node health held by it.


# Minimum system requirements

Following are the minimum system requirements for running one node. Maal Data Labs maintains all the nodes and the incurred costs on the operation of these nodes are charged from the OPEX cost.

| Type | Value                                                              | Influenced by                                                                                                                |
| ---- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| CPU  | 4 cores                                                            | <ul><li>Number of JSON-RPC queries</li><li>Size of the blockchain state</li><li>Block gas limit</li><li>Block time</li></ul> |
| RAM  | 8 GB                                                               | <ul><li>Number of JSON-RPC queries</li><li>Size of the blockchain state</li><li>Block gas limit</li></ul>                    |
| Disk | <ul><li>64 GB root partition with LVM for disk extension</li></ul> | <ul><li>Size of the blockchain state</li></ul>                                                                               |
|      |                                                                    |                                                                                                                              |

Validators in Maal Validators DAO do not need to acquire technical knowledge of running and maintaining a node, neither do they have to spend on the maintenance of these nodes as Maal Data Labs maintains it for all the validators, making it easy for anyone to join Maal Validator DAO.


# MAAL Validator DAO

**Table of Contents**

1. **Introduction**
2. **DAO Structure**
   * 2.1 Membership and Ranking
   * 2.2 Governance
   * 2.3 Revenue Sharing
3. **Technical Details**
   * 3.1 Smart Contracts
   * 3.2 Voting Mechanism
   * 3.3 Revenue Distribution
4. **Security Measures**
5. **Conclusion**

### 1. Introduction

Welcome to the MAAL Validator DAO (Decentralized Autonomous Organization) proposal. This document outlines the technical details and structure of a DAO designed to manage and govern the MAALChain network. The MAALChain network relies on a set of validators, and this DAO aims to provide these validators with a mechanism for participating in the network's governance and sharing in its success.

### 2. DAO Structure

#### 2.1 Membership and Ranking

The MAALChain Validator DAO consists of the 150 DAO validators, which are ranked based on their MAAL coin holdings and KYC verification check. These validators are divided into three tiers according to their coin holdings, with the top tier having the highest coin holdings and influence over the network's governance. Membership in this DAO is determined by holding the MAAL Validator NFT, which is minted and distributed to the 150 DAO validators only. These NFTs embody ownership of DAO validator rights and are eligible for transfer only after a 5-year period. They may be offered for resale among validators, who will have the first refusal right, (however each Validator can hold no more than 2 Validator NFTs at any time to avoid the Monopoly influence over the DAO but not stopped from holding additional Maal Coins). In the event that consensus among existing validators cannot be reached to exercise this right, the NFTs can be sold to any other party seeking to become a DAO validator, provided they undergo KYC approval prior to the transfer. Should neither of these options be feasible, holders have the choice of liquidating their MAAL coin holdings at prevailing market rates.

The tiers are as detailed below:

<table><thead><tr><th width="100">Tier</th><th width="300">Min. Maal Coin Holding</th><th data-type="number">Max Validators</th></tr></thead><tbody><tr><td>I</td><td>14,285,714 MAAL</td><td>10</td></tr><tr><td>II</td><td>2,500,000 MAAL</td><td>40</td></tr><tr><td>III</td><td>222,222 MAAL</td><td>100</td></tr><tr><td></td><td></td><td>150</td></tr></tbody></table>

*\*\* As of November 2nd, 2023, MAAL coin has been listed on* [*P2B*](https://p2pb2b.com/trade/MAAL_USDT/) *exchange and is actively being traded. Interested participants will have to buy MAAL coins at prevailing market rate. \*\**

#### Tier Assignment and Transition Rules

Once a validator is successful with his application to become a MAALChain DAO Validator, the following rules apply:

* **Shariah Compliance:** The Validators agree that the MAALChain Validator DAO will be operated in alignment with Sharia principles.&#x20;
* **Tier Assignment**: Based on their Minimum MAAL coin holdings that are pledged during their application Validators shall be assigned to the respective tiers as per the chart above.&#x20;
* **No Automatic Tier Changes**: There are no automatic tier changes for validators. In other words, validators will not be moved to a different tier based on fluctuations in their coin holdings. The initial tier assignment remains constant and hence the choice should be made before applying for a particular tier.
* **No Automatic Upgrading of Tiers based on Vested Coin Holding**: The only way for a validator to change tiers is by applying for a place in a particular tier. Once placed in a tier, the ranking is based on fluctuations in their coin holdings within that tier. &#x20;

**For example:** A person buys a tier III NFT by vesting 222,222 MAAL coins (subject to KYC verification pass) and gains tier III validator rights in MAAL Validator DAO. If the same person were to decide to add more coins to his/her validator NFT and adds 3,000,000 MAAL coins and vests. This would take his/her total holding to 3,222,222 MAAL coins making it more than the tier II validator NFT. Though the person would have more coin holdings than a tier II validator NFT, the person can't migrate to tier II and can only be ranked 1st within tier III if all other 99 validators within tier III hold less than 3,222,222 MAAL coins.

* **Ranking Within Tiers**: Ranking within tiers is determined on the basis of fluctuations in MAAL coin holdings as explained in the example above. ***However, Top Government Organisations/ Religious Institutions can be provided the top ranking within their respective tiers to promote active participation and endorsement.***

#### 2.2 Governance

Validators within the DAO will have the power to vote on proposals for the further development and management of the MAALChain network. Proposals can include network upgrades, changes to consensus rules, and other important decisions. Each validator's voting power is proportionate to their tier and coin holdings, ensuring that those with the highest stake have the most significant influence on the network's direction.

Tier 1 validators have 50 votes each (10 validator slots) with combined weightage of 500 votes

Tier 2 validators have 10 votes each (40 validator slots) with combined weightage of 400 votes

Tier 3 validators have 1 vote each (100 validator slots) with combined weightage of 100 votes

Total combined weightage of all three tiers is 1000 votes. If there is a tie on a proposal, the decision will be made on the basis of proportional MAAL coin holding of voters in favor or against the proposal.

#### 2.3 Revenue Sharing

One of the core functions of the MAALChain Validator DAO is revenue sharing. The DAO generates revenue from transaction fees on the MAALChain, RamzSwap, PanSea NFT Marketplace, and other ecosystem revenues. This revenue is distributed semi-annually among the 150 validators based on their respective tiers and coin holdings and the readiness of the business and actual realisation of the transactional revenues. Smart contracts deployed on MAALChain will automate this distribution process, ensuring transparency and fairness. All Validators share the risk as it requires 12 to 18 months from the initial ecosystem launch for transactional revenue to commence, following the successful precedents set by other blockchain platforms. Subsequently, the profit sharing will occur on a semi-annual basis.

### 3. Assumptions to Calculate the Sharing of Transactional Revenue

The calculations presented herein are founded on specific assumptions, illustrating the potential passive income that MAAL DAO validators have the opportunity to accrue.

<table><thead><tr><th width="266">US $ 10,000,000 Validator Pool</th><th width="130">USD ($)</th><th>Validator Sharing Within Each Tier</th></tr></thead><tbody><tr><td>$ 0.05 x 500 Million transactions</td><td>25,000,000</td><td></td></tr><tr><td>Deduct 40% OPEX</td><td>10,000,000</td><td>Shared Risk prior to generating the revenue &#x26; cost of setting up the servers nodes and other operations costs</td></tr><tr><td>EBITA</td><td>15,000,000</td><td></td></tr><tr><td>Total transaction income distribution</td><td>3,150,000</td><td>Shared Risk &#x26; profit among Validators</td></tr><tr><td>Balance of Revenue</td><td>11,850,000</td><td>Shared Risk and Shared Profit among entire MAALChain Community by way of value appreciation of MAAL coins</td></tr><tr><td>Distribution Ratio for Tier 1</td><td>50%</td><td>$ 1,575,000</td></tr><tr><td>Distribution Ratio for Tier 2</td><td>40%</td><td>$ 1,260,000</td></tr><tr><td>Distribution Ratio for Tier 3</td><td>10%</td><td>$ 315,000</td></tr></tbody></table>

*\*\* Following list of documents must be signed by the participants during their application for the MAAL Validator DAO and have to be agreed to be bound by the rules set in those documents. \*\**

1. *Disclaimer*
2. *Risk Warning*
3. *Information Memorandum*
4. *Application Form*

*To apply for MAAL DAO validator, send us an email to* [*info@maalchain.com*](mailto:info@maalchain.com)

### 4. Technical Details

#### 4.1 Smart Contracts

The MAALChain Validator DAO relies on smart contracts deployed on the MAALChain network to execute its functions. These smart contracts are responsible for:

* Minting and distributing MAAL Validator NFTs to the 150 validators.
* Managing proposals and voting mechanisms for governance decisions.
* Calculating and distributing revenue shares to validator wallets based on tier and coin holdings.
* Handling any dispute resolution or arbitration processes that may arise within the DAO.

#### 4.2 Voting Mechanism

Validators will vote on proposals using their MAAL Validator NFTs as voting tokens. The weight of their vote will be determined by their tier and coin holdings, ensuring a fair and proportional decision-making process. Proposals will be subject to a predefined quorum and majority vote threshold to ensure that only widely supported changes are implemented.

#### 4.3 Revenue Distribution

Revenue generated by the MAALChain network and its associated platforms will be collected in a DAO-controlled treasury wallet. The smart contract will automatically calculate and distribute revenue shares to validator wallets semi-anually. The distribution will be based on each validator's tier and coin holdings, promoting a sense of alignment between validators' interests and the success of the network.

### 5. Security Measures

To ensure the security and integrity of the MAALChain Validator DAO, several security measures will be implemented, including:

* Multi-signature wallets for key transactions and fund management.
* Regular security audits of the smart contracts by independent experts.
* A robust dispute resolution mechanism to address any conflicts or disputes that may arise within the DAO.
* A transparent and publicly accessible record of all DAO activities and decisions on the MAALChain blockchain.

### 6. Conclusion

The MAALChain Validator DAO represents a significant step toward decentralizing governance and revenue sharing within the MAALChain network. By allowing the 150 validators to actively participate in network governance and share in its success, this DAO aims to create a more inclusive and equitable ecosystem. Through smart contracts and transparent processes, the MAALChain Validator DAO will contribute to the long-term sustainability and growth of the MAALChain network. The MAAL Validator DAO operates in strict adherence to Sharia principles, devoid of any central authority that might accumulate substantial holdings of MAAL Coins, be it as a founder, developer, or promoter. Instead, decisions are exclusively entrusted to DAO Validators, setting it apart from conventional blockchain systems.