diff --git a/src/tutorials/0007-verifying-storage-on-filecoin/02.md b/src/tutorials/0007-verifying-storage-on-filecoin/02.md
index b01b41ea4..86da1c496 100644
--- a/src/tutorials/0007-verifying-storage-on-filecoin/02.md
+++ b/src/tutorials/0007-verifying-storage-on-filecoin/02.md
@@ -9,7 +9,7 @@ Before a system file (e.g. `puppy.gif`) can be stored on the Filecoin network, i
 
 In the first stage of this transformation, the system file is chunked up with UnixFS to create an IPLD DAG (Directed Acyclic Graph). You can learn more about DAGs (a form of merkle tree) in our [Content Addressing on the Decentralized Web](https://proto.school/content-addressing) tutorial. This IPLD DAG has a _payload CID_, identical to an IPFS CID, which represents the root of the DAG.
 
-The IPLD DAG is then serialized to a [CAR file](https://github.com/ipld/specs/blob/master/block-layer/content-addressable-archives.md#summary) and bit padded to make a Filecoin Piece. (Bit padding adds extra bits to make the piece conform to a standard size.) This piece has a unique _piece CID_, also known as a CommP (Piece Commitment).
+The IPLD DAG is then serialized to a [CAR file](https://ipld.io/specs/transport/car/) and bit padded to make a Filecoin Piece. (Bit padding adds extra bits to make the piece conform to a standard size.) This piece has a unique _piece CID_, also known as a CommP (Piece Commitment).
 
 Since payload CIDs and piece CIDs are cryptographic hashes of the data itself, they're unique, with identical CIDs guaranteeing identical content. Identical IPLD DAGs will produce identical payload CIDs and identical pieces will produce identical piece CIDs, no matter who's going to store or retrieve them.