@goplausible/algorand-mcp 3.0.7

package/dist/resources/knowledge/taxonomy/developer:docs:details:indexer.md

@@ -0,0 +1,472 @@
+title: Indexer
+
+This guide explains how to search the Algorand Blockchain using the Indexer. This Indexer is not part of the Algorand node and requires a separate binary download. See the [Indexer Install Guide](../run-a-node/setup/indexer.md) for instructions on installing and configuring the new Indexer.
+
+![Block Proposal](../imgs/indexerv2.png)
+<center>*Algorand V2 Indexer*</center>
+
+The primary purpose of this Indexer is to provide a REST API interface of API calls to support searching the Algorand Blockchain. The Indexer REST APIs retrieve the blockchain data from a [PostgreSQL](https://www.postgresql.org/) compatible database that must be populated. This database is populated using the same indexer instance or a separate instance of the indexer which must connect to the algod process of a running Algorand node to read block data. This node must also be an Archival node to make searching the entire blockchain possible. 
+
+The Indexer provides a set of REST API calls for searching blockchain Transactions, Accounts, Assets and Blocks. Each of these calls also provides several filter parameters to support refining searches. The latest Algorand native SDKs (Python, JavaScript, Go, and Java) provide similar functionality. These REST calls are based on the Open API specification and are described in the REST SDK reference documentation. 
+
+See the full description of endpoints available in the [indexer docs](../rest-apis/indexer.md).
+
+# SDK client instantiations
+
+=== "JavaScript"
+    <!-- ===JSSDK_INDEXER_CREATE_CLIENT=== -->
+	```javascript
+	const indexerToken = 'a'.repeat(64);
+	const indexerServer = 'http://localhost';
+	const indexerPort = 8980;
+	
+	const indexerClient = new algosdk.Indexer(
+	  indexerToken,
+	  indexerServer,
+	  indexerPort
+	);
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/indexer.ts#L15-L24)
+    <!-- ===JSSDK_INDEXER_CREATE_CLIENT=== -->
+
+=== "Python"
+    <!-- ===PYSDK_INDEXER_CREATE_CLIENT=== -->
+	```python
+	# instantiate indexer client
+	indexer_host = "http://localhost:8980"
+	indexer_token = "a" * 64
+	indexer_client = indexer.IndexerClient(
+	    indexer_token=indexer_token, indexer_address=indexer_host
+	)
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/indexer.py#L7-L13)
+    <!-- ===PYSDK_INDEXER_CREATE_CLIENT=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_INDEXER_CREATE_CLIENT=== -->
+	```java
+	String indexerHost = "http://localhost";
+	int indexerPort = 8980;
+	String indexerToken = "a".repeat(64);
+	IndexerClient indexerClient = new IndexerClient(indexerHost, indexerPort, indexerToken);
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/IndexerExamples.java#L12-L16)
+    <!-- ===JAVASDK_INDEXER_CREATE_CLIENT=== -->
+
+=== "Go"
+	<!-- ===GOSDK_INDEXER_CREATE_CLIENT=== -->
+	```go
+	// Create a new indexer client, configured to connect to out local sandbox
+	var indexerAddress = "http://localhost:8980"
+	var indexerToken = strings.Repeat("a", 64)
+	indexerClient, _ := indexer.MakeClient(
+		indexerAddress,
+		indexerToken,
+	)
+	
+	// Or, if necessary, pass alternate headers
+	
+	var indexerHeader common.Header
+	indexerHeader.Key = "X-API-Key"
+	indexerHeader.Value = indexerToken
+	indexerClientWithHeaders, err := indexer.MakeClientWithHeaders(
+		indexerAddress,
+		indexerToken,
+		[]*common.Header{&indexerHeader},
+	)
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/indexer/main.go#L15-L33)
+	<!-- ===GOSDK_INDEXER_CREATE_CLIENT=== -->
+
+!!! info 
+    When using cURL be aware that the parameters may need to be URL encoded. The SDKs handle the encoding of parameter data. 
+
+The indexer provides two primary ways to access information:
+
+1) Lookup a single item (a single account, a single transaction, a single block)
+   
+2) Search for items that match a query (transactions for > 100A and between round N and M)
+
+Each SDK provides methods for looking up or searching for transactions, assets, applications(smart contracts), and blocks. For a full list of method calls see the SDK docs:
+
+-  [Python](https://py-algorand-sdk.readthedocs.io/en/latest/algosdk/v2client/indexer.html)
+-  [JavaScript](https://algorand.github.io/js-algorand-sdk/classes/Indexer.html)
+-  [Java](https://algorand.github.io/java-algorand-sdk/com/algorand/algosdk/v2/client/indexer/package-summary.html) 
+-  [Go](https://pkg.go.dev/github.com/algorand/go-algorand-sdk/v2@v2.0.0/client/v2/indexer)
+
+# Lookup
+As an example, to get the details of a specific asset the indexer provides the `/assets/{asset-id}` REST call.  This call takes no parameters as the asset id is passed in the URL. This call returns the details of the asset and the round the results were calculated in. 
+
+=== "JavaScript"
+    <!-- ===JSSDK_INDEXER_LOOKUP_ASSET=== -->
+	```javascript
+	const indexer = getLocalIndexerClient();
+	const indexerAssetInfo = await indexer.lookupAssetByID(assetIndex).do();
+	console.log('Indexer Asset Info:', indexerAssetInfo);
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/asa.ts#L54-L57)
+    <!-- ===JSSDK_INDEXER_LOOKUP_ASSET=== -->
+
+=== "Python"
+    <!-- ===PYSDK_INDEXER_LOOKUP_ASSET=== -->
+	```python
+	# lookup a single asset
+	# by passing include_all, we specify that we want to see deleted assets as well
+	response = indexer_client.asset_info(asset_id, include_all=True)
+	print(f"Asset Info: {json.dumps(response, indent=2,)}")
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/indexer.py#L50-L54)
+    <!-- ===PYSDK_INDEXER_LOOKUP_ASSET=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_INDEXER_LOOKUP_ASSET=== -->
+	```java
+	Long asaId = 25l;
+	Response<AssetResponse> assetResponse = indexerClient.lookupAssetByID(asaId).execute();
+	Asset assetInfo = assetResponse.body().asset;
+	System.out.printf("Name for %d: %s\n", asaId, assetInfo.params.name);
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/IndexerExamples.java#L19-L23)
+    <!-- ===JAVASDK_INDEXER_LOOKUP_ASSET=== -->
+
+=== "Go"
+    <!-- ===GOSDK_INDEXER_LOOKUP_ASSET=== -->
+	```go
+	// query parameters
+	var assetId uint64 = 2044572
+	var minBalance uint64 = 50
+	
+	// Lookup accounts with minimum balance of asset
+	assetResult, _ := indexerClient.
+		LookupAssetBalances(assetId).
+		CurrencyGreaterThan(minBalance).
+		Do(context.Background())
+	
+	// Print the results
+	assetJson, _ := json.MarshalIndent(assetResult, "", "\t")
+	fmt.Printf(string(assetJson) + "\n")
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/indexer/main.go#L55-L68)
+    <!-- ===GOSDK_INDEXER_LOOKUP_ASSET=== -->
+
+=== "cURL"
+    <!-- ===CURL_INDEXER_LOOKUP_ASSET=== -->
+	``` bash
+    $ curl "localhost:8980/v2/assets/2044572" 
+    ```
+    <!-- ===CURL_INDEXER_LOOKUP_ASSET=== -->
+
+
+
+# Search
+Searching is similar to lookup with the ability to return multiple or filtered results. This example searches for transactions based on a few filters. 
+
+=== "JavaScript"
+    <!-- ===JSSDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+	```javascript
+	const transactionInfo = await indexerClient
+	  .searchForTransactions()
+	  .currencyGreaterThan(100)
+	  .do();
+	console.log(transactionInfo.transactions.map((t) => t.id));
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/indexer.ts#L33-L38)
+    <!-- ===JSSDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+
+=== "Python"
+    <!-- ===PYSDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+	```python
+	response = indexer_client.search_transactions(
+	    min_amount=10, min_round=1000, max_round=1500
+	)
+	print(f"Transaction results: {json.dumps(response, indent=2)}")
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/indexer.py#L57-L61)
+    <!-- ===PYSDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+	```java
+	Response<TransactionsResponse> transactionSearchResult = indexerClient.searchForTransactions()
+	        .minRound(10l).maxRound(500l).currencyGreaterThan(10l).execute();
+	TransactionsResponse txResp = transactionSearchResult.body();
+	System.out.printf("Found %d transactions that match criteria\n", txResp.transactions.size());
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/IndexerExamples.java#L26-L30)
+    <!-- ===JAVASDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+
+=== "Go"
+    <!-- ===GOSDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+	```go
+	// query parameters
+	var transactionMinAmount uint64 = 10
+	
+	// Query
+	transactionResult, _ := indexerClient.
+		SearchForTransactions().
+		CurrencyGreaterThan(transactionMinAmount).
+		Do(context.Background())
+	
+	// Print results
+	transactionJson, _ := json.MarshalIndent(transactionResult, "", "\t")
+	fmt.Printf(string(transactionJson) + "\n")
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/indexer/main.go#L73-L85)
+    <!-- ===GOSDK_INDEXER_SEARCH_MIN_AMOUNT=== -->
+
+=== "cURL"
+    <!-- ===CURL_INDEXER_SEARCH_MIN_AMOUNT=== -->
+	```bash
+    $ curl "localhost:8980/v2/transactions?currency-greater-than=10"
+    ```
+    <!-- ===CURL_INDEXER_SEARCH_MIN_AMOUNT=== -->
+
+# Pagination
+
+When searching large amounts of blockchain data often the results may be too large to process in one given operation. In fact, the indexer imposes hard limits on the number of results returned for specific searches.  The default limits for these searches are summarized in the table below.
+
+| Search Type  | Maximum number of results per search  |
+| ------------- | ------------- |
+| API Resources Per Account | 1,000 |
+| Transactions Search | 1,000 |
+| Accounts Search | 100 |
+| Assets Search | 100 |
+| Balances Search | 1,000 |
+| Applications Search | 100 |
+
+When trying to find specific transactions, the Indexer supplies a pagination method that allows separating the results into several REST calls to return larger result sets. When used with the limit parameter the results for large data sets can be returned in expected result counts.
+
+For example, adding a limit parameter of 5 to the previous call will cause only 5 results to be returned in each page. To get the next 5 transactions simply add the next-token as a parameter to the next REST call. The parameter is named `next` and this token is only good for the next 5 results.
+
+=== "JavaScript"
+    <!-- ===JSSDK_INDEXER_PAGINATE_RESULTS=== -->
+	```javascript
+	let nextToken = '';
+	
+	// nextToken will be undefined if we reached the last page
+	while (nextToken !== undefined) {
+	  // eslint-disable-next-line no-await-in-loop
+	  const response = await indexerClient
+	    .searchForTransactions()
+	    .limit(5)
+	    .currencyGreaterThan(10)
+	    .nextToken(nextToken)
+	    .do();
+	
+	  nextToken = response['next-token'];
+	  const txns = response.transactions;
+	  if (txns.length > 0)
+	    console.log(`Transaction IDs: ${response.transactions.map((t) => t.id)}`);
+	}
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/indexer.ts#L41-L58)
+    <!-- ===JSSDK_INDEXER_PAGINATE_RESULTS=== -->
+
+=== "Python"
+    <!-- ===PYSDK_INDEXER_PAGINATE_RESULTS=== -->
+	```python
+	
+	nexttoken = ""
+	has_results = True
+	page = 0
+	
+	# loop using next_page to paginate until there are
+	# no more transactions in the response
+	while has_results:
+	    response = indexer_client.search_transactions(
+	        min_amount=10, min_round=1000, max_round=1500, next_page=nexttoken
+	    )
+	
+	    has_results = len(response["transactions"]) > 0
+	
+	    if has_results:
+	        nexttoken = response["next-token"]
+	        print(f"Tranastion on page {page}: " + json.dumps(response, indent=2))
+	
+	    page += 1
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/indexer.py#L64-L83)
+    <!-- ===PYSDK_INDEXER_PAGINATE_RESULTS=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_INDEXER_PAGINATE_RESULTS=== -->
+	```java
+	String nextToken = "";
+	boolean hasResults = true;
+	// Start with empty nextToken and while there are
+	// results in the transaction results, query again with the next page
+	while (hasResults) {
+	    Response<TransactionsResponse> searchResults = indexerClient.searchForTransactions().minRound(1000l)
+	            .maxRound(1500l).currencyGreaterThan(10l).next(nextToken).execute();
+	    TransactionsResponse txnRes = searchResults.body();
+	    //
+	    // ... do something with transaction results
+	    //
+	    hasResults = txnRes.transactions.size() > 0;
+	    nextToken = txnRes.nextToken;
+	}
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/IndexerExamples.java#L33-L47)
+    <!-- ===JAVASDK_INDEXER_PAGINATE_RESULTS=== -->
+
+=== "Go"
+    <!-- ===GOSDK_INDEXER_PAGINATE_RESULTS=== -->
+	```go
+	var nextToken = ""
+	var numTx = 1
+	var numPages = 1
+	var pagedMinAmount uint64 = 10
+	var limit uint64 = 1
+	
+	for numTx > 0 {
+		// Query
+		pagedResults, err := indexerClient.
+			SearchForTransactions().
+			CurrencyGreaterThan(pagedMinAmount).
+			Limit(limit).
+			NextToken(nextToken).
+			Do(context.Background())
+		if err != nil {
+			return
+		}
+		pagedTransactions := pagedResults.Transactions
+		numTx = len(pagedTransactions)
+		nextToken = pagedResults.NextToken
+	
+		if numTx > 0 {
+			// Print results
+			pagedJson, err := json.MarshalIndent(pagedTransactions, "", "\t")
+			if err != nil {
+				return
+			}
+			fmt.Printf(string(pagedJson) + "\n")
+			fmt.Println("End of page : ", numPages)
+			fmt.Println("Transaction printed : ", len(pagedTransactions))
+			fmt.Println("Next Token : ", nextToken)
+			numPages++
+		}
+	}
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/indexer/main.go#L88-L122)
+    <!-- ===GOSDK_INDEXER_PAGINATE_RESULTS=== -->
+
+=== "cURL"
+    <!-- ===CURL_INDEXER_PAGINATE_RESULTS=== -->
+	```bash
+    $ curl "localhost:8980/v2/transactions?currency-greater-than=10&limit=5"
+    # note the "next-token" field in the most recent results and supply the value to the "next" parameter
+    $ curl "localhost:8979/v2/transactions?currency-greater-than=10&limit=5&next=cAoBAAAAAAAAAAAA"
+    ```
+    <!-- ===CURL_INDEXER_PAGINATE_RESULTS=== -->
+
+Results showing "next-token"
+```json
+{
+   "next-token" : "cAoBAAAAAAAAAAAA",
+   "current-round" : 7050272,
+   "transactions" : []
+}
+```
+
+A new next token will be returned to get the next five. This token acts as a marker in the current result set and allows the next call to pick up where the last search ended. We note that the 'limit' parameter can also be used to specify a larger (rather than smaller) results set than the defaults above. These limits are shown in the following table and are per call, not the total result set.
+
+| Search Type  | Search Limit with a limit parameter |
+| ------------- | ------------- |
+| Transaction Search | 10000 |
+| Account Search | 1000 |
+| Asset Search | 1000 |
+| Asset Balance Search | 10000 |
+
+The following REST calls support paginated results.
+
+* `/accounts` - Search for specific accounts.
+* `/accounts/{account-id}/transactions` - Search for transactions for a specific account.
+* `/accounts/{account-id}/created-apps` - Search for created applications for a specific account.
+* `/accounts/{account-id}/created-assets` - Search for created assets for a specific account.
+* `/accounts/{account-id}/assets` - Search for assets on a specific account.
+* `/accounts/{account-id}/apps-local-state` - Search for application local state for a specific account.
+* `/assets` - Search Assets.
+* `/assets/{asset-id}/balances` - Search Asset balances.
+* `/assets/{asset-id}/transactions` - Search for Transactions with a specific Asset.
+* `/transactions` - Search all transactions
+
+# Note field searching
+Every transaction has the ability to add up to a 1kb note in the note field. Several of the REST APIs provide the ability to search for a prefix that is present in the note field, meaning that the note starts with a specific string. This can be a very powerful way to quickly locate transactions that are specific to an application. The REST calls that support prefix searching are the following.
+
+* `/accounts/{account-id}/transactions` - Search for a prefix for a specific accounts transactions.
+* `/assets/{asset-id}/transactions` - Search for a prefix for a specific Asset Id.
+* `/transactions` - Search all Transactions for a specific transaction note field prefix.
+
+To search for a specific prefix use the `note-prefix` parameter. For the Javascript and direct REST API, the value needs to be base64 encoded to return results. (The other SDKs perform the base64 encoding for you.) For example, if the contents of the note field started with the string “showing prefix searches”, encoding the beginning of that sentence using python like the following:
+
+``` bash
+$ python3 -c "import base64;print(base64.b64encode('showing prefix'.encode()))"
+```
+
+This will return an encoded value of `c2hvd2luZyBwcmVmaXg=`.  This value can then be passed to the search. To search all transactions use the following command.
+
+=== "JavaScript"
+    <!-- ===JSSDK_INDEXER_PREFIX_SEARCH=== -->
+	```javascript
+	const txnsWithNotePrefix = await indexerClient
+	  .searchForTransactions()
+	  .notePrefix(Buffer.from('Hello'))
+	  .do();
+	console.log(
+	  `Transactions with note prefix "Hello" ${JSON.stringify(
+	    txnsWithNotePrefix,
+	    undefined,
+	    2
+	  )}`
+	);
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/indexer.ts#L80-L91)
+    <!-- ===JSSDK_INDEXER_PREFIX_SEARCH=== -->
+
+=== "Python"
+    <!-- ===PYSDK_INDEXER_PREFIX_SEARCH=== -->
+	```python
+	note_prefix = "showing prefix".encode()
+	response = indexer_client.search_transactions(note_prefix=note_prefix)
+	print(f"result: {json.dumps(response, indent=2)}")
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/indexer.py#L86-L89)
+    <!-- ===PYSDK_INDEXER_PREFIX_SEARCH=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_INDEXER_PREFIX_SEARCH=== -->
+	```java
+	byte[] prefix = new String("showing prefix").getBytes();
+	Response<TransactionsResponse> prefixResults = indexerClient.searchForTransactions().notePrefix(prefix)
+	        .execute();
+	// ...
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/IndexerExamples.java#L50-L54)
+    <!-- ===JAVASDK_INDEXER_PREFIX_SEARCH=== -->
+
+=== "Go"
+    <!-- ===GOSDK_INDEXER_PREFIX_SEARCH=== -->
+	```go
+	// Parameters
+	var notePrefix = "showing prefix"
+	
+	// Query
+	prefixResult, _ := indexerClient.
+		SearchForTransactions().
+		NotePrefix([]byte(notePrefix)).
+		Do(context.Background())
+	
+	// Print results
+	prefixJson, _ := json.MarshalIndent(prefixResult, "", "\t")
+	fmt.Printf(string(prefixJson) + "\n")
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/indexer/main.go#L125-L137)
+    <!-- ===GOSDK_INDEXER_PREFIX_SEARCH=== -->
+
+=== "cURL"
+    <!-- ===CURL_INDEXER_PREFIX_SEARCH=== -->
+	```bash
+    python3 -c "import base64;print(base64.b64encode('showing prefix'.encode()))"
+    $ curl "localhost:8980/v2/transactions?note-prefix=c2hvd2luZyBwcmVmaXg=" | json_pp
+    ```
+    <!-- ===CURL_INDEXER_PREFIX_SEARCH=== -->

package/dist/resources/knowledge/taxonomy/developer:docs:details:parameter_tables.md

@@ -0,0 +1,84 @@
+title: Algorand parameter tables
+[comment]: <> (generated from: https://docs.google.com/spreadsheets/d/12E_B6AYBfhrOoylO8NZysqKns4rHKklV8I0fejiwMXE)
+
+## Minimum balance
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Default|0.1 Algos|[reference](./accounts/index.md#minimum-balance)|MinBalance||
+|Opt-in ASA|+ 0.1 Algos|[reference](./asa.md#assets-overview)|MinBalance||
+|Created ASA|+ 0.1 Algos|[reference](./asa.md#assets-overview)|MinBalance|creator of ASA does not need to opt in|
+|Opt-in Application|(see below)|||creator of application only needs to opt in if they use local state|
+|Created Application|(see below)||||
+
+## Minimum balance for smart contract
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Per page application creation fee|0.1 Algos|[reference](./dapps/smart-contracts/apps/index.md#minimum-balance-requirement-for-a-smart-contract)|AppFlatParamsMinBalance||
+|Flat for application opt-in|0.1 Algos|[reference](./dapps/smart-contracts/apps/index.md#minimum-balance-requirement-for-a-smart-contract)|AppFlatOptInMinBalance||
+|Per state entry|0.025 Algos|[reference](./dapps/smart-contracts/apps/index.md#minimum-balance-requirement-for-a-smart-contract)|SchemaMinBalancePerEntry||
+|Addition per integer entry|0.0035 Algos|[reference](./dapps/smart-contracts/apps/index.md#minimum-balance-requirement-for-a-smart-contract)|SchemaUintMinBalance||
+|Addition per byte slice entry|0.025 Algos|[reference](./dapps/smart-contracts/apps/index.md#minimum-balance-requirement-for-a-smart-contract)|SchemaBytesMinBalance||
+|Per Box created|0.0025 Algos|[reference](./dapps/smart-contracts/apps/index.md#minimum-balance-requirement-for-a-smart-contract)|BoxFlatMinBalance||
+|Per byte in box created|0.0004 Algos|[reference](./dapps/smart-contracts/apps/index.md#minimum-balance-requirement-for-a-smart-contract)|BoxByteMinBalance|Includes the length of the key|
+
+## Transaction fee
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Minimum transaction fee, in all cases|0.001 Algos|[reference](./transactions/index.md#fees)|MinTxnFee||
+|Additional minimum constraint if congestion|additional fee per byte|[reference](./transactions/index.md#fees)|-||
+
+## Others
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Max number transactions in a group / atomic transfer|16|[reference](./atomic_transfers.md)|MaxTxGroupSize||
+|Max number of inner transactions|256|[reference](https://developer.algorand.org/docs/get-details/dapps/smart-contracts/apps/#inner-transactions)|MaxInnerTransactions|Whilst the actual value is 16, inner transaction pooling multiplies this value by MaxTxGroupSize.|
+|Maximum size of a block|5000000 bytes|-|MaxTxnBytesPerBlock||
+|Maximum size of note|1024 bytes|-|MaxTxnNoteBytes||
+|Maximum transaction life|1000 rounds|[reference](./transactions/index.md#setting-first-and-last-valid)|MaxTxnLife||
+
+## ASA constraints
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Max number of ASAs (create and opt-in)|Unlimited|[reference](./asa.md)|MaxAssetsPerAccount||
+|Max asset name size|32 bytes|[reference](./asa.md)|MaxAssetNameBytes||
+|Max unit name size|8 bytes|[reference](./asa.md)|MaxAssetUnitNameBytes||
+|Max URL size|96 bytes|[reference](./asa.md)|MaxAssetURLBytes||
+|Metadata hash|32 bytes|[reference](./asa.md)||padded with zeros|
+
+## Smart signature constraints
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Max size of compiled TEAL code combined with arguments|1000 bytes|[reference](../dapps/avm/teal/specification#execution-environment-for-logicsigs)|LogicSigMaxSize||
+|Max cost of TEAL code|20000|[reference](../dapps/avm/teal/specification#execution-environment-for-logicsigs)|LogicSigMaxCost||
+
+## Smart contract constraints
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Page size of compiled approval + clear TEAL code|2048 bytes|[reference](./dapps/avm/teal/index.md#dynamic-operational-cost-of-teal-opcodes)|MaxAppProgramLen|by default, each application has a single page|
+|Max extra app pages |3|[reference](./dapps/smart-contracts/apps/index.md#creating-the-smart-contract)|MaxExtraAppProgramPages|an application can "pay" for additional pages via minimum balance|
+|Max cost of approval TEAL code|700|[reference](./dapps/avm/teal/index.md#dynamic-operational-cost-of-teal-opcodes)|MaxAppProgramCost||
+|Max cost of clear TEAL code|700|[reference](./dapps/avm/teal/index.md#dynamic-operational-cost-of-teal-opcodes)|MaxAppProgramCost||
+|Max number of scratch variables|256|[reference](../dapps/avm/teal/specification/#scratch-space)|||
+|Max depth of stack|1000|[reference](../dapps/avm/teal/specification/#the-stack)|MaxStackDepth||
+|Max number of arguments|16|[reference](./dapps/smart-contracts/apps/index.md#passing-arguments-to-stateful-smart-contracts)|MaxAppArgs||
+|Max combined size of arguments|2048 bytes|[reference](./dapps/smart-contracts/apps/index.md#passing-arguments-to-stateful-smart-contracts)|MaxAppTotalArgLen||
+|Max number of global state keys|64|[reference](./dapps/smart-contracts/apps/index.md#creating-the-smart-contract)|MaxGlobalSchemaEntries||
+|Max number of local state keys|16|[reference](./dapps/smart-contracts/apps/index.md#creating-the-smart-contract)|MaxLocalSchemaEntries||
+|Max number of log messages|32|[reference](../dapps/avm/teal/opcodes/#log)|MaxLogCalls||
+|Max size of log messages|1024|[reference](../dapps/avm/teal/opcodes/#log)|MaxLogSize||
+|Max key size|64 bytes|[reference](./dapps/smart-contracts/apps/index.md#creating-the-smart-contract)|MaxAppKeyLen||
+|Max []byte value size|128 bytes|[reference](./dapps/smart-contracts/apps/index.md#creating-the-smart-contract)|MaxAppBytesValueLen||
+|Max key + value size|128 bytes|[reference](./dapps/smart-contracts/apps/index.md#creating-the-smart-contract)|MaxAppSumKeyValueLens||
+|Max number of foreign accounts|4|[reference](./dapps/smart-contracts/apps/index.md#stateful-contract-arrays)|MaxAppTxnAccounts||
+|Max number of foreign ASAs|8|[reference](./dapps/smart-contracts/apps/index.md#stateful-contract-arrays)|MaxAppTxnForeignAssets||
+|Max number of foreign applications|8|[reference](./dapps/smart-contracts/apps/index.md#stateful-contract-arrays)|MaxAppTxnForeignApps||
+|Max number of foreign accounts + ASAs + applications + box storage|8|[reference](./dapps/smart-contracts/apps/index.md#stateful-contract-arrays)|MaxAppTotalTxnReferences||
+|Max number of created applications|Unlimited|[reference](./dapps/smart-contracts/apps/index.md#opt-into-the-smart-contract)|MaxAppsCreated||
+|Max number of opt-in applications|Unlimited|[reference](./dapps/smart-contracts/apps/index.md#opt-into-the-smart-contract)|MaxAppsOptedIn||
+
+## Box Constraints
+|Name|Current value|Developer doc|Consensus parameter name in (.go)|Note|
+|-|-|-|-|-|
+|Max size of box | 32768 |[reference](./dapps/smart-contracts/apps/index.md#box-storage)|MaxBoxSize|Does not include name/key length. That is capped by MaxAppKeyLen|
+|Max box references | 8 |[reference](./dapps/smart-contracts/apps/index.md#smart-contract-arrays)|MaxAppBoxReferences||
+|Bytes per Box reference | 1024 |[reference](./dapps/smart-contracts/apps/index.md#smart-contract-arrays)|BytesPerBoxReference||

package/dist/resources/knowledge/taxonomy/developer:docs:details:stateproofs:index.md

@@ -0,0 +1,61 @@
+title: Algorand State Proofs Overview
+
+A State Proof is a cryptographic proof of state changes that occur in a given set of blocks. While other interoperability solutions use intermediaries to “prove” blockchain activity, State Proofs are created and signed by the Algorand network itself. The same participants that reach consensus on new blocks sign a message attesting to a summary of recent Algorand transactions. These signatures are then compressed into a [compact certificate of collective knowledge](https://people.csail.mit.edu/nickolai/papers/micali-compactcert-eprint.pdf), also known as a State Proof.
+
+After a State Proof is created, a State Proof transaction, which includes the State Proof and the message it proves, is created and sent to the Algorand network for validation. The transaction goes through [consensus](../algorand_consensus.md) like any other pending Algorand transaction: it gets validated by participation nodes, included in a block proposal, and written to the blockchain.
+
+Each State Proof can be used to power lightweight services that verify Algorand transactions without running consensus or storing a copy of the Algorand ledger. These external services, or “Light Clients'', can efficiently verify proofs of Algorand state (either State Proofs or State Proof derived zk-SNARK proofs) in low-power environments like a smartphone, IoT device, or even inside a blockchain smart contract. For each verified State Proof, the Light Client can store the message’s transaction summary, giving it a light, verified history of Algorand state. Depending on its storage budget, a Light Client could store all State Proof history, giving it the ability to efficiently, cryptographically verify any Algorand transaction which occurred since the first State Proof was written on-chain.
+
+Since Algorand users already trust the Algorand network’s ability to reach consensus on new blocks, we call these State Proof transactions, and the Light Clients they power, “trustless.” By providing simple interfaces to verify Algorand transactions, these Light Clients make it safer and easier to develop and use cross-chain products and services which want to leverage the state of the Algorand blockchain.
+
+# How State Proofs are Generated
+Each State Proof represents a collection of weighted signatures that attest to a specific message. In Algorand’s case, each State Proof message contains a commitment to all transactions that occurred over a period of 256 rounds, known as the State Proof Interval. Each proof convinces verifiers that participating accounts who jointly have a sufficient total portion of online Algorand stake have attested to this message, without seeing or verifying all of the signatures.
+
+Every block that is processed on the Algorand chain has a header containing a commitment to all transactions in that block. This Transaction Commitment is the root of a tree with all transactions in that block as leaves. At the end of each State Proof Interval, nodes assemble the block interval commitment by using each of the 256 Transaction Commitments from this interval as leaves. This commitment is then included in the State Proofs message, which is signed by network participants.
+
+The process for generating a State Proof for a specific block interval actually starts at the generation of the previous State Proof. For example, if a State Proof is being generated for round 768, the following steps will occur:
+
+1. On round 512 (=768 - 256), every participating node would create a participation commitment for the top N online accounts, composed of their public state proof keys and relative online stake. When a node is elected to propose a block through consensus, it includes this commitment in the block header. 
+2. On round 769, every participating node executes the following steps for each online account it manages:
+   
+    A. Build a Block Interval commitment tree based on all the blocks in the interval. This tree’s leaves are created using the transaction commitment from each of the blocks’ headers. This block interval will include rounds [513,...,768]. 
+
+    B. Assemble a [message](https://github.com/algorand/go-algorand/blob/fd488f806dcbc2586f585155eea0180c30287f70/daemon/algod/api/server/v2/generated/types.go#L470) containing this Block Interval Commitment and some other metadata, sign the message, and propagate it to the network using the standard protocol gossip framework.
+
+3. Relay nodes receive the signed messages and verify them. These signatures are accumulated based on the signer's weight and added to a Signature array. Once the relay node has sufficient signed weight accumulated, the relay node constructs a State Proof that contains a randomized sample of accumulated signatures which can convince a verifier that at least 30% of the top N accounts have signed the State Proof message.
+4. After creating the proof, the relay node constructs a State Proof transaction, composed of the message and its corresponding proof, and submits it to the network. This transaction (first in wins) is processed with normal consensus. Participation nodes run the state proof verification algorithm to make sure that this State Proof is valid, using the expected signers from round 512’s on-chain participation commitment as reference. Once through consensus, the transaction is written to the blockchain.
+
+For a deeper dive into the cryptography behind State Proofs, check out this [presentation](https://www.youtube.com/watch?v=gbk74npcs-g).
+
+Note that each State Proof is linked together by a series of participation commitments indicating which accounts should produce signatures for the next State Proof, and their weights. These commitments form a chain linking the most recent proof written on-chain to the genesis State Proof from launch day. Since the set of participants is committed ahead of time, and each participants’ signature is produced using quantum-safe Falcon keys, we can have confidence that each verifiable State Proof was produced by actual network participants. This means that any State Proof verifier can have full confidence that the transactions committed to in each State Proof message are in fact legitimate, even in an age where powerful quantum computers attempt attacks. By producing quantum-safe proofs of the history of the blockchain, Algorand reaches its first milestone towards post-quantum security.
+
+# Using State Proofs
+State Proofs allow others to verify Algorand transactions while taking on minimal trust assumptions. Specifically, someone verifying Algorand transactions via a State Proof Light Client needs to trust the following:
+
+1. The Algorand blockchain’s ability to reach consensus on valid transactions.
+2. The first “participants” commitment that initialized the Light Client was obtained in a trustworthy way (this specifies the eligible voters for the genesis State Proof).
+3. The State Proof verifier code inside the Light Client was implemented correctly.
+4. Algorand’s new cryptographic primitives are secure ([Sumhash](https://github.com/algorand/go-sumhash/blob/master/cryptanalysis/merging-trees-ss.pdf), [Falcon](https://github.com/algorand/falcon)).
+5. (Depending on the use case): The environment where the Algorand Light Client code is running is secure (e.g. another blockchain’s smart contract).
+
+To verify an Algorand transaction outside of the Algorand blockchain, external processes need to understand the structure of how transactions are hashed into the Block Interval commitment. This is done using two commitment trees that are explained below.
+
+## Transaction Commitment
+A transaction commitment is created for every block that occurs on the Algorand blockchain. The root of this tree is stored in the block header.
+
+<center>
+![Transaction Commitment](../../imgs/transaction_commitment.png)
+</center>
+
+The leaf nodes in this tree are sequenced in the same order as the transactions in the block.  
+
+## Block Interval Commitment Tree
+Once all of the blocks in a 256-round state proof interval have been certified on-chain, participating nodes generate a Block Interval commitment tree to attest to all transactions for the blocks in the period. The leaves of this block interval commitment are made of light block headers for each round contained within the interval. Each light block header contains the round number and the transaction commitment root for the given block.
+
+Participating accounts add the root of this commitment tree to a State Proof message, sign the message with their State Proof keys, and then propagate it to the network. The root of this commitment tree can be used in conjunction with a set of transaction and block interval proofs to verify any transaction in this period.
+
+<center>
+![Block Interval Commitment](../../imgs/block_interval_commitment.png)
+</center>
+
+The Algorand SDK provides clients that can make API calls to retrieve these commitment roots and proofs for verifying specific transactions. For more information on implementing a verifier or using the SDKs, continue reading on [How to Build an Algorand Light Client](light_client.md).