Merge main into release

Author: github-actions[bot]

docs/README.md

@@ -41,15 +41,26 @@ subscriber.pollOnce()
 
 ## Capabilities
 
-- [Notification _and_ indexing](#notification-and-indexing)
-- [Low latency processing](#low-latency-processing)
-- [Extensive subscription filtering](#extensive-subscription-filtering)
-- [ARC-28 event subscription and reads](#arc-28-event-subscription-and-reads)
-- [First-class inner transaction support](#first-class-inner-transaction-support)
-- [State-proof support](#state-proof-support)
-- [Simple programming model](#simple-programming-model)
-- [Easy to deploy](#easy-to-deploy)
-- [Fast initial index](#fast-initial-index)
+- [Algorand transaction subscription / indexing](#algorand-transaction-subscription--indexing)
+  - [Quick start](#quick-start)
+  - [Capabilities](#capabilities)
+    - [Notification _and_ indexing](#notification-and-indexing)
+    - [Low latency processing](#low-latency-processing)
+    - [Watermarking and resilience](#watermarking-and-resilience)
+    - [Extensive subscription filtering](#extensive-subscription-filtering)
+    - [ARC-28 event subscription and reads](#arc-28-event-subscription-and-reads)
+    - [First-class inner transaction support](#first-class-inner-transaction-support)
+    - [State-proof support](#state-proof-support)
+    - [Simple programming model](#simple-programming-model)
+    - [Easy to deploy](#easy-to-deploy)
+    - [Fast initial index](#fast-initial-index)
+  - [Entry points](#entry-points)
+  - [Reference docs](#reference-docs)
+  - [Emit ARC-28 events](#emit-arc-28-events)
+    - [Algorand Python](#algorand-python)
+    - [TealScript](#tealscript)
+    - [PyTEAL](#pyteal)
+    - [TEAL](#teal)
 
 ### Notification _and_ indexing
 
@@ -73,7 +84,7 @@ The `syncBehaviour` parameter can also be set to `sync-oldest`, which is a more
 
 ### Low latency processing
 
-You can control the polling semantics of the library when using the [`AlgorandSubscriber`](./subscriber.md) by either specifying the `frequencyInSeconds` parameter to control the duration between polls or you can use the `waitForBlockWhenAtTip` parameter to indicate the subscriber should [call algod to ask it to inform the subscriber when a new round is available](https://developer.algorand.org/docs/rest-apis/algod/#get-v2statuswait-for-block-afterround) so the subscriber can immediately process that round with a much lower-latency. When this mode is set, the subscriber intelligently uses this option only when it's caught up to the tip of the chain, but otherwise uses `frequencyInSeconds` while catching up to the tip of the chain.
+You can control the polling semantics of the library when using the [`AlgorandSubscriber`](./subscriber.md) by either specifying the `frequencyInSeconds` parameter to control the duration between polls or you can use the `waitForBlockWhenAtTip` parameter to indicate the subscriber should [call algod to ask it to inform the subscriber when a new round is available](https://dev.algorand.co/reference/rest-apis/algod/#waitforblock) so the subscriber can immediately process that round with a much lower-latency. When this mode is set, the subscriber intelligently uses this option only when it's caught up to the tip of the chain, but otherwise uses `frequencyInSeconds` while catching up to the tip of the chain.
 
 e.g.
 
@@ -294,11 +305,11 @@ The `intra-round-offset` field in a [subscribed transaction or inner transaction
 
 ### State-proof support
 
-You can subscribe to [state proof](https://developer.algorand.org/docs/get-details/stateproofs/) transactions using this subscriber library. At the time of writing state proof transactions are not supported by algosdk v2 and custom handling has been added to ensure this valuable type of transaction can be subscribed to.
+You can subscribe to [state proof](https://dev.algorand.co/concepts/protocol/stateproofs) transactions using this subscriber library. At the time of writing state proof transactions are not supported by algosdk v2 and custom handling has been added to ensure this valuable type of transaction can be subscribed to.
 
 The field level documentation of the [returned state proof transaction](subscriptions.md#subscribedtransaction) is comprehensively documented via [AlgoKit Utils](https://github.com/algorandfoundation/algokit-utils-ts/blob/main/src/types/indexer.ts#L277).
 
-By exposing this functionality, this library can be used to create a [light client](https://developer.algorand.org/docs/get-details/stateproofs/light_client/).
+By exposing this functionality, this library can be used to create a [light client](https://dev.algorand.co/concepts/protocol/stateproofs).
 
 ### Simple programming model
 
@@ -334,7 +345,7 @@ The indexer catchup isn't magic - if the filter you are trying to catch up with
 
 To understand how the indexer behaviour works to know if you are likely to generate a lot of transactions it's worth understanding the architecture of the indexer catchup; indexer catchup runs in two stages:
 
-1. **Pre-filtering**: Any filters that can be translated to the [indexer search transactions endpoint](https://developer.algorand.org/docs/rest-apis/indexer/#get-v2transactions). This query is then run between the rounds that need to be synced and paginated in the max number of results (1000) at a time until all of the transactions are retrieved. This ensures we get round-based transactional consistency. This is the filter that can easily explode out though and take a long time when using indexer catchup. For avoidance of doubt, the following filters are the ones that are converted to a pre-filter:
+1. **Pre-filtering**: Any filters that can be translated to the [indexer search transactions endpoint](https://dev.algorand.co/reference/rest-apis/indexer#transaction). This query is then run between the rounds that need to be synced and paginated in the max number of results (1000) at a time until all of the transactions are retrieved. This ensures we get round-based transactional consistency. This is the filter that can easily explode out though and take a long time when using indexer catchup. For avoidance of doubt, the following filters are the ones that are converted to a pre-filter:
    - `sender` (single value)
    - `receiver` (single value)
    - `type` (single value)

docs/code/classes/types_subscription.SubscribedTransaction.md

@@ -6,7 +6,7 @@
 
 The common model used to expose a transaction that is returned from a subscription.
 
-Substantively, based on the Indexer  [`TransactionResult` model](https://developer.algorand.org/docs/rest-apis/indexer/#transaction) format with some modifications to:
+Substantively, based on the Indexer  [`TransactionResult` model](https://dev.algorand.co/reference/rest-apis/indexer#transaction) format with some modifications to:
 * Add the `parentTransactionId` field so inner transactions have a reference to their parent
 * Override the type of `inner-txns` to be `SubscribedTransaction[]` so inner transactions (recursively) get these extra fields too
 * Add emitted ARC-28 events via `arc28Events`

docs/code/interfaces/types_subscription.TransactionSubscriptionResult.md

@@ -78,7 +78,7 @@ ___
 
 Any transactions that matched the given filter within
 the synced round range. This substantively uses the [indexer transaction
-format](https://developer.algorand.org/docs/rest-apis/indexer/#transaction)
+format](https://dev.algorand.co/reference/rest-apis/indexer#transaction)
 to represent the data with some additional fields.
 
 #### Defined in

docs/subscriptions.md

@@ -229,7 +229,7 @@ export interface TransactionSubscriptionResult {
   newWatermark: bigint
   /** Any transactions that matched the given filter within
    * the synced round range. This substantively uses the [indexer transaction
-   * format](https://developer.algorand.org/docs/rest-apis/indexer/#transaction)
+   * format](hhttps://dev.algorand.co/reference/rest-apis/indexer#transaction)
    * to represent the data with some additional fields.
    */
   subscribedTransactions: SubscribedTransaction[]