diff --git a/docs/about-settlemint/1_supported-blockchains.mdx b/docs/about-settlemint/1_supported-blockchains.mdx index d19989ba..c90f4d4a 100644 --- a/docs/about-settlemint/1_supported-blockchains.mdx +++ b/docs/about-settlemint/1_supported-blockchains.mdx @@ -17,6 +17,7 @@ import Polygon from '@site/static/img/about-settlemint/blockchain-logos/polygon- import zkevm from '@site/static/img/about-settlemint/blockchain-logos/zkevm-logo.png'; import Arbitrum from '@site/static/img/about-settlemint/blockchain-logos/arbitrum-logo.png'; import Optimism from '@site/static/img/about-settlemint/blockchain-logos/optimism-logo.png'; +import Hedera from '@site/static/img/about-settlemint/blockchain-logos/hedera-logo.png'; ## Permissioned Blockchains @@ -40,25 +41,14 @@ import Optimism from '@site/static/img/about-settlemint/blockchain-logos/optimis -
-
- -
-
-
-
+ /> + ## Public Blockchains @@ -136,4 +126,12 @@ import Optimism from '@site/static/img/about-settlemint/blockchain-logos/optimis /> +
+ +
diff --git a/docs/blockchain-guides/6_Polygon-Edge/1_polygon-edge-the-basics.md b/docs/blockchain-guides/6_Polygon-Edge/1_polygon-edge-the-basics.md deleted file mode 100644 index fbfdb43d..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/1_polygon-edge-the-basics.md +++ /dev/null @@ -1,20 +0,0 @@ -# The basics - -Polygon Edge is a modular and extensible framework developed by Polygon Technology. Its primary purpose is to bootstrap new Ethereum-compatible blockchain networks. Similar to Hyperledger Besu, a Polygon Edge network can either be permissioned or public. On SettleMint, all Polygon Edge networks are permissioned which means that only a set of specified nodes can join the network. - -## Features - -Polygon Edge's main features include: - -- **Permissioning**: Only specified nodes can join and participate in the network. -- **Ethereum compatible**: A Polygon Edge network is fully compatible with Ethereum smart contracts and transactions. -- **Support for industry standard wallets**: Users are able to interact with industry standard wallets through JSON-RPC. -- **Cross-chain communication**: Transfer assets to and from any Ethereum-compatible network, i.e Ethereum or Polygon thanks to the native [ChainBridge](https://wiki.polygon.technology/docs/edge/additional-features/chainbridge/overview/). - -## Consensus mechanism - -A consensus mechanism defines the rules for the nodes in a blockchain network to reach an agreement on the current state of the blockchain ledger. - -Polygon Edge supports two versions of the Istanbul Byzantine Fault Tolerant IBFT consensus mechanism: **Proof of Stake (PoS)** or **Proof of Authority (PoA)**. Any Polygon Edge network deployed with SettleMint uses **Proof of Authority**. - -You can find more information on Polygon Edge in the official [documentation](https://wiki.polygon.technology/docs/edge/) diff --git a/docs/blockchain-guides/6_Polygon-Edge/2_polygon-edge-network-settings.md b/docs/blockchain-guides/6_Polygon-Edge/2_polygon-edge-network-settings.md deleted file mode 100644 index 15c99ece..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/2_polygon-edge-network-settings.md +++ /dev/null @@ -1,36 +0,0 @@ -# Network settings - -Depending on your requirements, you can configure some advanced settings for your Polygon Edge network. We provide default settings, but you can change these according to your own preferences. - -## Chain ID - -Ethereum network identifier. Used for peer-to-peer communication between nodes as well as during the transaction signature process. Another identifier, known as the network ID is defaulted to the chain ID. - -## Seconds per block - -Interval for new block creation. -Default: 15 s - -## Gas limit - -The maximum amount of gas that can be consumed for a given transaction. -Default: 9007199254740991 - -## Gas price - -The price per gas unit. -Default: 0 wei - -## EVM stack size - -Size for the stack on which the EVM operates. The EVM (Ethereum Virtual Machine) is the environment in which all Ethereum nodes and smart contracts live. -Default: 2048 - -## Contract size limit - -Maximum limit for a smart contract. -Default: 2048 GB - -## Warning - -These settings can no longer be changed once the network is deployed. diff --git a/docs/blockchain-guides/6_Polygon-Edge/3_polygon-edge-node-types.md b/docs/blockchain-guides/6_Polygon-Edge/3_polygon-edge-node-types.md deleted file mode 100644 index 0106a065..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/3_polygon-edge-node-types.md +++ /dev/null @@ -1,19 +0,0 @@ -# Node types - -You can choose between 2 types of node: - -**Validator node** -A validator node is a node that actively participates in the consensus mechanism of the network. It validates the correctness of transactions and creates new blocks. A validator node is a full node, meaning it holds a complete copy of the current state of the blockchain ledger. - -**Non-validator node** -A non-validator node is node that does not actively participate in the consensus mechanism of the network. A non-validator node is also a full node. - -SettleMint uses the IBFT (Istanbul Byzantine Fault Tolerant) consensus mechanism for Polygon networks. Byzantine fault tolerance is the ability for the network to function correctly and reach consensus, despite nodes failing or propagating incorrect information to peers. - -All nodes running in SettleMint are configured to be **archive nodes**, meaning they all include all previous states of a given blockchain since its origin. - -## Info - -You need at least 4 validator nodes for your blockchain network to be Byzantine Fault Tolerant and continue operating if 1 validator node fails. - -[Learn here how to interact with your Polygon Edge node.](4_polygon-edge-connect-to-a-node.md) diff --git a/docs/blockchain-guides/6_Polygon-Edge/4_polygon-edge-connect-to-a-node.md b/docs/blockchain-guides/6_Polygon-Edge/4_polygon-edge-connect-to-a-node.md deleted file mode 100644 index 3e2ff4de..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/4_polygon-edge-connect-to-a-node.md +++ /dev/null @@ -1,72 +0,0 @@ -# Connect to a node - -For a software application to interact with a blockchain (e.g. by sending transactions/data to the network, or even just by reading data), it must connect to a node. - -This section describes how to connect to your Polygon Edge node. - -## Backend APIs - -Once a node has been deployed on an EVM (Ethereum Virtual Machine) compatible network, it can be accessed by different endpoints such as JSON-RPC, JSON-WS or GraphQL. You can connect to your already deployed node using these 3 most common endpoints. - -### JSON-RPC - -JSON-RPC, is a stateless, light-weight remote procedure call (RPC) protocol. Primarily, the specification defines several data structures and the rules around their processing. By default, the version of the JSON-RPC protocol needs to be 2.0, and you need to provide the node ID as well as a method and parameters. - -If you want to correctly connect to your node, you need to respect the right structure for the request, which is always the same: - -```json -{ -"jsonrpc":"2.0" -"Id": nodeId -"method":"methodName" -"params":{ -} -} -``` - -If you want to connect to a node deployed on the SettleMint platform, go to the **Connect** tab on the **Node detail page** in the **Blockchain nodes** section of your application. Select JSON-RPC or any other endpoint and click **Try it out**. You will then be redirected to a new tab where you will be able to test different methods as well as the related Curl command line. - -### JSON-WS - -To make RPC requests over WebSockets, you can use wscat, which is by definition a Node.js based command-line tool. First you will need to connect to your node’s WebSocket server using wscat, as follows: `"wscat -c ws://"` . All the credentials are provided in the **Connect** tab on the **Node detail page** in the **Blockchain nodes** section of your application. After you have established a connection, the terminal should display a ">" prompt. You will then be able to send individual requests as a JSON data package, as above, for instance: - -```json -{ -"jsonrpc":"2.0" -"Id": 1 -"method":"eth_blockNumber" -"params":{ -} -} -``` - -### GraphQL - -GraphQL is a query language and server-side runtime for API’s. It is designed to make APIs fast, flexible, and developer-friendly. -We have a GraphQL interface that can be used with many different queries. These queries can be tested out in our GraphQL playground. You can also test out the different graphql queries with cURL, those request would look like this: - -```bash -curl -X POST -H "Content-Type: application/json" -H “x-auth-token: ” --data -'{ "query": "{syncing{startingBlock currentBlock highestBlock}}"}' http://.settlemint.com/graphql -``` - -If you want to connect to a node deployed on the SettleMint platform, go to the **Connect** tab on the **Node detail page** in the **Blockchain nodes section** of your application. Select Graphql and click **Try it out**. This will bring you to the GraphQL playground where you can use all the different queries. - -## Javascript API - -If you do not want to use the above endpoints to connect to your node, it is possible to use plain Javascript. Several convenience libraries exist within the different ecosystem which makes connection much easier. With these libraries, developers around the world can write one-line methods to easily initiate requests (still under the hood) that interact with Ethereum or any other EVM compliant network. Note that some libraries might be available for Ethereum but not for the other networks. - -These libraries are very helpful and abstract away much of the complexity of interacting directly with your node. Most also provide useful and straightforward functions such as converting ETH to Gwei, so that you can spend less time dealing with decimal issues and more time on the functionality of your underlying application. - -One of the most commonly used libraries, Ethers, is extremely easy to use for signing transactions, sending tokens etc. For example: - -```typescript -// If you don't specify a //url//, Ethers connects to the default -// (i.e. ``http:/\/localhost:8545``) -const provider = new ethers.providers.JsonRpcProvider(); - -// The provider also allows signing transactions to -// send ether and pay to change state within the blockchain. -// For this, we need the account signer... -const signer = provider.getSigner(); -``` diff --git a/docs/blockchain-guides/6_Polygon-Edge/5_polygon-edge-network-stats.md b/docs/blockchain-guides/6_Polygon-Edge/5_polygon-edge-network-stats.md deleted file mode 100644 index 308803a1..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/5_polygon-edge-network-stats.md +++ /dev/null @@ -1,57 +0,0 @@ -# Network and node stats - -## Network stats - -The dashboard gives you an overview of the following stats for the network: - -### Best block - -Shows the "heaviest" block in terms of cumulative difficulty. In other words, the latest block number of the longest valid chain. - -### Last block - -Shows the time, in seconds, since the last block was mined. This value is a good indicator of whether the network is still up and running. A value noticeably above the average time between blocks indicates that the network is no longer mining blocks. - -### Average block time - -Shows the average time, in seconds, it takes for the network to mine a new block. - -### Nodes - -Shows the number of nodes in this network. - -### Transactions/5m - -Shows the number of transactions in a 5-minute window, displayed for the last hour. - -### Gas usage/5m - -Shows the amount of gas spent in a 5-minute window, displayed for the last hour. - -## Node stats - -The dashboard gives you an overview of the following stats for the node: - -### Best block - -Shows the "heaviest" block in terms of cumulative difficulty. In other words, the latest block number of the longest valid chain. - -### Last block - -Shows the time, in seconds, since the last block was mined. This value is a good indicator of whether the network is still up and running. A value noticeably above the average time between blocks indicates that the network is no longer mining blocks. - -### Average blocktime - -Shows the average time, in seconds, it takes for the network to mine a new block. - -### Gas limit - -Shows the maximum amount of gas that can be consumed for a given transaction. - -### Peers - -Shows the number of peer nodes for this node. - -### Pending transactions - -Shows the number of transactions that have been submitted but not yet executed. diff --git a/docs/blockchain-guides/6_Polygon-Edge/6_polygon-edge-integration-tools.md b/docs/blockchain-guides/6_Polygon-Edge/6_polygon-edge-integration-tools.md deleted file mode 100644 index a898a7c2..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/6_polygon-edge-integration-tools.md +++ /dev/null @@ -1,70 +0,0 @@ -# Smart contracts IDE - -The SettleMint IDE is the only tool you need to edit the smart contract set template you have selected, or **write** your own brand **new** smart contracts. The programming language used for your Polygon Edge smart contracts is Solidity. - -## Using the IDE - -When you open the IDE, you land in an instance of Visual Studio Code similar to the image below. - -![ide](../../../static/img/blockchain-guide/IDE.png) - -On the left, in the **“Explorer”** panel, you can see all the folders and files related to the smart contract set. - -The smart contract files are located in the **“contracts”** folder. You can edit them, or use them as they are if the template fits all your needs. - -The **“deploy”** folder contains the scripts that enable the deployment of the smart contract set on the blockchain. You might have to edit these scripts if you add new arguments to the constructor of your smart contract. - -The **“test”** folder contains a script that lets you test the functionalities of your smart contracts. You can add new ones if you edit the template. Do not hesitate to go through the test cases as they provide valuable information on how to use your smart contracts. - -The **subgraph** folder holds all the files needed to index your smart contract using the Graph protocol. - -## Scripts - -Several scripts are defined in `package.json` to help you use the smart contract set: - -- **lint** to lint your smart contracts, i.e. find the stylistic errors. -- **compile** to compile your smart contracts. -- **test** to run the test script in the “test” folder. -- **smartcontract:deploy** to deploy the smart contract set on the blockchain. -- **smartcontract:deploy:reset** to deploy from scratch after a first deployment. -- **graph:config** to create the middleware configuration file. -- **graph:compile** to compile the middleware files. -- **graph:codegen** to create the middleware schema. -- **graph:build** to build the middleware. -- **graph:deploy** to deploy the middleware. -- **graph:all** to execute all the graph scripts in one command. - -:::warning Note - -To execute the scripts related to the Graph middleware, you need a middleware instance in your app. - -::: - -You can execute these scripts in the terminal integrated with the IDE by running `yarn name-of-script`. -For example, to run the `smartcontract:deploy` task using the terminal, open a new terminal (ctrl + shift + \`) and run the command`yarn smartcontract:deploy`. - -## Private key - -To be able to deploy your smart contract set on the blockchain you need to have a private key enabled on your node to sign the transaction, and you need to fund this key with Ether to cover the cost for the transaction. You can create a private key and fund it in the **Private keys section** of your application. [More about private keys.](../../using-platform/17_private-keys.md) - -## Template library - -Every instance of the IDE contains a set of pre-built smart contract templates. These templates are easily customizable to match your specific use case. [Discover the smart contract set templates for Polygon Edge.](../6_Polygon-Edge/Template-library/1_polygon-edge-erc-20.md) - -## Generative AI plugin - -The integration of an OpenAI GPT plugin into the Smart Contract IDE of the SettleMint platform brings forth significant advantages for the fast development of new smart contracts. Generative AI technology empowers developers by providing them with automated code suggestions, smart contract templates, and code completion capabilities. This accelerates the development process by reducing manual effort and improving code efficiency. - -Additionally, the interactive debugging and explanation features offered by the GPT plugin greatly benefit developers of all skill levels. Beginners can leverage the plugin’s explanations to understand complex concepts, improve their coding skills, and gain insights into best practices. Experienced developers can utilize the debugging features to quickly identify and resolve issues, leading to more robust and error-free smart contracts. - -Overall, the integration of the OpenAI GPT plugin into the SettleMint platform’s Smart Contract IDE combines the power of generative AI and interactive debugging to enhance productivity, code quality, and learning opportunities for developers in the blockchain space. - -You can find this plugin in the sidebar (magic lamp icon), in context menu and the action panel. The first time you use the plugin you will get asked for an OpenAI API key. Depending on your OpenAI API access you can use the default GPT 3.5 model or the GPT 4 model which is slower, but more accurate. Check out the settings in the IDE to configure this and other settings (like using your own Azure GPT service) - -Here are some prompts to get you started: - -- Write a Solidity ERC20 token representing a bond, based on OpenZeppelin. Include a bond repayment and coupon payments. -- Write a Solidity ERC721 token representing real estate, based on OpenZeppelin and allow fractional ownership of this NFT in the form of ERC20 tokens. -- Write The Graph indexing code that indexes an ERC721 token on the Ethereum Mainnet. - - diff --git a/docs/blockchain-guides/6_Polygon-Edge/Template-library/1_polygon-edge-erc-20.md b/docs/blockchain-guides/6_Polygon-Edge/Template-library/1_polygon-edge-erc-20.md deleted file mode 100644 index 25696ede..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/Template-library/1_polygon-edge-erc-20.md +++ /dev/null @@ -1,264 +0,0 @@ -# ERC-20 token - -ERC-20 tokens are blockchain-based assets, issued on the Ethereum network, that have value and can be sent and received. These tokens are fungible, meaning they can be exchanged with another token of the same type because they have identical properties and there is an equal value. For example, the ERC-20 token of Alice is exactly the same as the ERC-20 token of Bob. They can exchange their token without consequences. - -Examples of fungible assets are currencies, stocks of a company, bonds, gold and other precious metals. - -The ERC-20 smart contract is the perfect standard to organize a crowdsale and let companies raise funds to launch their project. - -## ERC-20 smart contract features - -An ERC-20 smart contract is used to create fungible tokens and bring them to the blockchain. This process is called minting. It also keeps track of the total supply as well as the balances of users as they exchange their tokens. - -The ERC-20 smart contract on the SettleMint platform has the following features: - -- Custom name, symbol and initial supply that can be chosen by the user. -- Minting capabilities that let the admin of the smart contract mint (i.e create) new tokens. -- Pausable capabilities that let the admin pause the contract in case of emergency. -- Burnable capabilities that let users burn (i.e destroy) their token. - -By default, the account that deploys the ERC-20 smart contract gets 1,000,000 tokens. You can change this behaviour by modifying the **“constructor”** in **“GenericToken.sol”**. If you do not mint tokens in the constructor, make sure to mint some after the deployment. - -```solidity -contract GenericToken is ERC20, ERC20Burnable, Pausable, AccessControl { - constructor(string memory name_, string memory symbol_) ERC20(name_, symbol_) { - _setupRole(DEFAULT_ADMIN_ROLE, msg.sender); - _mint(msg.sender, 1000000 * 10**decimals()); - } -``` - -## Deploying an ERC-20 smart contract - -To set the name and symbol for your token, go to the **“deploy”** folder and in **“00_Deploy_GenericToken.ts”**, change the values in **“args”** in the **“deploy”** function. - -```typescript -await deploy('GenericToken', { - from: deployer, - args: ['GenericToken', 'GT'], - log: true, -}); -``` - -As soon as you are happy with the changes you made, just click on **“deploy”** in the **“task runner”** of the IDE and after a few seconds, your ERC-20 smart contract should be deployed on the network of your choice. - -The **“GenericToken.ts”** script in the **“test”** folder showcases all the functionalities of the ERC-20 standard. It shows you how to use the smart contract in your dapp. - -## ERC-20 with meta transactions - -The SettleMint platform also provides an ERC-20 template set with meta transaction capabilities. Meta transactions are used to fill the need for EVM-based contracts to accept transactions from externally owned accounts that do not have Matic to pay for gas. In short, implementing such an interface omits the need for the end user to pay for gas. With meta transactions, gas is paid by a `gas relayer` and a smart contract, known as a `trusted forwarder`, forwards the transactions to the recipient contract, i.e the one that the end user wants to interact with in the first place. - -### Setting up meta transactions - -When looking at the GenericTokenMeta.sol smart contract in the IDE we can see the main differences with the basic ERC20 being the following: - -```solidity -... -constructor( - ... - address trustedForwarder -) ERC20(name_, symbol_) ERC2771Context(trustedForwarder_) -... - -function _msgSender() internal view override(Context, ERC2771Context) returns (address sender) { - sender = ERC2771Context._msgSender(); -} - -function _msgData() internal view override(Context, ERC2771Context) returns (bytes calldata) { - return ERC2771Context._msgData(); -} - -``` - -Let’s unpack this: - -1. We pass in the constructor an Ethereum address, the `trustedForwarder`, to the `ERC2771Context` constructor. This enables the smart contract to accept transactions coming from the `Trusted Forwarder`. -2. `_msgSender()` function is kind of an alias for `msg.sender`. When called it returns `msg.sender` for regular transactions, but for meta transactions it returns the end user (rather than the `relayer` or the `trusted forwarder`). -3. `_msgData()` function is again an alias of some sort for msg.data. For meta transactions it will return the raw transaction data from the perspective of the end user rather than the `relayer`. - -### Sending a meta transaction to the ERC-20 contract - -Sending a meta transaction is slightly different than sending a regular transaction, but the template set comes with an example in which 10 tokens are transferred between two wallets without Matic. - -First, to send meta transactions using the `forwarder`, we have to define three objects called `EIP712Domain`, `domain` and `types` as follows: - -```typescript -const EIP712Domain = [ - { name: 'name', type: 'string' }, - { name: 'version', type: 'string' }, - { name: 'chainId', type: 'uint256' }, - { name: 'verifyingContract', type: 'address' }, -]; - -const domain = { - name: 'MinimalForwarder', - version: '0.0.1', - chainId: parseInt(await getChainId()), - verifyingContract: forwarderAddress, -}; -const types = { - EIP712Domain, - ForwardRequest: [ - { name: 'from', type: 'address' }, - { name: 'to', type: 'address' }, - { name: 'value', type: 'uint256' }, - { name: 'gas', type: 'uint256' }, - { name: 'nonce', type: 'uint256' }, - { name: 'data', type: 'bytes' }, - ], -}; -``` - -:::warning Note - -The name and version of domain have to match those of the forwarder (see the contract `Forwarder.sol`). - -::: - -Then, we need to generate the function data as follows: - -```typescript -const functionData = token.interface.encodeFunctionData('transfer', [walletTwoAddress, ethers.utils.parseUnits('10')]); -``` - -In that expression, `transfer` is the ERC-20 function we want to execute, `walletTwoAddress` is the account that will receive the tokens and the last parameter is the amount of tokens to be transferred. - -The last step before sending the meta transaction is to create and sign the message containing the underlying transaction as follows: - -```typescript -const walletOneNonce = Number(await read('Forwarder', 'getNonce', walletOneAddress)); -const req = { - from: walletOneAddress, - to: token.address, - value: '0', - gas: '100000', - nonce: walletOneNonce, - data: functionData, -}; - -const signedData = ethSigUtil.signTypedData({ - privateKey: walletOne.getPrivateKey(), - data: { - types: types, - domain: domain, - primaryType: 'ForwardRequest', - message: req, - }, - version: ethSigUtil.SignTypedDataVersion.V4, -}); -``` - -Finally, once the transaction is signed, we can send it to the `forwarder`: - -```typescript -await forwarder.execute(req, signedData, { gasLimit: '100000' }); -``` - -## ERC-20 Crowdsale - -Crowdsales allow the participants of a network to purchase tokens, usually in exchange for ether. A crowdsale can take many different forms, and our powerful templateset allows you the flexibility to shape and deploy the crowdsale according to your needs. - -### Stage 1: Creating a supply of the tokens being sold - -This is done in the templateset by deploying an ERC-20 contract. - -### Stage 2: Configuring and deploying the crowdsale - -When deploying a crowdsale, there are different specifications to be considered: - -- Crowdsale rates - price of the token being sold -- Validation - Who can actually purchase the tokens? -- Distribution - When does the distribution of the tokens actually take place? -- Token emission - Who actually transfers the tokens to the beneficiaries? -- Phases of the crowdsale - Are all the tokens going to be distributed in one go or are they going to be distributed in different phases? - -The ERC-20 crowdsale templateset we provide is designed to give you full flexibility to modify these different parameters according to your requirements. - -#### Price of the token being sold - -In our Crowdsale templateset, you can fix the price of the token in the `_usdRate` field on the `CrowdSale` contract. - -Its value is the number of tokens for one USD. - -#### Validation - -Validation refers to ensuring that the buyers meet certain conditions before they can purchase tokens. - -Our templateset provides KYC / AML whitelisting capabilities out of the box. The buyers must be whitelisted before they can purchase tokens. - -This is implemented using openzepellin’s `AccessControl`. The address with the `DEFAULT_ADMIN_ROLE` grants `WHITELISTED_ROLE` to buyers before they can purchase tokens. - -#### Purchase of tokens - -The buyers can be allocated the tokens in two ways. - -The first method is where the whitelisted buyers can send Matic to the contract directly. The equivalent amount of tokens will be calculated automatically. The calculation is done by first converting the Matic to USD leveraging Chainlink Oracle. Then, the USD is converted to the equivalent amount of tokens using the `_usdRate` set in the crowdsale. - -Alternatively, the admin of the crowdsale can directly allocate tokens to certain buyers by calling the `externalBuyTokens` function. This function can only be called by addresses which have been granted `DEFAULT_ADMIN_ROLE`. Here the tokens get transferred from the sender of the transaction to the beneficiary address listed as a parameter. The reason for providing such a function is to support allocation of tokens to buyers: - -- Who do not know how to send Matic to a contract -- Support payments in other forms other than Matic. For example, fiat payments can be supported. The buyer would send fiat to the crowdsale admin. The crowdsale admin would then call this function to allocate the equivalent amount of tokens to the buyer. - -#### Distribution - -Our templateset gives you flexibility over when you want to actually credit the tokens to the beneficiary. - -This can be done immediately after the tokens have been purchased or a certain amount of time after the purchase, called vesting period. - -To transfer the tokens immediately, set the `_vestingEndDate` field on the `CrowdSale` contract to `0` while deploying the contract. - -When the vesting end date is not set, the tokens purchased get transferred immediately to the beneficiary’s address. - -Transfering the tokens a certain amount of time after the purchase is achieved using two pieces: -Setting the `_vestingEndDate` on the contract to the timestamp at the end of the vesting period -Deploying a `VestingVault` contract and initializing `_vestingVault` field on the `CrowdSale` contract to it’s address - -The beneficiary in this case is the `VestingVault` contract. All the tokens purchased by buyers get stored in the `VestingVault` contract. - -A point to note here is that to store tokens in the `VestingVault` contract, the sender of the transaction must have a `VAULT_CONTROLLER_ROLE` of the `VestingVault` enabled. This can be seen in the deploy steps, explained below. - -The buyers withdraw the tokens they bought after the vesting period has ended by calling the `release` method on the `VestingVault` of the crowdsale contract. - -#### Token emission - -Token emission refers to the actual transaction of transfer of tokens to the beneficiary. -In our templateset, the tokens are transferred from the crowdsale contract itself to the beneficiary. - -The actual transfer from the contract to the beneficiary happens in the `deliverTokens` function on the `CrowdSale` contract. -This is the standard method for token emission. - -There are 2 other patterns of token emission - you can read more about them here: [https://docs.openzeppelin.com/contracts/2.x/crowdsales#token-emission](https://docs.openzeppelin.com/contracts/2.x/crowdsales#token-emission) - -#### Phases of the crowdsale - -Crowdsales are divided into two broad categories. Crowdsales where the tokens are distributed all in one sale. Or, crowdsales with different phases, where in each phase of the crowdsale, the token being sold usually has a different price. There is also a limit to the number of tokens that can be sold in a particular phase. - -To run a crowdsale where there is only one phase, you need to deploy only one `CrowdSale` contract. - -To orchestrate a crowdsale with multiple phases, you need to deploy multiple `CrowdSale` contracts. Here, you deploy a `CrowdSale` contract for each phase. - -Deploy steps: - -Now that we know the different specifications needed for a crowdsale, we will walk you through how we have configured them and deployed the templateset example. - -We are deploying an `ExampleCrowdSale` which is going to sell `ExampleToken`s at the rate of 250 tokens for 1 USD. The tokens are not going to be transferred to the beneficiary directly, they are going to be vested for 30 months in the `ExampleVestingVault`. - -Here we are going to deploy: - -1. An ERC20 token, the token to be sold - In step `00_deploy_token` we deploy the `ExampleToken` which is the actual token to be sold. - -2. A `VestingVault` contract to store the tokens for the vesting period - In step `02_deploy_vestingvault` we deploy the `ExampleVestingVault` to store the tokens for the vesting period. - -3. An `CrowdSale` contract which is the actual crowdsale - In step `03_deploy_crowdsale` we deploy the `ExampleCrowdSale` contract which is the actual crowdsale. We pass the address of the token to be sold, the address of the vesting vault, along with other parameters like the USD rate. - -4. Enable the `ExampleCrowdSale` to store tokens in the `ExampleVestingVault` - In step `04_enable_crowdsale` we grant the `ExampleCrowdSale` crowdsale a `VAULT_CONTROLLER_ROLE` which allows the crowdsale to store tokens in the vesting vault. - -5. Transfer tokens to the `ExampleCrowdSale` to start the crowdsale process - We transfer 100 million Example Tokens to the crowdsale to be sold. - -## Integration with the Middleware - -Working with complex or large data in your dApp can be a challenge. In the SettleMint platform we provide you with a [middleware solution](../../../using-platform/11_middleware.md) that allows you to index and query this data easily and efficiently. diff --git a/docs/blockchain-guides/6_Polygon-Edge/Template-library/2_polygon-edge-erc-721.md b/docs/blockchain-guides/6_Polygon-Edge/Template-library/2_polygon-edge-erc-721.md deleted file mode 100644 index 9185693a..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/Template-library/2_polygon-edge-erc-721.md +++ /dev/null @@ -1,223 +0,0 @@ -# ERC-721 token - -ERC-721 tokens are blockchain-based assets, issued on the Ethereum network, that have value and can be sent and received. Contrary to the ERC-20 tokens, these ERC-721 tokens are non- fungible, meaning that two tokens from the same smart contract are not equivalent. - -Non-fungible tokens, or NFTs, are digitally unique, no two NFTs are the same. For example, if Alice and Bob exchange their NFTs, one of them might feel unlucky as their new token is worth less than their previous ones. NFTs give the ability to assign or claim ownership of any unique piece of digital data, trackable on the blockchain. It can be created from digital objects, as a representation of digital or non-digital assets. - -Examples of what an NFT can represent are real estate properties, collectibles, event tickets, music videos, and artwork. - -The SettleMint platform comes with three ERC-721 contract sets. - -- The first one, simply called **ERC-721 Token**, has all the functionalities to create the token, but it has no specific asset attached to it. It is up to you to create one. The optimised **ERC-721a Token** provides significant gas savings for minting multiple NFTs in a single transaction. -- The second set, called **ERC-721 trading cards**, show you how you can create trading cards with different scarcities. -- Finally, the third set, called **ERC-721 Generative Art**, demonstrates how you can automatically create images by combining several layers of assets. This is the process that was used to create famous NFT collections such as the Bored Ape Yacht Club or the Cryptopunks. - -The trading cards and the generative art sets are extensions of the ERC-721 Token set. The specific features related to these two sets are presented in their respective sections. - -## ERC-721 smart contract features - -An ERC-721 smart contract is used to create non-fungible tokens and bring them to the blockchain. - -The process of creating an ERC-721 has a few distinct phases. The smart contract sets define one such a process which is what we describe below. This is by no means the only way to run your ERC-721 project, if you plan not to follow the playbook below, you can use it to setup your own flow easily. - -### Phase 0: Image generation - -#### Generative Art - -The image generation code for the generative art set is based on the [Hashlips Art Engine](https://github.com/HashLips/hashlips_art_engine), please check out the -README file in the `art_engine` folder on the usage instructions. - -In short, replace the images in the `art_engine/layers` folder, change the settings in the `art_engine/src/config.js` file, and run `yarn artengine:build` to generate your images. Rinse and repeat until you are happy with the result. Note that the generated images are randomized -to prevent streaks of similar images, this can be configured in the `art_engine/src/config.js` file. - -If you want to use the engine to generate a preview image run `yarn artengine:preview` for a static image and `yarn artengine:preview_gif` for a gif. - -Using `yarn artengine:rarity` you can check the rarity of each generated image. - -If you want to pixelate your images, use `yarn artengine:pixelate`, the settings are again in the `art_engine/src/config.js` file. - -Not that the generated metadata does not have a real base uri set, after we have uploaded everything to IPFS, we can set it in the `art_engine/src/config.js` file and update all the metadata using `yarn artengine:update_info`. - -The end result looks like this: -![thumbzup_419.png](../../../../static/img/document360/Images/thumbzup_419.png) - -```json -{ - "name": "thumbzup #419", - "image": "ipfs://bafybeihroeexeljv5yoyum2x4jz6riuqp6xwg6y7cg7jaumcdpyrjxg5zi", - "attributes": [ - { - "trait_type": "background", - "value": "yellow" - }, - { - "trait_type": "body", - "value": "thumb" - }, - { - "trait_type": "face", - "value": "happy" - }, - { - "trait_type": "hair", - "value": "long brown hair" - }, - { - "trait_type": "accessories", - "value": "sunglasses" - } - ] -} -``` - -#### Trading Cards - -The image generation code for Trading Cards is based on the a Hardhat task found in the `tasks` folder. This task is written especially for the -cards for this example project, but it should be fairly simple to adapt it to your needs. - -In short, replace the images in the `assets/layers` folder, change the logic in the `task/generate-assets.ts` file. To generate the trading cards execute `yarn artengine:build --common 10 --limited 5 --rare 2 --unique 1 --ipfsnode `. The ipfs node key can be found in `.secrets/default.hardhat.config.ts`. - -The end result would look like this: - -![aiko-1.png](../../../../static/img/document360/Images/aiko-1.png) - -```json -{ - "name": "Aiko (#1/1)", - "description": "Aiko can express more with his tail in seconds than his owner can express with his tongue in hours.", - "image": "ipfs://bafybeia5truvedhrtdfne3qmoh3tvsvpku6h4airpku6eqvcmrfoja7h4m", - "attributes": [ - { - "trait_type": "Serial Number", - "value": 1, - "max_value": 1, - "display_type": "number" - }, - { - "trait_type": "Breed", - "value": "English Cocker Spaniel" - }, - { - "trait_type": "Shedding", - "value": 3, - "max_value": 5, - "display_type": "number" - }, - { - "trait_type": "Affectionate", - "value": 5, - "max_value": 5, - "display_type": "number" - }, - { - "trait_type": "Playfulness", - "value": 3, - "max_value": 5, - "display_type": "number" - }, - { - "trait_type": "Floof", - "display_type": "boost_number", - "value": 100 - }, - { - "trait_type": "Birthday", - "value": 1605465513, - "display_type": "date" - } - ] -} -``` - -### Phase 1: Initial Setup - -The first step of the process is to deploy the ERC721 contract, and claim the reserve tokens. - -Reserves are an initital amount of tokens that are created at the start of the sale. This is used -typically to generate tokens for the team members and to mint tokens for later use (e.g. for marketing -purposes). - -During this setup phase, some of the important parameters of the sale and collection are set. In the -contract look for the `Configuration` section and tweak the parameters as needed. - -```solidity - ////////////////////////////////////////////////////////////////// - // CONFIGURATION // - ////////////////////////////////////////////////////////////////// - - uint256 public constant RESERVES = 5; // amount of tokens for the team, or to sell afterwards - uint256 public constant PRICE_IN_WEI_WHITELIST = 0.0069 ether; // price per token in the whitelist sale - uint256 public constant PRICE_IN_WEI_PUBLIC = 0.0420 ether; // price per token in the public sale - uint256 public constant MAX_PER_TX = 6; // maximum amount of tokens one can mint in one transaction - uint256 public constant MAX_SUPPLY = 100; // the total amount of tokens for this NFT -``` - -Furthermore, the collection will be launched without exposing any of the metadata or art, leaving the -reveal for after the public sale. In the `assets/placeholder` folder, modify the artwork and metadata -which will be exposed until the reveal. - -Also make sure to go through the files in the `deploy` folder to change any of the values to match your project. - -When you are happy with the setup, you can deploy the contract and claim the reserves by running. - -```bash -yarn smartcontract:deploy:setup -``` - -### Phase 2: Building the whitelist - -To have a successful launch, you will engage in a lot of marketing efforts and community building. Typically -before engaging in the actual sale, various marketing actions are taken to build a whitelist. This list -is to allow people to buy in before the public sale. Allowing a person on the whitelist should be close to a -concrete commitment to the sale. - -Thw whitelist process is built to be very gas efficient using [Merkle Trees](https://medium.com/@ItsCuzzo/using-merkle-trees-for-nft-whitelists-523b58ada3f9). You start by filling the `assets/whitelist.json` file -with the addresses of the whitelisted participants and they amount they can buy in the pre-sale. - -When you have enough commitments we will built the Merkle Tree, generate all the proofs and stire the Merkle Root -in the contract. - -```bash -yarn smartcontract:deploy:whitelist -``` - -This will export the proofs needed to include in your dAPP in the `./assets/generated/whitelist.json` file. Your dAPP -will provide a page where the participants connects their wallet to. Using the address of the wallet, you can load the -proofs and allowances from this JSON file. The dAPP will then configure a form where the participant can choose, -with a maximum of their allowance, how many tokens they want to buy. Pressing the submit button will trigger a transaction -to the `whitelistMint` function with all the parameters filled in and the correct amount of ETH/MATIC/etc as a value. -The user signs this transaction in their wallet and the transaction is sent to the network. - -To display the state of the sale, the items minted, the items left, use the GraphQL endpoint from the The Graph node you can -launch in the SettleMint platform. - -### Phase 3: Opening up the pre-sale - -As soon as you execute the following command, the pre-sale is live. - -```bash -yarn smartcontract:deploy:presale -``` - -### Phase 4: Opening up the public sale - -As soon as you execute the following command, the pre-sale is terminated and the public sale is live. - -```bash -yarn smartcontract:deploy:publicsale -``` - -### Phase 5: The big reveal - -At some point during the process, you will want to reveal the metadata. Some projects choose to reveal immediately, others choose to -reveal after the whitelist sale, and others will wait until a point during the public sale or even after it has concluded. - -Revealing the metadata is done by switching the baseURI to the final IPFS folder with setBaseURI. This can be followed up by running the following to freeze the metadata and prevent further changes. - -```bash -yarn smartcontract:deploy:reveal -``` - -## Integration with the Middleware - -Working with complex or large data in your dApp can be a challenge. In the SettleMint platform we provide you with a [middleware solution](../../../using-platform/11_middleware.md) that allows you to index and query this data easily and efficiently. diff --git a/docs/blockchain-guides/6_Polygon-Edge/Template-library/3_polygon-edge-state-machine.md b/docs/blockchain-guides/6_Polygon-Edge/Template-library/3_polygon-edge-state-machine.md deleted file mode 100644 index 2ccf51f3..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/Template-library/3_polygon-edge-state-machine.md +++ /dev/null @@ -1,294 +0,0 @@ -# State Machine - -This smart contract set implements a state machine. State machines are usually used to represent a system where an entity goes through several sequential states. - -Each state has different functions and different roles associated with it. You can call certain functions only if the state you are in is associated with that function. The different roles associated with a state are the roles who are allowed to perform transition to the next state from the given state. - -Our templateset provides a powerful, highly customisable way to create a statemachine for your use case. - -## Description - -### Representation of a state - -Each state in the statemachine is represented using a `State` struct. A `struct` is a data type in solidity used to represent an object containing different attributes. The `State` struct is declared in the `StateMachine.sol` file as follows: - -```solidity -struct State { - // a boolean to check if the state is actually created - bool hasBeenCreated; - // a mapping of functions that can be executed when in this state - mapping(bytes4 => bool) allowedFunctions; - // a mapping of all roles that have been configured for this state - mapping(bytes32 => bool) allAllowedRoles; - // a list of all the roles that have been configured for this state - bytes32[] allowedRoles; - // a list of all the preconditions that have been configured for this state - function(bytes32, bytes32) internal view[] preConditions; - // a list of callbacks to execute before the state transition completes - function(bytes32, bytes32) internal[] callbacks; - // a list of states that can be transitioned to - bytes32[] nextStates; - // function that executes logic and then does a StateTransition - bytes4 preFunction; -} -``` - -To create a state, you can call the `createState` function which our templateset provides out of the box. It is defined in the `StateMachine.sol` contract. - -### Defining a state - -To comprehensively represent your state, you need to define: - -1. The next states that you can transition to from the given state (`nextStates` field) -2. The functions you can access when you are in the given state (`allowedFunctions` field) -3. The roles who can perform the state transition to the next state (`allowedRoles` field) - -Our templateset allows you to do this very easily through the functions `addNextStateForState`, `addAllowedFunctionForState` and `addRoleForState`. These functions are defined in the `StateMachine.sol` file. - -One thing to note is that these three functions can be only called by the admin. The admin is set to the address from which the contract creation transaction is sent. - -### Transitioning from a state - -#### 1. Pre-conditions - -There are usually some conditions that need to be satisfed before transitioning to the next state. Our templateset allows you to effortlessly add these conditions using the `preConditions` field. It is important to note that while defining pre-condition functions, you need to ensure they throw an exception when the condition fails. Add a pre-condition for a state using `addPreConditionForState` function. - -#### 2. Callbacks - -Before you transition to another state, there may be several actions you need to perform first. To accomodate for this, our templateset provides support for `callbacks`. `callbacks` for a given state are functions which are called before moving to the next state from the given state. Add a callback for a state using `addCallbackForState` function. - -#### 3. State transition - -Once pre-conditions are satisfied and the callbacks have been executed, we are ready to perform our state transition. - -Generally in a state transition, there is some business logic to be executed, followed by the actual change of state. Both these steps are bundled in a function, let's call such a function a transition function for the state. This transition function should be called when you want to transition from the given state. - -To build your transition function - all you need to do is define the business logic you want to execute before the state transition. To perform the actual state transition, you can simply call the `transitionState` function. - -The `transitionState` function we provide does all the heavy lifting of a state transition for you (for example: checking the preconditions, execution of callbacks, etc.). It also verifies all the edge conditions associated with state transitions so you don't need to worry about them. - -After you have defined your transition function for a state, you can calculate its function signature and set the `preFunction` field on the state to the calculated function signature. You can do this by calling `setPreFunctionForState` defined in the `StateMachine.sol` contract. - -### History of state transitions - -To have more transparency, our templateset also records the history of state transtions. - -We use a `StateTransition` struct to store information on a state transition. It is defined in the `StateMachine.sol` contract as: - -```solidity -struct StateTransition { - bytes32 fromState; - bytes32 toState; - address actor; - uint256 timestamp; -} -``` - -The history is stored as an array of `StateTransition`s. To view the transition at a particular index in the `history` array, you can use the `getHistory` function defined in the `StateMachine.sol` contract. - -You can also get the length of the `history` array using `getHistoryLength` function. - -To view the while history, you could get the length of the history array using `getHistoryLength` and call `getHistory` for each index in the array. - -## Usage - -### 1. Setting up the state machine states and flow - -For your convenience the Generic.sol template contract has all the necessary boilerplate code set up. So modify the different states and their relationships at your leisure. - -#### Creating states - -```solidity -// Create the variable -bytes32 public constant STATE_START = "STATE_START"; - -// use the createState helper inside the setupStateMachine function -function setupStateMachine(address adminAddress) internal override { - ... - createState(STATE_START); - ... - // set the correct state as the starting state - setInitialState(STATE_START); -} -``` - -#### Defining flow and roles - -```solidity -// Add next states to existing states to define flow -// Add Roles to state -function setupStateMachine(address adminAddress) internal override { - ... - addNextStateForState(STATE_START, STATE_END); - addRoleForState(STATE_START, ROLE_ADMIN, adminAddress); - ... - -} -``` - -### 2. Understanding the deployment process and deploying the contract - -Before we dive in you should know that the `Generic.sol` contract extends from the `StateMachineMetadata.sol` contract. -It's an interface on top of the base `StateMachine.sol` contract that allows linking metadata to a contract. -The setup for this takes place during the deployment of the contract. So let's do just that. - -Now when deploying the contract you may want to bind some IPFS data to it. A potential use case for this could be lifecycle tracing of a vehicle for example. So you could define a state machine that describes the various states a vehicle goes through (manufacturing, maintenance, etc...), but the vehicle itself has several unchanging attributes that don't need to be stored on-chain (f.e. a repair manual). IPFS is perfect for that. - -Let's look at the constructor of our `Generic.sol` contract to get an idea of the inputs it will need for deployment: - -```solidity - constructor( - uint256 entityId, - string memory ipfsHash, - string memory baseURI - ) { - address adminAddress = msg.sender; - _roles = [ROLE_ADMIN, ROLE_MANUFACTURER, ROLE_ONE, ROLE_TWO, ROLE_THREE, ROLE_FOUR]; - _setRoleAdmin(ROLE_ADMIN, DEFAULT_ADMIN_ROLE); - _grantRole(DEFAULT_ADMIN_ROLE, adminAddress); - setupStateMachine(adminAddress); - _entityId = entityId; - _baseURI = baseURI; - _setEntityURI(_entityId, ipfsHash); - } -``` - -Since the binding of the metadata is key-value based, you can see the entityId being the key and the value being the url/ipfshah or any other identifier to retrieve your metadata from the web (for example the unique suffix of a wetransfer link). The baseURI is an optional prefix that will be attached to the passed identifier (here ipfsHash). This baseURI will be `ipfs://` here, indicating the character of the metadata. - -The reason we want to use an entityId as key to retrieve the bound value is to provide flexibility to the end user. F.e., if only the deployer knows the key, then only he can retrieve the value. Or maybe you want to extend the functionalities of the `StateMachineMetadata.sol` contract, allowing users to add metadata later on etc... - -Your entityId can be any slug you want. But we recommend using a crypto library to generate a unique 32 bytes long one at least, for obvious reasons. - -Now to deploy our contract you define an entityId and the data you want to upload to IPFS: - -```typescript -// This identifier is used as a key to attach metadata to the smart contract -// See StateMachineMetadata.sol for more info -// This value is hardcoded here to make graph indexing of the metadata possible -export const entityId = 3073193977; // crypto.randomBytes(32).readUInt32LE() - -// Let's define the metadata for our entity that we want to upload to IPFS -const metadata = { - param1: 'param1', - param2: 'param2', -}; - -// using our hardhat task to upload the data to IPFS -const jsonCid: string = await run('ipfs-upload-string', { - data: JSON.stringify(metadata), - ipfspath: `/generic-statemachine/metadata/metadata-${entityId}.json`, - ipfsnode, -}); - -// Then we deploy -const statemachine = await factory.deploy(BigNumber.from(entityId), jsonCid, 'ipfs://'); -``` - -### 3. Indexing on-chain data - -#### statemachinemetadata Indexing Module - -The statemachinemetadata indexing module has 3 main and 1 helper file: - -1. `subgraph/datasource/statemachinemetadata.gql.json` - Schema definition file -2. `subgraph/datasource/statemachinemetadata.yaml` - Subgraph manifest template file -3. `subgraph/datasource/statemachinemetadata.ts` - Mapping functions file - -And a helper file at `subgraph/fetch/statemachinemetadata.ts` - -#### 1. statemachinemetadata Schema - -We define 2 entities in the schema: - -1. `StateMachineMetadataContract` - - This is the entity modelling the `Generic.sol` statemachine contract. - - - The field `currentState` holds the current state the entity represented by the statemachine is in. - - The `stateTransitions` field hold a list of transitions that the entity has gone through. - - The two fields `param1` and `param2` seem confusing, since we don't see them as state variables on the `Generic.sol` contract or any of the contracts that `Generic.sol` inherits. This is because they are not state variables on the contract, but metadata for the entity that we have uploaded on IPFS. - -You can see them being set in the deploy script at `deploy > 00_deploy_StateMachine.ts`. - -If you wish to change the name of the parameters in the metadata from `param1`, `param2` to your custom field name in the deploy script, please be sure to propagate the changes in: - -a. schema definition at `subgraph/datasource/statemachinemetadata.gql.json` - -b. handler at `subgraph/datasource/statemachinemetadata.ts` - -2. `StateTransition` - -This is the entity representing the `Transition` event emitted by the `Generic.sol` statemachine contract. -Its fields represent the information emitted by the event. - -#### 2. statemachinemetadata Subgraph Manifest Template - -The field of interest to us in the subgraph manifest template at `subgraph/datasource/statemachinemetadata.yaml` is the `eventHandlers` field. - -Here, we list the events we want to listen to, as given here: - -```yaml -- event: Transition(address,bytes32,bytes32) - handler: handleTransitions -``` - -We listen to the `Transition` event emitted by the `Generic` statemachine contract. When that event is emitted, we call the `handleTransitions` mapping function defined in `subgraph/datasource/statemachinemetadata.ts` - -#### 3. statemachinemetadata Mapping function - -The mapping functions for the `statemachinemetadata` indexing module are defined in `subgraph/datasource/statemachinemetadata.ts` - -It is advisable to run `graph:config`, `graph:compile`, and `graph:codegen` tasks before playing around with this file to generate types and classes.\*\* - -Now that we have our types and classes, let's see how they are used. - -The `handleTransitions` handler takes in the `Transition` event. Then, it performs three main tasks: - -- fetches the `StateMachineMetadataContract` entity which emitted the `Transition` event - -To do this, a custom fetcher was written (`./subgraph/fetch/statemachinemetadata.ts`). - -Inside the fetcher, you will see the hard coded `entityId` from the deploy script `deploy > 00_deploy_StateMachine` again: - -```typescript -const try_entityURI = sm.try_entityURI(BigInt.fromString(`3073193977`)); -``` - -We fetch the metadata from IPFS using this entity ID and populate the fields on the `StateMachineMetadataContract` entity accordingly: - -```typescript -const try_entityURI = sm.try_entityURI(BigInt.fromString(`3073193977`)); -const metadataURI = try_entityURI.reverted ? '' : try_entityURI.value; - -if (metadataURI.includes('ipfs://')) { - const ipfsHash = metadataURI.replace('ipfs://', ''); - const metadataURIBytes = ipfs.cat(ipfsHash); - if (metadataURIBytes) { - const metadataURIContent = json.try_fromBytes(metadataURIBytes); - if (metadataURIContent.isOk && metadataURIContent.value.kind == JSONValueKind.OBJECT) { - const entityMetadata = metadataURIContent.value.toObject(); - - const param1 = entityMetadata.get('param1'); - const param2 = entityMetadata.get('param2'); - - contract.param1 = param1 ? param1.toString() : null; - contract.param2 = param2 ? param2.toString() : null; - - contract.save(); - } - } -} -``` - -It's really important that this entityId matches with the one defined in the deployment script. Also we want to point out that general indexing logic can be re-used based on the protocol prefix we defined in the deployment as well (`ipfs://`). - -- Then, we create a new `StateTransition` entity to keep a track of the events emitted by the contract -- Finally, we save the changes in the storage - -## Note - -\*\* Before using this file, it is recommended to run the tasks `graph:config`, `graph:compile` and `graph:codegen`. - -The `graph:codegen` task is where the types/classes are generated based on the entities defined in the schema (at `subgraphs > x.gql.json`). These types/classes are imported and used in the mapping functions. - -Without running this task, you will run into several `Cannot find module..` linter errors while trying to use this file. diff --git a/docs/blockchain-guides/6_Polygon-Edge/_category_.json b/docs/blockchain-guides/6_Polygon-Edge/_category_.json deleted file mode 100644 index 619967e0..00000000 --- a/docs/blockchain-guides/6_Polygon-Edge/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Polygon Edge", - "position": 6 -} diff --git a/src/components/CardComponents.tsx b/src/components/CardComponents.tsx index a3a6056e..95a93230 100644 --- a/src/components/CardComponents.tsx +++ b/src/components/CardComponents.tsx @@ -20,7 +20,12 @@ export function CardSection({ className?: string; }) { return ( -
+
{title && {title}} {description &&

{description}

}
{children}
@@ -62,8 +67,7 @@ export function Card({ + title={tag.description}> {tag.label}
diff --git a/src/components/ContentCard.module.css b/src/components/ContentCard.module.css index 53729825..f57a6666 100644 --- a/src/components/ContentCard.module.css +++ b/src/components/ContentCard.module.css @@ -56,7 +56,7 @@ a:hover { } .riImage { - width: 110px; /* Adjust the size */ + width: 100px; /* Adjust the size */ height: 100px; /* Adjust the size */ border-radius: var(--ifm-global-radius); margin-bottom: 0px; /* Add some space below the image */ diff --git a/src/components/ContentCard.tsx b/src/components/ContentCard.tsx index 4274c6ff..0426c4b1 100644 --- a/src/components/ContentCard.tsx +++ b/src/components/ContentCard.tsx @@ -16,7 +16,13 @@ const ContentCard = (props: PropsWithChildren) => {
- {props.image && {props.title}} + {props.image && ( + {props.title} + )}
diff --git a/static/img/about-settlemint/blockchain-logos/hedera-logo.png b/static/img/about-settlemint/blockchain-logos/hedera-logo.png new file mode 100644 index 00000000..18e25c57 Binary files /dev/null and b/static/img/about-settlemint/blockchain-logos/hedera-logo.png differ