@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,390 @@
+title: How To Build An Algorand Light Client - With State Proofs
+
+# What is an Algorand Light Client?
+An Algorand light client is a lightweight process that tracks the state of the Algorand network without trust in any intermediary. By cryptographically verifying a chain of proofs produced by the Algorand network itself, each light client can verify any given transaction on the network without running full node operations like consensus. Anyone can run an Algorand light client in any environment, providing a simple, secure interface to Algorand state in low power environments where running a full node is impractical or undesirable.
+
+While State Proofs compress large amounts of Algorand state into a portable format (~600-900 KB), they are not designed to be verified inside blockchain smart contracts. The Algorand research team is currently building ultra-compact zk-SNARK proofs, which will be optimized for on-chain verification in fee-constrained environments like a blockchain smart contract. The rest of this article will focus on how to build a State Proof powered light client. We will discuss how to build a SNARK Proof powered light client as the cryptography work nears completion, although the key difference lies in the proof verification function used to advance the Light Client’s state.
+
+Please note that Algorand light clients let you securely export Algorand state. In order to import state from another blockchain into Algorand, we’ll need to build a light client from that blockchain on Algorand. We will cover how to build other blockchain light clients on Algorand in a future article.
+
+The cryptographic verification functions necessary to build a State Proof powered light client and to verify Algorand transactions are currently available as APIs in the go-algorand-sdk.
+
+# Exporting Algorand State
+State proofs use two primary Vector Commitment trees (similar to Merkle trees) to summarize blockchain activity.
+
+1. A Transaction Commitment tree, which summarizes all transactions in a given block, is built into each block header by hashing each signed transaction in that block as tree leaves.
+2. A Block Interval Commitment tree, which summarizes all block headers in a given state proof interval (256 rounds), is built once per interval. It is constructed with “light” block headers, which contain the block’s transaction commitment root and can be derived from the main block header, as tree leaves.
+
+Each state proof “message” contains the root of the block interval commitment tree summarizing all transactions in that interval. After validating each state proof, a light client can store as many validated block interval commitments as it desires, creating a window of verified Algorand state. Requestors can then ask the Light Client to verify individual Algorand transactions which occurred in that interval - they simply need to provide proofs (retrieved from the Algorand SDKs) linking a specific transaction to a block interval commitment root.
+
+<center>
+![Block Interval Commitment](../../imgs/block_interval_commitment_arch.png)
+</center>
+
+Three new API endpoints to algod are available which are accessible via the Algorand SDKs to support State Proofs.
+
+## GetTransactionProof(txnId, confirmedRound, hashType)
+GetTransactionProof returns data that is used to verify that a specific transaction exists in a given transaction commitment tree. This function accepts a transaction ID, the round the transaction was confirmed in, and the hash function used to construct the commitment tree. This method will return a proof, the leaf index of the transaction, the depth of the tree, and the hash of the signed transaction that is being checked. These pieces of information should be all that a Light Client will need to verify a transaction is in the Transaction Commitment tree. Note that both the block interval commitment (inside the State Proof message) and the transaction commitment (inside the light block header) are constructed using SHA256, so you should use this hashType when verifying Algorand transactions on a Light Client. 
+
+## GetLightBlockHeaderProof(round)
+GetLightBlockHeaderProof returns data that is used to verify that a specific Light Block Header exists in the Block Interval tree. This call takes a round number as a parameter and returns a proof, the leaf index of the light block header, and the tree depth of the block interval tree. These pieces of information should be all that a Light Client needs to verify a Light Block Header exists in a Block Interval Tree. If the State Proof transaction has not been written to the ledger for a specific interval and this method is called for a round in that interval, the call will fail.
+
+## GetStateProof(round)
+GetStateProof is used to retrieve a State Proof for the interval that contains a specific round, which is passed as a parameter. The State Proof contains the signatures of the attested State Proof message and the actual message which contains the Block Interval Commitment root for the given round. Note that it is possible that this call will return an error if the chosen round does not have a specific State Proof written on chain yet. This call will be used by Light Clients to track the state of the Algorand Chain, which is described in the next section.
+
+# Light Client PoC Overview
+Algorand Light Clients should be built to answer one question: did a specific transaction occur on Algorand’s blockchain at a specified round. To accomplish this, each Light Client will verify State Proofs (or zk-SNARK proofs) in order to store block interval commitments. These verified commitments can be used to validate block interval roots re-computed by the transaction verifier via the proofs returned from the algod API.
+
+The Light Client should have 2 interfaces: one to advance Algorand state by verifying incoming State Proofs, and another to verify specific Algorand transactions against previously-verified block interval commitments. Because State Proofs are not polled by the Light Client itself, external relayers should retrieve State Proofs and their associated messages from the Algorand SDKs as they become available and push them to the Light Client for verification. Similar to the State Proof chain, each Light Client forms a chain by verifying incoming State Proofs against a previously-verified participants’ commitment. Similar to how Proof of Stake blockchains are initialized, the Light Client will need to hard-code the initial participants commitment in order to verify the first State Proof written on-chain.
+
+<center>
+![Light Client](../../imgs/light_client_arch.png)
+</center>
+
+Algorand provides a proof of concept version of a light client which is located on [GitHub](https://github.com/algorand/light-client-poc). Please note that this PoC code is purely informational and does not reflect the ideal way to implement a Light Client. Each section of the Light Client proof of concept will be explained below.
+
+## Oracle
+
+```go
+// Oracle is responsible for ingesting State Proofs in chronological order and saving their block interval commitments
+// to form a window of verified Algorand history.
+// It then allows, given a round, to retrieve the vector commitment root attesting to the interval to which the round
+// belongs.
+type Oracle struct {
+   // BlockIntervalCommitmentHistory is a sliding window of verified block interval commitments. Given a round,
+   // it returns the block interval commitment that contains the specified block.
+   BlockIntervalCommitmentHistory *CommitmentHistory
+   // VotersCommitment is the vector commitment root of the top N accounts to sign the next StateProof.
+   VotersCommitment stateproofcrypto.GenericDigest
+   // LnProvenWeight is an integer value representing the natural log of the proven weight with 16 bits of precision.
+   // This value would be used to verify the next state proof.
+   LnProvenWeight uint64
+}
+
+```
+
+The Oracle exposes the following functions:
+
+### InitializeOracle
+
+```go
+
+// InitializeOracle initializes the Oracle using trusted genesis data.
+// Parameters:
+// firstAttestedRound - the first round to which a state proof message attests.
+// intervalSize - represents the number of rounds that occur between each state proof.
+// genesisVotersCommitment - the initial genesisVotersCommitment commitment. Real values can be found in the Algorand developer portal.
+// genesisLnProvenWeight - the initial LnProvenWeight. Real values can be found in the Algorand developer portal.
+// capacity - the maximum number of commitments to hold before discarding the earliest commitment.
+func InitializeOracle(firstAttestedRound uint64, intervalSize uint64, genesisVotersCommitment stateproofcrypto.GenericDigest,
+   genesisLnProvenWeight uint64, capacity uint64) *Oracle {
+   return &Oracle{
+      // The BlockIntervalCommitmentHistory is initialized using the first attested round,
+      // the interval size and its capacity.
+      BlockIntervalCommitmentHistory: InitializeCommitmentHistory(firstAttestedRound, intervalSize, capacity),
+      VotersCommitment:               genesisVotersCommitment,
+      LnProvenWeight:                 genesisLnProvenWeight,
+   }
+}
+
+```
+
+### AdvanceState
+
+```go
+// AdvanceState receives a msgpacked state proof, provided by the Algorand node API, and a state proof message that the
+// state proof attests to. It verifies the message using the proof given and the VotersCommitment and LnProvenWeight
+// from the previous state proof message.
+// If successful, it updates the Oracle's VotersCommitment and LnProvenWeight using their values from the new message,
+// and saves the block header commitment to the history.
+// This method should be called by a relay or some external process that is initiated when new Algorand state proofs are available.
+// Parameters:
+// stateProof - the decoded state proof, retrieved using the Algorand SDK.
+// message - the message to which the state proof attests.
+func (o *Oracle) AdvanceState(stateProof *stateproof.StateProof, message types.Message) error {
+   // verifier is Algorand's implementation of the state proof verifier, exposed by the state proof verification library.
+   // It uses the previous proven VotersCommitment and LnProvenWeight.
+   verifier := stateproof.MkVerifierWithLnProvenWeight(o.VotersCommitment, o.LnProvenWeight)
+
+   // We hash the state proof message using the Algorand SDK. The resulting hash is of the form
+   // sha256("spm" || msgpack(stateProofMessage)).
+   messageHash := stateproofcrypto.MessageHash(crypto.HashStateProofMessage(&message))
+
+   // The newly formed verifier verifies the given message using the state proof.
+   err := verifier.Verify(message.LastAttestedRound, messageHash, stateProof)
+   if err != nil {
+      // If the verification failed, for whatever reason, we return the error returned.
+      return err
+   }
+
+   // Successful verification of the message means we can trust it, so we save the VotersCommitment
+   // and the LnProvenWeight in the message, for verification of the next message.
+   o.VotersCommitment = message.VotersCommitment
+   o.LnProvenWeight = message.LnProvenWeight
+
+   var commitmentDigest types.Digest
+   copy(commitmentDigest[:], message.BlockHeadersCommitment)
+   // We insert the BlockHeadersCommitment found in the message to our commitment history sliding window.
+   // A side effect of this, if this commitment were to push our window over its capacity, would be deletion
+   // of the earliest commitment.
+   o.BlockIntervalCommitmentHistory.InsertCommitment(commitmentDigest)
+
+   return nil
+}
+```
+
+### GetStateProofCommitment
+
+```go
+// GetStateProofCommitment retrieves a saved commitment for a specific round.
+// Parameters:
+// round - the round to which a commitment will be retrieved.
+func (o *Oracle) GetStateProofCommitment(round types.Round) (types.Digest, error) {
+   // Receiving a commitment that should cover a round requires calculating the round's interval and retrieving the commitment
+   // for that interval. See BlockIntervalCommitmentHistory.GetCommitment for more details.
+   return o.BlockIntervalCommitmentHistory.GetCommitment(round)
+}
+```
+
+## Transaction Verifier
+The transaction verifier exposes the following interface:
+
+### VerifyTransaction
+
+```go
+
+// VerifyTransaction receives a sha256 hashed transaction, a proof to compute the transaction's commitment, a proof
+// to compute the commitment belonging to the light block header associated with the transaction's commitment,
+// and an expected commitment to compare to. The function verifies that the computed commitment using the given proofs
+// is identical to the provided commitment.
+// Parameters:
+// transactionHash - the result of invoking Sha256 on the canonical msgpack encoded transaction.
+// transactionProofResponse - the response returned by an Algorand node when queried using GetTransactionProof.
+// lightBlockHeaderProofResponse - the response returned by an Algorand node when queried using the GetLightBlockHeaderProof.
+// confirmedRound - the round in which the given transaction was confirmed.
+// genesisHash - the hash of the genesis block.
+// seed - the sortition seed of the block associated with the light block header.
+// blockIntervalCommitment - the commitment to compare to, provided by the Oracle.
+func VerifyTransaction(transactionHash types.Digest, transactionProofResponse models.TransactionProofResponse,
+   lightBlockHeaderProofResponse models.LightBlockHeaderProof, confirmedRound types.Round, genesisHash types.Digest, seed types.Seed, blockIntervalCommitment types.Digest) error {
+   // Verifying attested vector commitment roots is currently exclusively supported with sha256 hashing, both for transactions
+   // and light block headers.
+   if transactionProofResponse.Hashtype != "sha256" {
+      return ErrUnsupportedHashFunction
+   }
+
+   var stibHashDigest types.Digest
+   copy(stibHashDigest[:], transactionProofResponse.Stibhash[:])
+
+   // We first compute the leaf in the vector commitment that attests to the given transaction.
+   transactionLeaf := computeTransactionLeaf(transactionHash, stibHashDigest)
+   // We use the transactionLeaf and the given transactionProofResponse to compute the root of the vector commitment
+   // that attests to the given transaction.
+   transactionProofRoot, err := computeVectorCommitmentRoot(transactionLeaf, transactionProofResponse.Idx,
+      transactionProofResponse.Proof, transactionProofResponse.Treedepth)
+
+   if err != nil {
+      return err
+   }
+
+   // We use our computed transaction vector commitment root, saved in transactionProofRoot, and the given data
+   // to calculate the leaf in the vector commitment that attests to the light block headers.
+   candidateLightBlockHeaderLeaf := computeLightBlockHeaderLeaf(confirmedRound, transactionProofRoot, genesisHash, seed)
+   // We use the candidateLightBlockHeaderLeaf and the given lightBlockHeaderProofResponse to compute the root of the vector
+   // commitment that attests to the candidateLightBlockHeaderLeaf.
+   lightBlockHeaderProofRoot, err := computeVectorCommitmentRoot(candidateLightBlockHeaderLeaf, lightBlockHeaderProofResponse.Index, lightBlockHeaderProofResponse.Proof,
+      lightBlockHeaderProofResponse.Treedepth)
+
+   if err != nil {
+      return err
+   }
+
+   // We verify that the given commitment, provided by the Oracle, is identical to the computed commitment
+   if bytes.Equal(lightBlockHeaderProofRoot[:], blockIntervalCommitment[:]) != true {
+      return ErrRootMismatch
+   }
+   return nil
+}
+```
+
+Transaction verification uses several utility functions. In depth understanding of the following functions is required:
+
+### computeVectorCommitmentRoot
+
+```go
+// computeVectorCommitmentRoot takes a vector commitment leaf, its index, a proof, and a tree depth. it calculates
+// the vector commitment root using the provided data. This is done by computing internal nodes using the proof,
+// starting from the leaf, until we reach the root. This function uses sha256 - it cannot be used correctly with leaves
+// and proofs created using a different hash function.
+// Parameters:
+// leaf - the node we start computing the vector commitment root from.
+// leafIndex - the leaf's index.
+// proof - the proof to use in computing the vector commitment root. It holds hashed sibling nodes for each internal node
+// calculated.
+// treeDepth - the length of the path from the leaf to the root.
+func computeVectorCommitmentRoot(leaf types.Digest, leafIndex uint64, proof []byte, treeDepth uint64) (types.Digest, error) {
+  // An empty proof is only possible when the leaf received is already the root, which means that the treeDepth
+  // must be 0. In this case, the result is the leaf itself.
+  if len(proof) == 0 && treeDepth == 0 {
+     return leaf, nil
+  }
+
+  nodeHashSize := uint64(sha256.New().Size())
+  // The proof must hold exactly treeDepth node hashes to allow us to compute enough nodes to reach the root.
+  if treeDepth*nodeHashSize != uint64(len(proof)) {
+     return types.Digest{}, ErrProofLengthTreeDepthMismatch
+  }
+
+  // See comments on getVectorCommitmentPositions for more details on the contents of the positions variable.
+  positions, err := getVectorCommitmentPositions(leafIndex, treeDepth)
+  if err != nil {
+     return types.Digest{}, err
+  }
+
+  // We start climbing from the leaf.
+  currentNode := leaf
+  // When distanceFromLeaf equals treeDepth, currentNode will contain the computed root.
+  for distanceFromLeaf := uint64(0); distanceFromLeaf < treeDepth; distanceFromLeaf++ {
+     siblingIndexInProof := distanceFromLeaf * nodeHashSize
+     // siblingHash is the next node to append to our current node, retrieved from the proof.
+     siblingHash := proof[siblingIndexInProof : siblingIndexInProof+nodeHashSize]
+
+     // Vector commitment nodes are of the form Sha256("MA" || left child || right child). To calculate the internal node,
+     // we have to use the positions array to determine if our current node is the left or right child.
+     // Positions[distanceFromLeaf] is the position of the current node at height distanceFromLeaf.
+     nodeDomainSeparator := []byte(transactionverificationtypes.MerkleArrayNode)
+     internalNodeData := nodeDomainSeparator
+     switch positions[distanceFromLeaf] {
+     case leftChild:
+        internalNodeData = append(internalNodeData, currentNode[:]...)
+        internalNodeData = append(internalNodeData, siblingHash[:]...)
+     case rightChild:
+        internalNodeData = append(internalNodeData, siblingHash[:]...)
+        internalNodeData = append(internalNodeData, currentNode[:]...)
+     default:
+        return types.Digest{}, ErrInvalidPosition
+     }
+
+     currentNode = sha256.Sum256(internalNodeData)
+  }
+
+  return currentNode, nil
+}
+```
+
+### getVectorCommitmentPositions
+
+```go
+
+// getVectorCommitmentPositions maps a depth and a vector commitment index to the "positions" of the nodes
+// on the leaf-to-root path, with 0/1 denoting left/right (respectively). It does so by expressing the index in binary
+// using exactly depth bits, starting from the most-significant bit.
+// For example, leafDepth=4 and index=5 maps to the array [0,1,0,1] -- indicating that the leaf is a left child,
+// the leaf's parent is a right child, etc.
+// Parameters:
+// index - the leaf's index in the vector commitment tree.
+// depth - the length of the path from the leaf to the root.
+func getVectorCommitmentPositions(index uint64, depth uint64) ([]NodePosition, error) {
+   // A depth of 0 is only valid when the proof's length is also 0. Since the calling function checks for the situation
+   // where both values are 0, depth of 0 must be invalid.
+   if depth == 0 {
+      return []NodePosition{}, ErrInvalidTreeDepth
+   }
+
+   // Since each bit of the index is mapped to an element in the resulting positions array,
+   // the index must contain a number of bits amounting to the depth parameter, which means it must be smaller than 2 ^ depth.
+   if index >= 1<<depth {
+      return []NodePosition{}, ErrIndexDepthMismatch
+   }
+
+   // The resulting array should contain a number of positions equal to the depth of the tree -
+   // the length of the path between the root and the leaves - as that is the amounts of nodes traversed when calculating
+   // the vector commitment root.
+   directions := make([]NodePosition, depth)
+
+   // We iterate on the resulting array starting from the end, to allow us to extract LSBs, yet have the eventual result
+   // be equivalent to extracting MSBs.
+   for i := len(directions) - 1; i >= 0; i-- {
+      // We take index's current LSB, translate it to a node position and place it in index i.
+      directions[i] = NodePosition(index & 1)
+      // We shift the index to the right, to prepare for the extracting of the next LSB.
+      index >>= 1
+   }
+
+   return directions, nil
+}
+```
+
+## Main
+Tying it all together
+
+```go
+// A light client is composed of two modules:
+// 1. An oracle, in charge of maintaining Algorand's state as verified with state proofs. For more details, see oracle.go.
+// 2. A transaction verifier, in charge of verifying Algorand transaction occurrence by interfacing with the oracle. For more
+// details, see transactionVerifier.go.
+// This main function aims to demonstrate the interface between these two modules. In an actual
+// light client, they can be entirely separate processes/smart contracts.
+// The oracle should receive Algorand data from an off chain relayer, and the transaction verifier should receive
+// transaction occurrence queries from third parties. For the purposes of this PoC, they're two separate go packages, and
+// both the relayer and other third parties have been replaced with example committed data.
+func main() {
+  // This is the genesis data, required for initializing the oracle. This data can either be queried from the
+  // blockchain itself, or found in the developer's portal.
+  genesisVotersCommitment, genesisVotersLnProvenWeight, err := encodedassets.GetParsedGenesisData("encodedassets/genesis/")
+  if err != nil {
+     fmt.Printf("Failed to parse genesis assets: %s\n", err)
+     return
+  }
+
+  // This is data required for verifying a transaction. In a real light client, this data should come from a
+  // third party. The third party is responsible for querying Algorand to get most of this data.
+  genesisHash, round, seed, transactionHash, transactionProofResponse, lightBlockHeaderProofResponse, err :=
+     encodedassets.GetParsedTransactionVerificationData("encodedassets/transactionverification/")
+  if err != nil {
+     fmt.Printf("Failed to parse assets needed for transaction verification: %s\n", err)
+     return
+  }
+
+  // This is data required for advancing the oracle's state. In a real light client, this data should come from a relayer.
+  stateProofMessage, stateProof, err :=
+     encodedassets.GetParsedStateProofAdvancmentData("encodedassets/stateproofverification/")
+  if err != nil {
+     fmt.Printf("Failed to parse assets needed for oracle state advancement: %s\n", err)
+     return
+  }
+
+  // In a real light client, intervalSize and firstAttestedRound should be hardcoded, and retrieved from the Algorand
+  // consensus and from the Algorand blockchain respectively.
+  intervalSize := uint64(8)
+  firstAttestedRound := uint64(9)
+
+  // We initialize the oracle using the parsed genesis data and a hard coded capacity.
+  oracleInstance := oracle.InitializeOracle(firstAttestedRound, intervalSize, genesisVotersCommitment, genesisVotersLnProvenWeight, 1000)
+
+  // We advance the oracle's state using the state proof and the state proof message. The oracle verifies the message
+  // using the state proof. See the documentation in oracle.go for more details.
+  err = oracleInstance.AdvanceState(stateProof, stateProofMessage)
+  if err != nil {
+     fmt.Printf("Failed to advance oracle state: %s\n", err)
+     return
+  }
+
+  // After advancing the oracle's state, we retrieve the block interval commitment containing the given transaction's round from the oracle.
+  desiredTransactionCommitment, err := oracleInstance.GetStateProofCommitment(round)
+  if err != nil {
+     fmt.Printf("Failed to retrieve commitment interval for round %d: %s\n", round, err)
+     return
+  }
+
+  // We then verify the transaction's occurrence using the data provided for transaction verification,
+  // along with the block interval commitment this transaction belongs to.
+  err = transactionverifier.VerifyTransaction(transactionHash, transactionProofResponse,
+     lightBlockHeaderProofResponse, round, genesisHash, seed, desiredTransactionCommitment)
+
+  if err != nil {
+     fmt.Printf("Transaction verification failed: %s\n", err)
+     return
+  }
+}
+```

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

@@ -0,0 +1,233 @@
+title: Technical FAQ
+
+
+# Protocol Limits
+
+How many transactions can be in an atomic group?
+How large can my approval program be?
+How many arguments can I pass?
+What is the Minimum Balance Requirement increase for an asset opt-in?
+
+The limits applied at the protocol level are documented [here](/docs/get-details/parameter_tables).
+
+
+# Address Encoding/Decoding
+
+An address comes in 2 forms:
+    1) encoded, 58 characters long, looks something like `7K5TT4US7M3FM7L3XBJXSXLJGF2WCXPBV2YZJJO2FH46VCZOS3ICJ7E4QU`
+    2) decoded, 32 byte, looks something like `0xfabb39f292fb36567d7bb853795d693175615de1aeb194a5da29f9ea8b2e96d0` as hexadecimal
+
+You can translate from one to the other by using the SDK supplied methods.
+
+For example, in python `encoding.encode_address` will convert the 32 byte version to the encoded 58 character long version and `encoding.decode_address` will perform the opposite translation.
+
+All SDKs have a similarly named method.
+
+!! Note that smart contracts operate _only_ on the 32 byte version, so any interaction where an address is used should be translated prior to passing it to the smart contract. This is handled for you automatically in some cases (e.g. sender on a transaction)
+
+[Address Details](/docs/get-details/accounts/#keys-and-addresses)
+[Encoding Details](/docs/get-details/encoding/#address-encoding)
+
+# Application State Encoding/Decoding
+
+When calling the API for global or local state, the result returned is in the form of an array of state values. Each entry in the array represents a key/value pair in global or local state. To decode the key or bytes value, just base64 decode the string into bytes, then encode the bytes in whatever format is required.
+
+*examples*:
+
+- for a simple string, just encode it as `ascii` or `utf-8`
+- for an address call `encode_address` or similar depending on SDK
+- for an ABI tuple like `(address,uint64,bool)` use `ABIType.from_string("(address,uint64,bool)").decode(value_bytes)`
+
+
+```ts
+    interface StateValue {
+      // The base64 encoded key for this state value
+      key: string;
+      // The value as a sort of union type
+      value: {
+        // if set, the base64 encoded bytes for the state value
+        bytes: string;
+        // if set, the number stored in state
+        uint: number;
+        // 1 for bytes, 2 for uint
+        type?: number;
+        // Only set in the eval deltas, describes delete/set
+        action?: number;
+      };
+    }
+```
+
+
+# Deciphering Algod Errors
+
+A 400 error typically occurs because there was some issue with the transactions. The exact reason will depend on the circumstances, but the error message will contain more information.
+
+Common reasons include:
+
+- `transaction already in ledger: ...`
+
+    This happens when resending a transaction that has already been approved or accepted into a transaction pool. To make the transaction unique, add a nonce to the note field or change the valid rounds. To check if the transaction is in the pool use `/v2/transactions/pending/{txid}` REST API endpoint.
+
+- `underflow on subtracting SEND_AMOUNT from sender amount AVAILABLE_AMOUNT`, `account ADDRESS balance 0 below min XXX (N assets)`
+
+    All of these happen when some account does not have enough Algos to cover the transaction (taking into account their minimum balance requirement and any other transaction in the same group). Fund the account if necessary or cover the fees from its transactions with another transaction in the group.
+
+- `receiver error: must optin, asset ASSET_ID missing from ACCOUNT_ADDR`
+
+    This happens when the intended receiver of some asset hasn't opted in.
+
+- `should have been authorized by ADDR1 but was actually authorized by ADDR2`
+
+    This happens when the wrong signer is used to sign a transaction.
+
+- `TransactionPool.Remember: txn dead: round XXXXXXXX outside of XXXXXXXX--XXXXXXXX`
+
+    This happens when trying to submit a transaction outside its validity window, transactions may only have up to 1000 rounds between first/last valid round and the current round must be somewhere between first/last valid.
+
+- `fee N below threshold M`
+
+    This happens when the fee attached to a transaction (or transaction group) is not sufficient to cover the fees for the transaction.
+
+- `only clearing out is supported for applications that have been deleted`
+
+    This happens when an attempt is made to call an application that no longer exists
+
+- `this transaction should be issued by the manager. It is issued by ADDR`
+
+    This happens when trying to issue an asset config transaction by an account that is _not_ the manager account for the asset
+
+- `cannot close asset ID in allocating account`
+
+    This happens when the creator of an asset tries to close out of the asset.
+
+- `check failed on ApprovalProgram: program version N greater than protocol supported version M`
+
+    This happens when trying to create an application with a version that is not yet supported by the protocol.
+    If this happens on your local sandbox, set the protocol version to `future` to get access to the latest changes.
+
+- `cannot clear state: ADDR is not currently opted in to app N`
+
+    This happens when an account that is not opted in to an application tries to opt out or clear state for that app.
+
+- `invalid : program version mismatch: N != M`
+
+    This happens when you attempt to deploy or update a programs approval and clear state code with two different versions. Check that they both have the same version number.
+
+
+# Deciphering Logic errors
+
+How can I debug this logic error?
+
+Generally Logic errors can be debugged using [Dryrun, Tealdbg, or Simulate](/docs/get-details/dapps/smart-contracts/debugging).
+
+For some common errors, find an explanation below:
+
+-  `logic eval error: invalid {Asset|App|Account|Box} reference`
+
+    This happens when the reference is not passed in the app call transactions in the appropriate reference field. By passing a reference in the transaction, the node is able to quickly load the reference into memory and have it available for the AVM runtime to consult quickly. See [Box Storage Limitations](#box-storage) for additional information.
+
+
+- `logic eval error: assert failed pc=XXX`
+
+    An `assert` was invoked on something that evaluated to 0. The `pc` will provide a pointer to where in the program the `assert` failed. To find where in the TEAL source program this corresponds to, compile the source TEAL with [`source_map`](/docs/rest-apis/algod#post-v2tealcompile) enabled and use the result to find the line in the source program.
+
+- `logic eval error: program logs too large.`
+
+    At most, 1k may be logged and the `log` op may be called at most 32 times in a single app call.
+
+- `logic eval error: write budget (N) exceeded`, `logic eval error: box read budget (N) exceeded`
+
+    Every box reference passed allots another 1k to the read/write budget for the app call. By passing more box refs a larger IO budget is available. The budget is shared across app calls within the same group so a 32k box can be read/written to as long as 32 box references are passed (8 per txn, 4 txns). See [Box Storage Limitations](#box-storage) for additional information.
+
+- `logic eval error: store TYPE count N exceeds schema TYPE count M`
+
+    Schema needs to be large enough to allow storage requirements. Since the schema immutable after creation, a new application must be created if more storage is required. See [Global/Local Storage Limitations](#globallocal-storage) for additional information.
+
+- `logic eval error: err opcode executed.`
+
+    Typically, this is the result of the internal routing of the app finding that there are no matching routes for some conditional block. This often happens when something like the ABI method selector passed is not present in the application.
+
+- `logic eval error: overspend`
+
+    The account listed in the error did not have enough Algos to cover the transactions and fees of the transaction.
+
+- `logic eval error: * overflowed.`
+
+    The math operation would have returned a value > max uint64 (2^64 - 1). A solution is to use wide math opcodes to perform the arithmetic or byte math ops like `b*`.
+
+- `logic eval error: - would result negative.`
+
+    The math operation would have returned a negative value (< 0). Consider checking the values before using them within the operation.
+
+- `logic eval error: invalid ApplicationArgs index 0.`
+
+    An attempt was made by the contract to access an Application Arguments array element that was not set. Check that the correct Application Arguments are passed and that the flow of the program does not accidentally reference an invalid index.
+
+# Environment Setup
+
+How do I setup the Algod to connect to sandbox?
+
+Instructions for [Algokit](https://github.com/algorandfoundation/algokit-cli/blob/main/docs/algokit.md)
+
+Or
+
+Instructions for [Sandbox](https://github.com/algorand/sandbox/README.md)
+
+
+# API Providers
+
+Which API should I use?
+
+Below is a list of API providers that can be used to query Algod or Indexer data.
+
+- [AlgoNode](https://algonode.io/api/) (algod and indexer available, free tier available)
+- [Blockdaemon](https://www.blockdaemon.com/protocols/algorand) (algod only)
+- [GetBlock.io](https://getblock.io/nodes/algo/) (algod only, free tier available)
+
+Or find others [here](https://developer.algorand.org/ecosystem-projects/?tags=api-services)
+
+# Smart Contract Storage Limitations
+
+When storing data on-chain you must give consideration to the different limitations between state and box storage. Be aware the note field is not an option, as that's transactional data and is not stored directly to the ledger, nor is it accessible to other application calls outside the initial transaction group.
+
+## Global/Local Storage
+
+[Global](/docs/get-details/dapps/smart-contracts/apps/state/#global-storage) and [Local](/docs/get-details/dapps/smart-contracts/apps/state/#local-storage) state storage can store key-value pairs up to a maximum size of 128 bytes, inclusive of the key length. For example if the key is 8 bytes, then a maximum of 120 bytes can be stored in the value. Since each key must be unique, only a single 0 byte length key can be used to store a 128 byte value. Storing larger values requires the data to be split up and stored in multiple key-value pairs within state storage.
+
+## Box Storage
+
+[Box storage](/docs/get-details/dapps/smart-contracts/apps/state/#box-storage) is ideal for storing larger dynamically sized data. Since the minimum balance requirement is proportional to the amount of data you allocate to the box, it's generally more cost efficient, allowing you to allocate exactly the amount you need. Keys must again be unique per application, much like state storage, however the key is not included as part of the box size and instead must be between 1 to 64 bytes. The exact size of the box value can be up to 32KB (32768 bytes), however anything over 1024 bytes is going to require additional box references. This is due to each box reference being given a 1024 bytes of operational budget. For example if you wanted to store 2000 bytes in a box named "data", you'd need to include the "data" box reference two times in your application call transaction.
+
+
+# Pending Transactions
+
+When you run a non-participation node only transactions submitted to that particular node are seen as pending in the [transaction pool](/docs/rest-apis/algod/#get-v2accountsaddresstransactionspending). If you're interested in receiving all pending transactions within the network you'll need to set `ForceFetchTransactions` to True in the [algod configuration settings](/docs/run-a-node/reference/config/#algod-configuration-settings). Note that this will increase the bandwidth used by the node.
+
+# Verifying Release Binaries
+
+When downloading a release, you're able to look at the accompanying signature files to verify that you've received artifacts provided by Algorand Inc. The steps to do so vary slightly by product and package type.
+
+## algod
+
+The algod binaries have detached signatures for every archive file. The signatures are used as follows:
+1. Download public keys from https://releases.algorand.com
+2. Install one or more of the public keys with `gpg --import key.pub`.
+2. Download an artifact and its .sig file.
+3. Verify using a gpg tool: `gpg --verify file.tar.gz.sig file.tar.gz`
+
+## Conduit & Indexer
+
+Instead of detached signatures, these binaries have a single checksum file which is signed. Their public key is also hosted on a keyserver to simplify the process of installing, refreshing and revoking keys as needed. They can also be downloaded and imported from the releases page outlined above.
+
+1. Install the Algorand signing key from keys.openpgp.org or . Using GnuPG this is done with the following command:
+    > gpg --keyserver keys.openpgp.org --search-keys dev-ci+build@algorand.com
+
+2. Refresh keys if necessary. In the event of a security breech, we will revoke the key. To account for this, simply refresh the key:
+    > gpg --refresh-keys --keyserver keys.openpgp.org
+
+3. Download `checksums.txt.sig` and `checksums.txt` and verify the signature:
+    > gpg --verify checksums.txt.sig checksums.txt
+
+4. Download one or more release archives and verify the checksum:
+    > sha256sum -c < checksums.txt
+