Hedera forking tutorials

[kpachhai]

Description:

This PR adds comprehensive tutorials for fork testing on Hedera using both Hardhat and Foundry frameworks. These tutorials enable developers to test smart contracts against real Hedera network state locally without spending gas or affecting the live network.

• Add Hardhat Part 1 tutorial - Basic ERC-20 fork testing with impersonation
• Add Hardhat Part 2 tutorial - Advanced HTS token operations (create, mint, transfer)
• Add Foundry Part 1 tutorial - Basic ERC-20 fork testing with vm.prank
• Add core concepts page explaining how Hedera forking works internally
• Add complete project examples with contracts, tests, deploy scripts, and READMEs

Tutorials added:

• how-to-fork-the-hedera-network-with-hardhat-basic-erc20.mdx
• how-to-fork-the-hedera-network-with-hardhat-advanced-hts.mdx
• how-to-fork-the-hedera-network-with-foundry-basic-erc20.mdx
• forking-hedera-network-for-local-testing.mdx (core concepts)

Example projects added:

• hardhat/basic-erc20-fork-test/ - Complete Hardhat ERC-20 example
• hardhat/advanced-hts-fork-test/ - Complete Hardhat HTS example
• foundry/basic-erc20-fork-test/ - Complete Foundry ERC-20 example

Related issue(s):

Fixes #361

Notes for reviewer:

Key concepts covered in these tutorials:

• Fork testing against deployed contracts on Hedera testnet
• Account impersonation (hardhat_impersonateAccount / vm.prank)
• Funding accounts (hardhat_setBalance / vm.deal)
• HTS system contract precompiles for token operations
• Understanding the hedera-forking emulation layer
• Differences between Hardhat and Foundry approaches

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[jasuwienas]

Overall, this is a great job!

(most importantly the testing scenario works : ))

There are just a few things I’d like to clarify.

(
I’m not a fan of including the full contents of JavaScript test files (especially when theyre hundreds of lines long) directly in README files. Don’t you think it would be better to keep them elsewhere and simply reference them from the README (or copy only relevant parts when there’s a need to point to a specific place)?

P.S. just for context: I’ve been working with the forking library for some time, so I understand how it works under the hood and what it’s meant for. I read this guide from that perspective

[kpachhai]

Overall, this is a great job!

(most importantly the testing scenario works : ))

There are just a few things I’d like to clarify.

( I’m not a fan of including the full contents of JavaScript test files (especially when theyre hundreds of lines long) directly in README files. Don’t you think it would be better to keep them elsewhere and simply reference them from the README (or copy only relevant parts when there’s a need to point to a specific place)?

P.S. just for context: I’ve been working with the forking library for some time, so I understand how it works under the hood and what it’s meant for. I read this guide from that perspective

So, the reason we wanna include as much code as we want in the documentation is because we want users to be able to follow along with the tutorials word for word. This will prevent some weird discrepancies if we decide to update the github repo that hosts the code or worse yet, the repo gets moved or whatever the reason.

Also, one important reason we wanna have as much detail as we can as part of our documentation(especially for tutorials) going forward has to do with the fact that these days, everyone uses AI to ask questions about code and this includes the AI we have integrated within our documentation. This is to feed all the relevant data to the LLMs so they're aware of everything needed to help users on their journey in case they aren't reading the tutorial on our documentation page but rather asking their favorite AI instead.

[jasuwienas]

Thank you! LGTM!

[michielmulders]

Nitpicking: Instead of pasting the raw URL, can we give it a word like "list of HTS supported methods"?

[kpachhai]

I had this before and then I removed it again.
I can put it back again but note that this list is constantly updated as new methods are supported and we should be sure to always update the same thing in 2 places(in github repo and doc).

So, to remove this dependency, I just added the authoritative source of truth(which is the github repo README itself).

What do you think?

[michielmulders]

Overall, this is a great job!
(most importantly the testing scenario works : ))
There are just a few things I’d like to clarify.
( I’m not a fan of including the full contents of JavaScript test files (especially when theyre hundreds of lines long) directly in README files. Don’t you think it would be better to keep them elsewhere and simply reference them from the README (or copy only relevant parts when there’s a need to point to a specific place)?
P.S. just for context: I’ve been working with the forking library for some time, so I understand how it works under the hood and what it’s meant for. I read this guide from that perspective

So, the reason we wanna include as much code as we want in the documentation is because we want users to be able to follow along with the tutorials word for word. This will prevent some weird discrepancies if we decide to update the github repo that hosts the code or worse yet, the repo gets moved or whatever the reason.

Also, one important reason we wanna have as much detail as we can as part of our documentation(especially for tutorials) going forward has to do with the fact that these days, everyone uses AI to ask questions about code and this includes the AI we have integrated within our documentation. This is to feed all the relevant data to the LLMs so they're aware of everything needed to help users on their journey in case they aren't reading the tutorial on our documentation page but rather asking their favorite AI instead.

@jasuwienas @kpachhai You can use expandaples to show/hide code (hide them by default: https://www.mintlify.com/docs/components/expandables It might be helpful for long code files