What would you like us to improve?
The VRF v2.5 Getting Started guide sends readers to faucets.chain.link to get testnet ETH and LINK before creating a subscription. The testnet ETH drip silently requires the requester to already hold at least 1 LINK on Ethereum Mainnet — an anti-Sybil restriction — with no warning anywhere in the tutorial or on the faucet page before submission.
Scope note: this is a documentation gap, not a request to change the faucet's underlying logic (which is presumably intentional). The fix is a docs-only addition.
Steps to reproduce:
- Follow "Create and fund a subscription" in the VRF v2.5 Getting Started guide
- Visit faucets.chain.link/base-sepolia (or /sepolia) as instructed
- Request testnet LINK — succeeds
- Request testnet ETH — fails: "You must hold at least 1 LINK on Ethereum Mainnet to request native tokens."
Both drips were requested from the same faucet in the same session — the LINK drip's success confirms the faucet was functioning normally, isolating the ETH-specific mainnet gate as the actual cause.
Full reproduction with tx hashes and screenshots: [(https://github.com/HarshaSiriki/Chainlink_VRF_v2.5_Tutorial_Validation/tree/main)]
Suggested fix: add a note in the Getting Started prerequisites (and/or the faucet page) warning about this requirement, with either a link to an alternate faucet without the restriction, or an explanation of how to satisfy it.
Secondary, minor observation: the linked "Create and manage subscriptions" page orders its steps as Create → Add Consumer → Fund → Cancel, which doesn't match the order a Getting Started reader actually needs. Happy to open separately if useful.
How important it is?
This blocks exactly the audience a "Getting Started" tutorial targets: first-time users with no prior mainnet holdings. There's no guidance on what to do next, so a reader has to independently discover and troubleshoot the block outside the documentation.
This isn't an isolated occurrence — multiple independent developers have reported hitting the identical error since at least November 2024, with no fix or workaround documented anywhere in the tutorial flow. It's a recurring first-impression failure point for new Chainlink developers specifically.
What would you like us to improve?
The VRF v2.5 Getting Started guide sends readers to faucets.chain.link to get testnet ETH and LINK before creating a subscription. The testnet ETH drip silently requires the requester to already hold at least 1 LINK on Ethereum Mainnet — an anti-Sybil restriction — with no warning anywhere in the tutorial or on the faucet page before submission.
Scope note: this is a documentation gap, not a request to change the faucet's underlying logic (which is presumably intentional). The fix is a docs-only addition.
Steps to reproduce:
Both drips were requested from the same faucet in the same session — the LINK drip's success confirms the faucet was functioning normally, isolating the ETH-specific mainnet gate as the actual cause.
Full reproduction with tx hashes and screenshots: [(https://github.com/HarshaSiriki/Chainlink_VRF_v2.5_Tutorial_Validation/tree/main)]
Suggested fix: add a note in the Getting Started prerequisites (and/or the faucet page) warning about this requirement, with either a link to an alternate faucet without the restriction, or an explanation of how to satisfy it.
Secondary, minor observation: the linked "Create and manage subscriptions" page orders its steps as Create → Add Consumer → Fund → Cancel, which doesn't match the order a Getting Started reader actually needs. Happy to open separately if useful.
How important it is?
This blocks exactly the audience a "Getting Started" tutorial targets: first-time users with no prior mainnet holdings. There's no guidance on what to do next, so a reader has to independently discover and troubleshoot the block outside the documentation.
This isn't an isolated occurrence — multiple independent developers have reported hitting the identical error since at least November 2024, with no fix or workaround documented anywhere in the tutorial flow. It's a recurring first-impression failure point for new Chainlink developers specifically.