Clarify current state of DA layer support in Paima

PaimaStudios · Oct 20, 2023 · 9a7270d · 9a7270d
1 parent fdd315a
commit 9a7270d
Show file tree

Hide file tree

Showing 3 changed files with 7 additions and 5 deletions.
diff --git 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
@@ -81,9 +81,9 @@ Whether you are deploying or simply performing some admin functions, most of the
   - `supply` &ndash; the maximum number of NFTs that can be minted;
   - `owner` &ndash; 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` &ndash; intended primarily for the "add minter" admin function, also used during deployment if not empty;
-  - `baseUri`
+  - `baseUri` &ndash; the base URI used for all your NFTs (keep as "" if you don't want to use this feature)
 - `NftSale`:
-  - `price` &ndash; 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` &ndash; 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` &ndash; decimals of the underlying base currency of the chain, used for price calculation;
   - `owner` &ndash; see `Nft`'s `owner` field;

diff --git 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/',
     },
     {