diff --git a/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/10-stakepools.md b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/10-stakepools.md
index 0dc47b3d..0d820460 100644
--- a/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/10-stakepools.md
+++ b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/10-stakepools.md
@@ -12,6 +12,7 @@ extensions:
     startSlot: 32815320
     stopSlot: 32815924
     scheduledPrefix: cd
+    network: CardanoNetworkConfigEntryName
 ```
 
 ### Meaning
diff --git a/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/20-delayed-state.md b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/20-delayed-state.md
index f197ad1f..410c719e 100644
--- a/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/20-delayed-state.md
+++ b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/20-delayed-state.md
@@ -1,6 +1,6 @@
 # Delayed State
 
-Different blockchains may have different block times & finality, so trying to guarantee the state of blockchain A from blockchain B often requires timelock systems like [projected data](../../../700-multichain-support/1-nfts/2-projected-nfts/1-basics.mdx).
+Different blockchains may have different block times & finality, so trying to guarantee the state of blockchain A from blockchain B often requires timelock systems like [projected data](../../../700-multichain-support/1-projected-nfts/1-introduction.mdx).
 
 However, not all use-cases care about having the data entirely up-to-date. For example, NFT-gated features should work even if your knowledge of whether or not the user owns an NFT is 5 minutes delayed. That is to say, delayed data is **not** guaranteed to be up-to-date (hence *delayed*)
 
@@ -23,6 +23,7 @@ extensions:
       - "919d4c2c9455016289341b1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
     startSlot: 22505578
     stopSlot: 32815924
+    network: CardanoNetworkConfigEntryName
 ```
 
 ### Meaning
diff --git a/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/30-cardano-transfer.md b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/30-cardano-transfer.md
new file mode 100644
index 00000000..7524e18b
--- /dev/null
+++ b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/30-cardano-transfer.md
@@ -0,0 +1,62 @@
+
+# Cardano Transfer {#transfer}
+
+### Example
+
+```yaml
+extensions:
+  - name: "CardanoTransfer"
+    type: cardano-transfer
+    credential: addr_test1qp27ms6du9e2fga6njk9ruzprp7gg3uddrnc3htv7mct8kwrwdlnpt07ycmdqyuw7lft338dt33tmr6xdwnn8ezsudpquved20
+    startSlot: 12472120
+    stopSlot: 12500000
+    scheduledPrefix: ct
+    network: CardanoNetworkConfigEntryName
+```
+
+### Meaning
+
+- `startSlot` is required and means that only transactions that happen after that slot (exclusive) will be considered.
+- `stopSlot` is optional, and it stops the indexing at that point.
+- `credential` is the address to track. This can be a bech32 address, or a hex encoded credential.
+
+### Paima Concise format
+
+The scheduled input for each event is of the following form.
+
+```
+cardanoTransfer  = ct|txId|metadata|inputCredentials|outputs
+```
+
+It can be parsed with a rule of the form:
+
+```ts
+const cardanoTransfer: ParserRecord<CardanoTransfer> = {
+  txId: PaimaParser.NCharsParser(0, 64),
+  metadata: PaimaParser.OptionalParser(null, PaimaParser.RegexParser(/[a-f0-9]*/)),
+  inputCredentials: PaimaParser.ArrayParser({
+    item: PaimaParser.RegexParser(/[a-f0-9]*/),
+  }),
+  outputs: (keyName: string, input: string) => {
+    return JSON.parse(input);
+  },
+};
+
+interface CardanoTransfer {
+  txId: string;
+  metadata: string | null;
+  inputCredentials: string[];
+  outputs: {
+    asset: { policyId: string; assetName: string } | null;
+    amount: string;
+    address: string;
+  }[];
+}
+```
+
+- The metadata field is in its binary form, but hex encoded.
+- The entries in `inputCredentials` are also hex encoded. Each one is the binary
+representation of the payment key (64 characters or 32 bytes).
+- `outputs` preserves the same order as in the binary transaction. The `asset`
+will be `null` when the amount is in lovelace.
+
diff --git a/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/40-cardano-mint-burn.md b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/40-cardano-mint-burn.md
new file mode 100644
index 00000000..b568c697
--- /dev/null
+++ b/docs/home/300-react-to-events/2-primitive-catalogue/20-cardano/40-cardano-mint-burn.md
@@ -0,0 +1,53 @@
+# Cardano Mint and Burn {#mint-burn}
+
+### Example
+
+```yaml
+extensions:
+  - name: "CARDANO-MINT-BURN"
+    type: cardano-mint-burn
+    policyIds: 
+      - "0fc891fb7368d3b7c7b88815c203fda0d6862b0f1d797222672e91fe"
+      - "0fc891fb7368d3b7c7b88815c203fda0d6862b0f1d797222672e91ff"
+    startSlot: 722300
+    stopSlot: 733216
+    scheduledPrefix: cmb
+    network: CardanoNetworkConfigEntryName
+``` 
+
+### Meaning
+
+- `startSlot` is required and means that only mints events after that slot (exclusive) will be considered.
+- `stopSlot` is optional, and it stops the indexing at that point.
+- `policyIds` is an array with the collections to index.
+
+### Paima Concise format
+
+The scheduled input for each event is of the following form.
+
+```
+cardanoMint = cmb|txId|metadata|assets
+```
+
+It can be parsed with a rule of the form:
+
+```ts
+const cardanoMint: ParserRecord<CardanoMint> = {
+  txId: PaimaParser.NCharsParser(0, 64),
+  metadata: PaimaParser.OptionalParser(null, PaimaParser.RegexParser(/[a-f0-9]*/)),
+  assets: (keyName: string, input: string) => {
+    return JSON.parse(input);
+  },
+};
+
+export interface CardanoMint {
+  txId: string;
+  metadata: string | null;
+  assets: { asset: { policyId: string; assetName: string }; amount: string };
+}
+```
+
+- The `metadata` field is hex encoded (if any), and it's the metadata in binary
+form.
+- The `assets` field has the minted or burned assets. The difference between a
+mint and a burn is in the sign of `amount` when interpreted as a number.
\ No newline at end of file