Chainlink

## LINK Token Basics
- LINK is an ERC-20 token on Ethereum — standard wallet and exchange support
- Also available on multiple chains — Arbitrum, Optimism, Polygon, Avalanche, BSC
- Bridging LINK between chains uses official Chainlink bridge — verify bridge address before using
- Different chains have different LINK contract addresses — verify correct address per network

## Token Transfers
- Standard ERC-20 transfer rules apply — gas paid in native token (ETH, MATIC, etc.)
- Some DeFi protocols accept LINK as collateral — Aave, Compound
- LINK has no special transfer restrictions — no tax tokens, no rebasing
- Decimals: 18 — same as ETH, standard precision

## Staking (v0.2)
- Community staking allows LINK holders to stake — earn rewards for securing network
- Staking has capacity limits — pool may be full, waitlist exists
- Unbonding period applies — can't withdraw instantly after unstaking
- Rewards in LINK — automatically added to staked balance
- Slashing risk exists — node operators can lose stake for misbehavior

## Price Feeds (For Developers)
- Chainlink price feeds are the standard for DeFi — Aave, Synthetix, and most protocols use them
- Feed addresses differ per network and pair — always verify on docs.chain.link
- Feeds update based on deviation threshold and heartbeat — not every block
- Check `latestRoundData()` not just `latestAnswer()` — includes timestamp and round info
- Stale data check critical — verify `updatedAt` timestamp is recent

## Oracle Integration Patterns
- Direct consumer: your contract calls feed directly — simplest approach
- Chainlink Automation (Keepers): trigger actions based on conditions — no server needed
- VRF (Verifiable Random Function): provably fair randomness — for NFT mints, games, lotteries
- Functions: connect to any API — custom off-chain computation
- CCIP: cross-chain messaging — official Chainlink interoperability protocol

## VRF Usage
- Request/receive pattern: request randomness, receive in callback — not synchronous
- Each request costs LINK — fund subscription or pay per request
- Confirmation blocks add security but delay — more confirmations = more secure
- Randomness is verifiable on-chain — anyone can verify it wasn't manipulated

## Common Developer Mistakes
- Hardcoding feed addresses — use address registry or config
- Not checking for stale data — price feeds can stop updating
- Assuming instant updates — deviation thresholds mean prices can be slightly stale
- Not handling VRF callback failures — callback can revert, losing the randomness
- Insufficient LINK for subscriptions — requests fail silently when underfunded

## Network Comparisons
- Ethereum mainnet: highest security, highest gas costs
- L2s (Arbitrum, Optimism): lower cost, same security model
- Alt-L1s (Polygon, Avalanche): native integration, different trust assumptions
- Testnets: Sepolia for Ethereum, network-specific for others

## Security Considerations
- Only use official Chainlink feeds — verify contract addresses on docs.chain.link
- Monitor for feed deprecation — Chainlink announces deprecated feeds
- Multi-oracle pattern for critical systems — don't rely on single source
- Circuit breakers for extreme price movements — protect against oracle manipulation

## CCIP (Cross-Chain)
- Send messages and tokens across chains — official Chainlink bridge
- Lane availability varies — not all chain pairs supported
- Fee estimation before sending — paid in LINK or native token
- Message finality depends on source and destination chains

## Ecosystem
- Node operators earn LINK for providing data — professional infrastructure required
- BUILD program for projects integrating Chainlink — access to resources and support
- Extensive documentation at docs.chain.link — primary reference for developers
- Community resources: Discord, Stack Overflow, GitHub