diff --git a/docs/home/0-what-is-paima-engine.md b/docs/home/0-what-is-paima-engine.md index 7aecafb5..e7491226 100644 --- a/docs/home/0-what-is-paima-engine.md +++ b/docs/home/0-what-is-paima-engine.md @@ -13,13 +13,15 @@ Notably, its key features are that it 3. Enables cross-wallet gameplay, meaning you can deploy your game to one chain yet have it be playable from across many blockchains 4. Speeds you up to make weekly releases a reality instead of most web3 games which are release-and-pray +Paima supports any EVM chain, and comes with some features for multichain support as well. + # Key technologies that enable this If you prefer explanations in video form, we have [a high-level summary video](https://www.youtube.com/watch?v=HtvemijxF-0) that explains some of the core benefits of Paima Engine. ## Sovereign rollups -Paima is a framework for creating app-specific layer 2s (L2s) as sovereign rollups. That is to say: apps publish transactions to a blockchain for ordering and data availability, but uses its own code to determine the correct app state +Paima is a framework for creating app-specific layer 2s (L2s) as sovereign rollups. That is to say: apps publish transactions to a blockchain for ordering and data availability, but uses its own code to determine the correct app state. ## State machines as Sovereign Rollup L2s @@ -104,7 +106,7 @@ Although Paima allows games to subsidize gameplay, games can also choose to spec ### Data availability layer support -Projects may want the blockchain used as the Data Availability (DA) layer to be different from the primary chain used for their app (either as a volition or a validium) +Paima, by default, uses EVM both as the settlement and Data Availability (DA) layer. However, some games may want to separate these concerns by using a different layers for settlement and DA (either as a volition or a validium) To enable this, Paima will facilitate storing state machine inputs on a DA layer, significantly lowering costs for data-hungry use-cases. We plan to integrate Avail and Celestia for this diff --git a/docs/home/1-setup/3-deploying-your-stateful-nft.md b/docs/home/1-setup/3-deploying-your-stateful-nft.md index 8f9d3818..8e09802c 100644 --- a/docs/home/1-setup/3-deploying-your-stateful-nft.md +++ b/docs/home/1-setup/3-deploying-your-stateful-nft.md @@ -81,9 +81,9 @@ Whether you are deploying or simply performing some admin functions, most of the - `supply` – the maximum number of NFTs that can be minted; - `owner` – the owner of the contract. Only used for the "transfer ownership" admin function, during deployment, the address of the deploying wallet will be used; - `minter` – intended primarily for the "add minter" admin function, also used during deployment if not empty; - - `baseUri` + - `baseUri` – the base URI used for all your NFTs (keep as "" if you don't want to use this feature) - `NftSale`: - - `price` – the price of buying an NFT through the sale contract, used both for `NativeNftSale` and `Erc20NftSale`. For native sale the price is multiplied by `10^decimals`; + - `price` – the price of buying an NFT through the sale contract, used both for `NativeNftSale` and `Erc20NftSale`. For native sale the price is multiplied by `10^decimals`. Ex: `price: 3, decimals: 5` → `300000`; - `NativeNftSale`: - `decimals` – decimals of the underlying base currency of the chain, used for price calculation; - `owner` – see `Nft`'s `owner` field; diff --git a/sidebars.js b/sidebars.js index d15752c4..fadd7637 100644 --- a/sidebars.js +++ b/sidebars.js @@ -11,7 +11,7 @@ const sidebars = { }, { type: 'link', - label: 'Paima Engine code', + label: 'Paima Engine Code', href: 'https://github.com/PaimaStudios/paima-engine/', }, {