@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,396 @@
+title: Atomic transfers
+
+In traditional finance, trading assets generally requires a trusted intermediary, like a bank or an exchange, to make sure that both sides receive what they agreed to. On the Algorand blockchain, this type of trade is implemented within the protocol as an **Atomic Transfer**. This simply means that transactions that are part of the transfer either all succeed or all fail. Atomic transfers allow complete strangers to trade assets without the need for a trusted intermediary, all while guaranteeing that each party will receive what they agreed to. 
+
+On Algorand, atomic transfers are implemented as irreducible batch operations, where a group of [transactions](../transactions) are submitted as a unit and all transactions in the batch either pass or fail. This also eliminates the need for more complex solutions like [hashed timelock contracts](https://en.bitcoinwiki.org/wiki/Hashed_Timelock_Contracts) that are implemented on other blockchains. An atomic transfer on Algorand is confirmed in less than 4 seconds, just like any other transaction. Transactions can contain Algos or Algorand Standard Assets and may also be governed by Algorand Smart Contracts. 
+
+# Quick start videos
+
+If you prefer videos, take a look at this 10 minute guide to learn about Atomic Transactions.
+
+<iframe width="100%" style="aspect-ratio:16/9" src="https://www.youtube-nocookie.com/embed/65I0wyq7XoI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+# Use cases
+
+Atomic transfers enable use cases such as:
+
+**Circular trades** - Alice pays Bob if and only if Bob pays Claire if and only if Claire pays Alice.
+
+**Group payments** - Everyone pays or no one pays.
+
+**Decentralized exchanges** - Trade one asset for another without going through a centralized exchange. 
+
+**Distributed payments** - Payments to multiple recipients. 
+
+**Pooled transaction fees** - One transaction pays the fees of others. 
+
+# Process overview
+
+To implement an atomic transfer, generate all of the transactions that will be involved in the transfer and then group those transactions together. The result of grouping is that each transaction is assigned the same group ID. Once all transactions contain this group ID, the transactions can be split up and sent to their respective senders to be authorized. A single party can then collect all the authorized transactions and submit them to the network together. 
+
+!!! info
+    An individual account involved in an atomic transfer can verify that all the correct transfers are involved by creating the same set of [unsigned] transactions and grouping them in the same order. The group ID is a hash of the group of transactions and should match if the configuration is the same.
+
+<center>![Atomic Transfer Flow](../imgs/atomic_transfers-1.png)</center>
+<center>*Atomic Transfer Flow*</center>
+
+Below you will find examples for creating and sending group transactions to the network in each of the available SDKs and with `goal`. 
+
+!!! tip
+    The following processes may be simplified with the SDKs use of the [atomic transaction composer (ATC)](atc.md). The ATC supports ABI compliant smart contract calls with Argument and Return Value encoding/decoding.
+
+# Step-by-step guide
+
+## Create transactions
+Create two or more (up to 16 total) unsigned transactions of any type. Read about transaction types in the [Transactions Overview](../transactions) section. 
+
+This could be done by a service or by each party involved in the transaction. For example, an asset exchange application can create the entire atomic transfer and allow individual parties to sign from their location.
+
+The example below illustrates creating, grouping, and signing transactions atomically and submitting to the network.
+
+
+=== "JavaScript"
+    <!-- ===JSSDK_ATOMIC_CREATE_TXNS=== -->
+	```javascript
+	const suggestedParams = await client.getTransactionParams().do();
+	
+	const alicesTxn = algosdk.makePaymentTxnWithSuggestedParamsFromObject({
+	  from: acct1.addr,
+	  to: acct2.addr,
+	  amount: 1e6,
+	  suggestedParams,
+	});
+	
+	const bobsTxn = algosdk.makePaymentTxnWithSuggestedParamsFromObject({
+	  from: acct2.addr,
+	  to: acct1.addr,
+	  amount: 1e6,
+	  suggestedParams,
+	});
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/atomics.ts#L15-L30)
+    <!-- ===JSSDK_ATOMIC_CREATE_TXNS=== -->
+
+=== "Python"
+    <!-- ===PYSDK_ATOMIC_CREATE_TXNS=== -->
+	```python
+	# payment from account 1 to account 2
+	txn_1 = transaction.PaymentTxn(addr1, suggested_params, addr2, 100000)
+	# payment from account 2 to account 1
+	txn_2 = transaction.PaymentTxn(addr2, suggested_params, addr1, 200000)
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/atomic_transfers.py#L16-L20)
+    <!-- ===PYSDK_ATOMIC_CREATE_TXNS=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_ATOMIC_CREATE_TXNS=== -->
+	```java
+	Response<TransactionParametersResponse> rsp = algodClient.TransactionParams().execute();
+	
+	// payment from account 1 to account 2
+	Transaction ptxn1 = Transaction.PaymentTransactionBuilder().sender(acct1.getAddress())
+	                .amount(1000000).receiver(acct2.getAddress()).suggestedParams(rsp.body()).build();
+	// txn_1 = transaction.PaymentTxn(addr1, suggested_params, addr2, 100000)
+	
+	// payment from account 2 to account 1
+	Transaction ptxn2 = Transaction.PaymentTransactionBuilder().sender(acct2.getAddress())
+	                .amount(2000000).receiver(acct1.getAddress()).suggestedParams(rsp.body()).build();
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/AtomicTransfers.java#L26-L36)
+    <!-- ===JAVASDK_ATOMIC_CREATE_TXNS=== -->
+
+=== "Go"
+    <!-- ===GOSDK_ATOMIC_CREATE_TXNS=== -->
+	```go
+	sp, err := algodClient.SuggestedParams().Do(context.Background())
+	if err != nil {
+		log.Fatalf("failed to get suggested params: %s", err)
+	}
+	
+	tx1, err := transaction.MakePaymentTxn(acct1.Address.String(), acct2.Address.String(), 100000, nil, "", sp)
+	if err != nil {
+		log.Fatalf("failed creating transaction: %s", err)
+	}
+	
+	// from account 2 to account 1
+	tx2, err := transaction.MakePaymentTxn(acct2.Address.String(), acct1.Address.String(), 100000, nil, "", sp)
+	if err != nil {
+		log.Fatalf("failed creating transaction: %s", err)
+	}
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/atomic_transactions/main.go#L24-L39)
+    <!-- ===GOSDK_ATOMIC_CREATE_TXNS=== -->
+
+=== "goal"
+    <!-- ===GOAL_ATOMIC_CREATE_TXNS=== -->
+	``` goal
+    $ goal clerk send --from=my-account-a<PLACEHOLDER> --to=my-account-c<PLACEHOLDER> --fee=1000 --amount=100000 --out=unsginedtransaction1.txn"
+
+    $ goal clerk send --from=my-account-b<PLACEHOLDER> --to=my-account-a<PLACEHOLDER> --fee=1000 --amount=200000 --out=unsginedtransaction2.txn"
+    ```
+    <!-- ===GOAL_ATOMIC_CREATE_TXNS=== -->
+
+At this point, these are just individual transactions. The next critical step is to combine them and then calculate the group ID.
+
+See [Authorizing Transactions Offline](../transactions/offline_transactions#saving-unsigned-transactions-to-file) to learn how to create and save individual **unsigned** transactions to a file. This method can be used to distribute group transactions for signing.
+
+## Group transactions
+
+The result of this step is what ultimately guarantees that a particular transaction belongs to a group and is not valid if sent alone (even if properly signed). A group-id is calculated by hashing the concatenation of a set of related transactions. The resulting hash is assigned to the [Group](../transactions/transactions#group) field within each transaction. This mechanism allows anyone to recreate all transactions and recalculate the group ID to verify that the contents are as agreed upon by all parties. Ordering of the transaction set must be maintained.
+
+=== "JavaScript"
+    <!-- ===JSSDK_ATOMIC_GROUP_TXNS=== --->
+	```javascript
+	const txnArray = [alicesTxn, bobsTxn];
+	// assignGroupID returns the same txns with the group ID set
+	const txnGroup = algosdk.assignGroupID(txnArray);
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/atomics.ts#L33-L36)
+    <!-- ===JSSDK_ATOMIC_GROUP_TXNS=== --->
+
+=== "Python"
+    <!-- ===PYSDK_ATOMIC_GROUP_TXNS=== --->
+	```python
+	# Assign group id to the transactions (order matters!)
+	transaction.assign_group_id([txn_1, txn_2])
+	# Or, equivalently
+	# get group id and assign it to transactions
+	# gid = transaction.calculate_group_id([txn_1, txn_2])
+	# txn_1.group = gid
+	# txn_2.group = gid
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/atomic_transfers.py#L24-L31)
+    <!-- ===PYSDK_ATOMIC_GROUP_TXNS=== --->
+
+=== "Java"
+    <!-- ===JAVASDK_ATOMIC_GROUP_TXNS=== --->
+	```java
+	// Assign group id to the transactions (order matters!)
+	Transaction[] txs = TxGroup.assignGroupID(ptxn1, ptxn2);
+	
+	// Or, equivalently
+	// compute group id and assign it to transactions
+	Digest gid = TxGroup.computeGroupID(txs);
+	ptxn1.group = gid;
+	ptxn2.group = gid;
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/AtomicTransfers.java#L39-L47)
+    <!-- ===JAVASDK_ATOMIC_GROUP_TXNS=== --->
+
+=== "Go"
+    <!-- ===GOSDK_ATOMIC_GROUP_TXNS=== --->
+	```go
+	// compute group id and put it into each transaction
+	gid, _ := crypto.ComputeGroupID([]types.Transaction{tx1, tx2})
+	tx1.Group = gid
+	tx2.Group = gid
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/atomic_transactions/main.go#L42-L46)
+    <!-- ===GOSDK_ATOMIC_GROUP_TXNS=== --->
+
+=== "goal"
+    <!-- ===GOAL_ATOMIC_GROUP_TXNS=== --->
+	```goal
+    $ cat unsignedtransaction1.tx unsignedtransaction2.tx > combinedtransactions.tx
+    $ goal clerk group -i combinedtransactions.tx -o groupedtransactions.tx -d data -w yourwallet 
+    ```
+    <!-- ===GOAL_ATOMIC_GROUP_TXNS=== --->
+
+## Split transactions (Goal only)
+
+At this point the transaction set must be split to allow distributing each component transaction to the appropriate wallet for authorization. 
+
+=== "goal"
+    <!-- ===GOAL_ATOMIC_GROUP_SPLIT=== -->
+	```goal
+    # keys in distinct wallets
+    $ goal clerk split -i groupedtransactions.tx -o splitfiles -d data -w yourwallet 
+
+    Wrote transaction 0 to splitfiles-0
+    Wrote transaction 1 to splitfiles-1
+
+    # distribute files for authorization
+    ```
+    <!-- ===GOAL_ATOMIC_GROUP_SPLIT=== -->
+
+## Sign transactions
+With a group ID assigned, each transaction sender must authorize their respective transaction. 
+
+=== "JavaScript"
+    <!-- ===JSSDK_ATOMIC_GROUP_SIGN=== -->
+	```javascript
+	const alicesSignedTxn = txnGroup[0].signTxn(acct1.privateKey);
+	const bobsSignedTxn = txnGroup[1].signTxn(acct2.privateKey);
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/atomics.ts#L39-L41)
+    <!-- ===JSSDK_ATOMIC_GROUP_SIGN=== -->
+
+=== "Python"
+    <!-- ===PYSDK_ATOMIC_GROUP_SIGN=== -->
+	```python
+	# sign transactions
+	stxn_1 = txn_1.sign(sk1)
+	stxn_2 = txn_2.sign(sk2)
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/atomic_transfers.py#L34-L37)
+    <!-- ===PYSDK_ATOMIC_GROUP_SIGN=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_ATOMIC_GROUP_SIGN=== -->
+	```java
+	// sign transactions
+	SignedTransaction signedPtxn1 = acct1.signTransaction(ptxn1);
+	SignedTransaction signedPtxn2 = acct2.signTransaction(ptxn2);
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/AtomicTransfers.java#L50-L53)
+    <!-- ===JAVASDK_ATOMIC_GROUP_SIGN=== -->
+
+=== "Go"
+    <!-- ===GOSDK_ATOMIC_GROUP_SIGN=== -->
+	```go
+	_, stx1, err := crypto.SignTransaction(acct1.PrivateKey, tx1)
+	if err != nil {
+		fmt.Printf("Failed to sign transaction: %s\n", err)
+		return
+	}
+	_, stx2, err := crypto.SignTransaction(acct2.PrivateKey, tx2)
+	if err != nil {
+		fmt.Printf("Failed to sign transaction: %s\n", err)
+	}
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/atomic_transactions/main.go#L49-L58)
+    <!-- ===GOSDK_ATOMIC_GROUP_SIGN=== -->
+
+=== "goal"
+    <!-- ===GOAL_ATOMIC_GROUP_SIGN=== -->
+	```goal
+    # sign from single wallet containing all keys
+    $ goal clerk sign -i groupedtransactions.tx -o signout.tx -d data -w yourwallet
+
+    # -- OR --
+
+    # sign from distinct wallets
+    $ goal clerk sign -i splitfiles-0 -o splitfiles-0.sig -d data -w my_wallet_1
+    $ goal clerk sign -i splitfiles-1 -o splitfiles-1.sig -d data -w my_wallet_2
+    ```
+    <!-- ===GOAL_ATOMIC_GROUP_SIGN=== -->
+
+## Assemble transaction group
+
+All authorized transactions are now assembled into an array, maintaining the original transaction ordering, which represents the transaction group.
+
+=== "JavaScript"
+    <!-- ===JSSDK_ATOMIC_GROUP_ASSEMBLE=== -->
+	```javascript
+	const signedTxns = [alicesSignedTxn, bobsSignedTxn];
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/atomics.ts#L44-L45)
+    <!-- ===JSSDK_ATOMIC_GROUP_ASSEMBLE=== -->
+
+=== "Python"
+    <!-- ===PYSDK_ATOMIC_GROUP_ASSEMBLE=== -->
+	```python
+	# combine the signed transactions into a single list
+	signed_group = [stxn_1, stxn_2]
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/atomic_transfers.py#L40-L42)
+    <!-- ===PYSDK_ATOMIC_GROUP_ASSEMBLE=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_ATOMIC_GROUP_ASSEMBLE=== -->
+	```java
+	// combine the signed transactions into a single list
+	SignedTransaction[] stxns = new SignedTransaction[] { signedPtxn1, signedPtxn2 };
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/AtomicTransfers.java#L56-L58)
+    <!-- ===JAVASDK_ATOMIC_GROUP_ASSEMBLE=== -->
+
+=== "Go"
+    <!-- ===GOSDK_ATOMIC_GROUP_ASSEMBLE=== -->
+	```go
+	var signedGroup []byte
+	signedGroup = append(signedGroup, stx1...)
+	signedGroup = append(signedGroup, stx2...)
+	
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/atomic_transactions/main.go#L61-L65)
+    <!-- ===GOSDK_ATOMIC_GROUP_ASSEMBLE=== -->
+
+=== "goal"
+    <!-- ===GOAL_ATOMIC_GROUP_ASSEMBLE=== -->
+	``` goal
+    # combine signed transactions files
+    cat splitfiles-0.sig splitfiles-1.sig > signout.tx
+    ```
+    <!-- ===GOAL_ATOMIC_GROUP_ASSEMBLE=== -->
+
+## Send transaction group
+The transaction group is now broadcast to the network. 
+
+=== "JavaScript"
+    <!-- ===JSSDK_ATOMIC_GROUP_SEND=== -->
+	```javascript
+	await client.sendRawTransaction(signedTxns).do();
+	await algosdk.waitForConfirmation(client, alicesTxn.txID().toString(), 3);
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/atomics.ts#L48-L50)
+    <!-- ===JSSDK_ATOMIC_GROUP_SEND=== -->
+
+=== "Python"
+    <!-- ===PYSDK_ATOMIC_GROUP_SEND=== -->
+	```python
+	
+	# Only the first transaction id is returned
+	tx_id = algod_client.send_transactions(signed_group)
+	
+	# wait for confirmation
+	result: Dict[str, Any] = transaction.wait_for_confirmation(
+	    algod_client, tx_id, 4
+	)
+	print(f"txID: {tx_id} confirmed in round: {result.get('confirmed-round', 0)}")
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/atomic_transfers.py#L45-L54)
+    <!-- ===PYSDK_ATOMIC_GROUP_SEND=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_ATOMIC_GROUP_SEND=== -->
+	```java
+	// Only the first transaction id is returned
+	Response<PostTransactionsResponse> txResponse = algodClient.RawTransaction()
+	                .rawtxn(Encoder.encodeToMsgPack(stxns)).execute();
+	String txid = txResponse.body().txId;
+	
+	// Wait for the transaction id to be confirmed
+	// If the results from other transactions are needed, grab the txid from those
+	// directly and
+	// call waitForConfirmation on each
+	PendingTransactionResponse txResult = Utils.waitForConfirmation(algodClient, txid, 4);
+	System.out.printf("Transaction %s confirmed in round %d\n", txid, txResult.confirmedRound);
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/AtomicTransfers.java#L61-L72)
+    <!-- ===JAVASDK_ATOMIC_GROUP_SEND=== -->
+
+=== "Go"
+    <!-- ===GOSDK_ATOMIC_GROUP_SEND=== -->
+	```go
+	pendingTxID, err := algodClient.SendRawTransaction(signedGroup).Do(context.Background())
+	if err != nil {
+		fmt.Printf("failed to send transaction: %s\n", err)
+		return
+	}
+	confirmedTxn, err := transaction.WaitForConfirmation(algodClient, pendingTxID, 4, context.Background())
+	if err != nil {
+		fmt.Printf("Error waiting for confirmation on txID: %s\n", pendingTxID)
+		return
+	}
+	fmt.Printf("Confirmed Transaction: %s in Round %d\n", pendingTxID, confirmedTxn.ConfirmedRound)
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/atomic_transactions/main.go#L68-L79)
+    <!-- ===GOSDK_ATOMIC_GROUP_SEND=== -->
+
+=== "goal"
+    <!-- ===GOAL_ATOMIC_GROUP_SEND=== -->
+	```goal
+    goal clerk rawsend -f signout.tx -d data -w yourwallet
+    ```
+    <!-- ===GOAL_ATOMIC_GROUP_SEND=== -->

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

@@ -0,0 +1,95 @@
+title: Conduit
+
+Conduit is a plugin based framework that functions like a data pipeline. Conduit is primarily intended to allow dApp developers to customize the data the dApp wants to monitor/aggregate/act on from the Algorand Blockchain. 
+
+Conduit can be used to:
+
+- Build a notification system for on chain events.
+- Power a next generation block explorer.
+- Select dApp specific data and act on specific dApp transactions.
+- Identify and act on dApp specific Token actions/movements.
+- Identify and act on specific Algorand transactions based on Address or other transaction properties.
+- Build a custom Indexer for a new [ARC](https://github.com/algorandfoundation/ARCs).
+- Send blockchain data to another streaming data platform for additional processing (e.g. RabbitMQ, Kafka, ZeroMQ).
+- Build an NFT catalog based on different standards.
+- Have Searchability on a massively reduced set of transactions, requiring much less disk space. 
+
+!!!note
+	Full documentation for the Conduit framework is available in the [Conduit Github repository](https://github.com/algorand/conduit/blob/master/README.md).
+
+
+# Installing Conduit
+
+Conduit can be installed by downloading the [built binaries](https://github.com/algorand/conduit/releases), using a [docker image](https://hub.docker.com/r/algorand/conduit) on docker hub, or [built from source](https://github.com/algorand/conduit/tree/master#install-from-source). Full instructions for Installation of Conduit are described in the [Conduit Github Repository](https://github.com/algorand/conduit/blob/master/README.md).
+
+
+# Conduit Architecture
+
+The framework consists of three primary plugin components, _Importers_, _Processors_, and _Exporters_. _Importer_ plugins are designed to source data into the pipeline, _Processors_ manipulate or filter the data, and _Exporter_ plugins act on the processed data. Within a given instance of Conduit, the pipeline supports one _importer_ and one _exporter_, while zero or more _processor_ plugins can be used. 
+
+<center>
+![Conduit Architecture](/docs/imgs/conduitarch.png){: style="width:700px" align=center }
+</center>
+
+Default installations of the conduit binaries include two types of _importers_ ([`algod`](https://github.com/algorand/conduit/tree/master/conduit/plugins/importers/algod) and [`file_reader`](https://github.com/algorand/conduit/tree/master/conduit/plugins/importers/filereader)). The `algod` plugin is used to source data from an [Algorand Follower node](https://github.com/algorand/conduit/blob/master/docs/tutorials/IndexerWriter.md#node-algod-with-follow-mode) or an [Archival node](https://developer.algorand.org/docs/run-a-node/setup/types/#archival-mode). Using a Follower node is the recommended approach as you have access to more data for use in the _processor_ and also have access to the `postgresql` _exporter_. The `file_reader` plugin can be used to source block data from the filesystem. Most dApps will most likely use the `algod` importer. 
+
+The default installation provides one _processor_ that filters the data based on transaction properties. This plugin ([`filter_processor`](https://github.com/algorand/conduit/tree/master/conduit/plugins/processors/filterprocessor)) will be described in more detail in a subsequent section. 
+
+The default installation provides two _exporters_ ([`postgresql`](https://github.com/algorand/conduit/tree/master/conduit/plugins/exporters/postgresql) and [`file_writer`](https://github.com/algorand/conduit/tree/master/conduit/plugins/exporters/filewriter)). The `file_writer` _exporter_, writes block data to the filesystem. The `postgresql` _exporter_ writes block data to a postgreSQL database. 
+
+# Configuring Conduit
+
+Conduit is configured by defining all the plugins the pipeline will support in a YAML file called `conduit.yml`. These plugins must be built and part of the binaries that the specific instance of Conduit is using. This file is used to define which _importer_, _processors_, and _exporter_ plugin a particular instance is using. In addition, individual plugin properties are also configured in the YAML file as well.  For more information on creating and configuring the YAML file see the [Conduit documentation](https://github.com/algorand/conduit/blob/master/README.md#create-conduityml-configuration-file). 
+
+!!!note
+	Multiple instances of Conduit can be running simultaneously, with different configurations. No two instances can use the same follower node though.
+
+# Running Conduit
+
+Once Installed and configured, start Conduit with your data directory as an argument:
+
+`./conduit -d data`
+
+!!!warning 
+    This data directory should be unique to conduit. This is not the data directory that algod uses.
+
+
+# Customizing Conduit
+
+In addition to the default plugins described above, the Conduit framework allows custom plugins to be developed allowing dApp developers total customization of how the data is sourced, processed and stored or acted on. This process is described in detail with several tutorials available in the [Conduit Github repository](https://github.com/algorand/conduit/blob/master/docs/PluginDevelopment.md). The Conduit team also hosts a known list of [externally developed plugins](https://github.com/algorand/conduit/blob/master/docs/ExternalPlugins.md). 
+
+!!!note
+	The Conduit team is actively looking for sample plugins that illustrate interesting use cases. If you build a plugin and want to share your work, please file a PR on the Conduit repository to add it to that page. 
+
+# Using the Indexer API with an Instance of Conduit
+
+When using Conduit, some dApps may wish to continue to use the Indexer API that Algorand provides. If your application will require this API, you will need to setup the Conduit pipeline as described in the [Conduit documentation](https://github.com/algorand/conduit/blob/master/docs/tutorials/IndexerWriter.md). 
+
+!!!note
+	The 2.X versions of Indexer used all the blockchain data since its inception. With Conduit, you can decide how much data you really want to store and search with the Indexer API.
+
+# Filtering Block Data
+
+One of the primary use cases of Conduit is to filter data that a specific dApp is interested in examining or acting on. To accommodate this, the default installation of Conduit provides the `filter_processor`. This filter is configured similarly to the following in `config.yml`.
+
+```sh
+name: filter_processor
+config:
+    # Whether the expression searches inner transactions for matches.
+    search-inner: true
+
+    # Whether to include the entire transaction group when the filter
+    # conditions are met.
+    omit-group-transactions: true
+
+    # The list of filter expressions to use when matching transactions.
+    filters:
+      - any:
+          - tag: "txn.rcv"
+            expression-type: "equal"
+            expression: "ADDRESS"
+```
+
+After specifying the proper name and two basic parameters, one or more filters can be added to the YAML file to specify particular transactions your dApp is interested in. In the above example, Conduit will only store/act on transactions where a specific address is the receiver of a transaction. Developers can set any number of filters, specifying different tags, expression-types and expressions.  The `tag` property has access to all transaction properties defined in the [Developer documentation](https://developer.algorand.org/docs/get-details/transactions/transactions/). In addition, if your instance of Conduit is attached to a Follower node, the filter can also tag specific data in the `ApplyData` set. `ApplyData` contains data that needs to be applied to the ledger, based on the results of a transaction(s). This includes properties like changes to Closing Amount , Application State, etc. The full list of available properties in the `ApplyData` set is available in the [Conduit Documentation](https://github.com/algorand/conduit/blob/master/conduit/plugins/processors/filterprocessor/Filter_tags.md). For more information and examples of other filters see the [Conduit filter examples](https://github.com/algorand/conduit/tree/master/conduit/plugins/processors/filterprocessor#examples).
+
+

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

@@ -0,0 +1,156 @@
+title: IPFS Pinning With Crust
+
+## IPFS
+Algorand offers [various ways to store data in contracts](../dapps/smart-contracts/apps/state/), but there are still many use cases where storing the data off-chain makes more sense. This is paticularly true when the data is large and not used directly on-chain (for example, NFT metadata and images). A common solution for off-chain data storage is the InterPlanetary File System (IPFS) protocol. In short, IPFS is a peer-to-peer file sharing protocol. For more information on IPFS, see https://docs.ipfs.tech/concepts/faq/.
+
+In order to share files via IPFS, one must pin a file on the network. Pinning a file means assigning it a unique Content Identifier (CID) and making it availible to download. It is common for developers to use a pinning service like Pinata, web3.storage, or nft.storage. While these services do indeed pin the file on IPFS, they are still using centralized servers to do so. This means those using these services are dependend on them to keep running them and are locked into their pricing model.
+
+
+## Crust
+
+To avoid using centralized services for IPFS pinning, Algorand developers can use the Crust network. Crust is a decentralized pinning service where users can pay the network to pin a file and that file will be pinned on many servers around the world. The pricing model is set by the node runners, rather than a single entity. For more information on Crust, see https://crust.network/faq/.
+
+## Crust and Algorand
+
+Crust is easier than ever to use for Algorand developers because you can pay for storage via ABI method calls to the Crust contracts deployed on testnet and mainnet. 
+
+### Deployments
+Testnet storage contract application ID: [507867511](https://testnet.explorer.perawallet.app/application/507867511/)
+
+Mainnet storage contract application ID: [1275319623](https://explorer.perawallet.app/application/1275319623/)
+
+
+### Usage
+
+The easiest way to use the Crust storage contract is to use the ARC32 `application.json` that was generated by the beaker contract. The JSON and full source can be found at https://github.com/crustio/algorand-storage-contract.
+
+The general process is:
+
+1. Build web3 authentication header
+2. Upload files to IPFS
+3. Get storage price
+4. Place storage order
+
+#### Building Header
+
+```ts
+/**
+ * Generate a web3 auth header from an Algorand account
+ */
+function getAuthHeader(account: algosdk.Account) {
+    const sk32 = account.sk.slice(0, 32)
+    const signingKey = nacl.sign.keyPair.fromSeed(sk32)
+
+    const signature = nacl.sign(Buffer.from(account.addr), signingKey.secretKey)
+    const sigHex = Buffer.from(signature).toString('hex').slice(0, 128)
+    const authStr = `sub-${account.addr}:0x${sigHex}`
+
+    return Buffer.from(authStr).toString('base64')
+}
+```
+
+#### Upload to IPFS
+
+```ts
+/**
+ * upload a file to IPFS and get its CID and size
+ * 
+ * @param account Account to use to generate the auth header
+ */
+async function uploadToIPFS(account: algosdk.Account) {
+    // Note: Not all gateways require this header
+    const headers = {
+        "Authorization": `Basic ${getAuthHeader(account)}`
+    }
+
+    // list of API hosts
+    // https://github.com/crustio/crust-apps/blob/master/packages/apps-config/src/ipfs-gateway-endpoints/index.ts
+    const apiEndpoint = 'https://gw-seattle.crustcloud.io:443/api/v0/add'
+
+    // If you're in browser, you should be able to just use a file directly
+    const formData = new FormData();
+    formData.append('README.md', fs.createReadStream('./README.md'));
+
+
+    const res = await axios.post(apiEndpoint, formData, {
+        headers: {
+            ...headers,
+            // formData.getHeaders() is only required if you're using nodejs
+            ...formData.getHeaders()
+        }
+    });
+
+    const json: { Hash: string, Size: number } = await res.data
+
+    return { cid: json.Hash, size: Number(json.Size) }
+}
+```
+
+#### Get Storage Price
+
+```ts
+/**
+ * Gets the required price to store a file of a given size
+ * 
+ * @param algod Algod client to use to simulate the ABI method call
+ * @param appClient App client to use to compose the ABI method call
+ * @param size Size of the file
+ * @param isPermanent Whether the file should be added to the renewal pool
+ * @returns Price, in uALGO, to store the file
+ */
+async function getPrice(algod: algosdk.Algodv2, appClient: StorageOrderClient, size: number, isPermanent: boolean = false) {
+    const result = await (await appClient.compose().getPrice({ size, is_permanent: isPermanent }).atc()).simulate(algod)
+
+    return result.methodResults[0].returnValue?.valueOf() as number
+}
+```
+
+#### Place Order
+
+```ts
+/**
+ * Uses simulate to get a random order node from the storage contract
+ * 
+ * @param algod Algod client to use to simulate the ABI method call
+ * @param appClient The app client to use to compose the ABI method call
+ * @returns Address of the order node
+ */
+async function getOrderNode(algod: algosdk.Algodv2, appClient: StorageOrderClient) {
+    return (await (await appClient.compose().getRandomOrderNode({}, { boxes: [new Uint8Array(Buffer.from('nodes'))] }).atc()).simulate(algod)).methodResults[0].returnValue?.valueOf() as string
+}
+
+/**
+ * Places a storage order for a CID
+ * 
+ * @param algod Algod client used to get transaction params
+ * @param appClient App client used to call the storage app
+ * @param account Account used to send the transactions
+ * @param cid CID of the file
+ * @param size Size of the file
+ * @param price Price, in uALGO, to store the file
+ * @param isPermanent Whether the file should be added to the renewal pool
+ */
+async function placeOrder(
+    algod: algosdk.Algodv2,
+    appClient: StorageOrderClient,
+    account: algosdk.Account,
+    cid: string,
+    size: number,
+    price: number,
+    isPermanent: boolean
+) {
+    const merchant = await getOrderNode(algod, appClient)
+    const seed = algosdk.makePaymentTxnWithSuggestedParamsFromObject({
+        from: account.addr,
+        to: (await appClient.appClient.getAppReference()).appAddress,
+        amount: price,
+        suggestedParams: await algod.getTransactionParams().do(),
+    });
+
+    appClient.placeOrder({ seed, cid, size, is_permanent: isPermanent, merchant })
+}
+```
+
+#### Full Examples
+
+To see the full scripts that use the above functions go to https://github.com/algorand-devrel/crust-examples

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

@@ -0,0 +1,18 @@
+title: AVM
+
+The Algorand virtual machine (AVM) runs on every node in the Algorand blockchain. This virtual machine contains a stack engine that evaluates smart contracts and smart signatures against the transactions they're called with. These programs either fail and reject the transaction or succeed and apply changes according to the logic and contents of the transactions. 
+
+
+# Quick start videos
+
+If you prefer videos, take a look at this playlist to learn about AVM. Most of the videos in the list are under 5 minutes each.
+
+<iframe width="100%" style="aspect-ratio:16/9" src="https://www.youtube-nocookie.com/embed/96pwBo5jqnk" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+Smart contracts, also referred to as stateful smart contracts, contain logic that is deployed and can be remotely called from any node on the Algorand blockchain. These contracts are called by issuing an Application Call transaction. The AVM evaluates the contract logic against this transaction and ultimately results in success or failure. If a call to a smart contract fails, any changes produced by that call will not be committed to the blockchain. If the call is successful, the changes will be recorded to the blockchain when the block is committed. In addition to changes to balances, the logic within a smart contract can modify key/value data associated with the contract on a global or per-account basis. 
+
+Smart signatures, also referred to as stateless contracts, contain logic that is used to sign transactions, commonly for signature delegation. The logic of the smart signature is submitted with the transaction. While the logic in the smart signature is stored on the chain as part of the transaction approval process, the logic is not remotely callable. Any new transaction that relies on the same smart signature would resubmit the logic. When the logic is submitted to a node the AVM evaluates the logic and results in success or failure. If a smart signature’s logic fails when executed by the AVM, the associated transaction will not be applied.
+
+The AVM interprets an assembler-like language called [Transaction Execution Approval Language (TEAL)](teal/index.md). TEAL can be thought of as syntactic sugar for AVM bytecode and the [full specification](teal/specification.md) of the TEAL language is available in the developer documentation. In addition, a simple [overview guide](teal/index.md) explains many of the features of the language. TEAL programs are comprised of a set of operation codes (opcodes). These opcodes are used to implement the logic of smart contracts and smart signatures. The full list of [opcodes](teal/opcodes) is available in the developer documentation.  
+
+While it is possible to write TEAL directly, a developer may prefer to use the PyTeal Python library, which provides a more familiar syntax. For more information on using PyTeal to write smart signatures and smart contracts see [Build with Python](/docs/get-details/dapps/writing-contracts/pyteal).