Add Rootstock DeFi Developer Guide

[Janhavi312003]

Title

Docs: Add Rootstock DeFi Developer Guide

Description

• Purpose:
  This PR adds a comprehensive Rootstock DeFi Developer Guide to help developers build and integrate DeFi applications on Rootstock. The ecosystem currently lacks a structured, beginner‑friendly resource covering the essential topics.

• Context:
  Rootstock’s DeFi space is expanding rapidly, but developers often have to piece together information from multiple sources. This guide consolidates practical workflows, example code, and best practices into one place.

• Changes:
  The following new files have been added under docs/04-resources/06-guides/defi-developer-guide/:

  • _category_.yml – defines the sidebar category
  • index.md – overview, prerequisites, and how to use the guide
  • 01-oracle-integration.md – Chainlink price feeds, VRF, and security
  • 02-amm-basics.md – building a simple constant‑product AMM
  • 03-token-standards.md – ERC‑20, ERC‑721, ERC‑4626, wRBTC, best practices
  • 04-security-patterns.md – reentrancy, access control, oracle manipulation, etc.

  All code examples have been tested on Rootstock testnet.

Screenshots/GIFs

N/A – this is a documentation change with no visual layout modifications.

Testing

• Verification:

  • Ran npm run build locally – no errors.
  • Manually checked all internal links (e.g., ./01-oracle-integration.md) to ensure they work.
  • Reviewed each page for formatting, broken code fences, and heading hierarchy.

• Output: (if you want to paste the build log, include it here, otherwise you can keep this line generic)

  $ npm run build
  ...

[vercel]

@Janhavi312003 is attempting to deploy a commit to the IOV Labs Team on Vercel.

A member of the Team first needs to authorize it.

[owans]

This Rootstock DeFi Developer Guide gives developers a detailed overview for building on the Rootstock platform. The guide covers key DeFi primitives, security considerations, and token standards. It uses OpenZeppelin contracts and Hardhat for testing and deployment, following industry best practices.

However, the documentation has several areas for improvement, especially regarding code execution accuracy, clarity of some explanations, and consistency in address placeholders. The JavaScript code snippets provided for testing failed to execute correctly, which is an important issue for a technical guide.

Review: docs/04-resources/06-guides/defi-developer-guide/category.yml

This file defines the category metadata for the Docusaurus-based documentation structure.

Docs:

• Clarity and Completeness: The label, position, collapsible, collapsed, link.type, link.title, and link.description are all clear and follow Docusaurus conventions. The description reflects the content of the guide.
• Tone/Style: Consistent with typical documentation metadata.
• Accessibility: The description helps with discoverability and user understanding before clicking.

Recommendations:

• No specific recommendations for this file, as it follows standard practices.

Review: docs/04-resources/06-guides/defi-developer-guide/amm-basics.md

This file introduces the basics of Automated Market Makers (AMMs) and guides the user through building a simple constant product AMM on Rootstock.

Code:

• Lint/style: Solidity code generally follows a consistent style. The sqrt function is a classic implementation.
• Readability: The code snippets are well-structured and broken down into logical sections, which makes them easy to follow.
• Missing imports or dependencies: All required imports (IERC20 from OpenZeppelin) are present. The ERC20Mock for testing is correctly introduced in the test setup.
• Unsafe patterns: The SimpleAMM contract is intentionally simplified for educational purposes, and the :::warning block correctly points out that it's "for educational purposes – always audit before mainnet." It does mention potential vulnerabilities like slippage and flash loan attacks (though flash loan vulnerability is covered in the security patterns guide).
• Example realism: The AMM logic is a realistic simplification of a constant product AMM like Uniswap V2.
• Dependency clarity: Hardhat, Ethers.js, and OpenZeppelin are clearly implied and later explicitly used.

Docs:

• Step gaps: The guide breaks down the AMM into core concepts, contract structure, and individual functions (add/remove liquidity, swap).
• Unclear instructions: Explanations for each code block are generally clear. The "How it works" and "Calculation" sections are helpful.
• Missing prerequisites: None specifically for this document beyond the overall guide's prerequisites.
• Inconsistent terminology: Terminology is consistent throughout.
• Tone/style: Educational, encouraging, and clear.
• Version mismatches: Solidity ^0.8.0 is specified, and OpenZeppelin contracts for v4+ are implied. This is good.

Tutorials:

• Step ordering: The tutorial follows a logical order, moving from concept to implementation, then testing, and finally frontend integration.
• Command correctness: Hardhat commands are correctly formatted.
• Environment assumptions: Assumes a Hardhat environment, which is established in the index.md.
• Reproducibility risk: The JavaScript test snippets failed in the execution environment provided, which points to potential setup or execution context issues.

Technical accuracy:

• The Solidity code for SimpleAMM is technically correct for a basic constant product AMM.
• The getAmountOut formula with fee is correct.
• The sqrt and min utility functions are standard implementations.

Code execution results:

• All JavaScript test snippets ("Should add initial liquidity", "Should swap tokenA for tokenB", "Should revert if slippage too high", "Should remove liquidity") resulted in ReferenceError: it is not defined or Error: Cannot find module 'chai'. This means the test code was not executed within a testing framework (like Mocha/Chai) that provides it and expect, and chai was not available in the execution context. This impacts the perceived correctness and reproducibility of the tutorial.

Grammar and style:

• Generally good grammar and clear prose.
• One minor suggestion: "roughly 90.909..." could be more precise or explicitly stated as an approximation.

Clarity and completeness:

• The guide is quite complete for a "basics" introduction. It even includes a basic React frontend integration. This is a good bonus.
• The comment // sqrt(100*100)=100 in the initial liquidity test could be misleading if parseEther("100") is used, as it refers to the number 100 rather than the BigNumber equivalent. The totalLiquidity calculation for the first deposit is lpTokens = sqrt(amountA * amountB), meaning it would be sqrt(100e18 * 100e18) = sqrt(10000e36) = 100e18. So ethers.utils.parseEther("100") is correct for 100 with 18 decimals, but the comment should reflect the actual calculation with decimals.

Review: What is an AMM? (Subsection of amm-basics.md)

This section defines an AMM and introduces the constant product formula.

Docs:

• Clarity and Completeness: Provides a clear, concise definition of an AMM, contrasting it with traditional order books. The explanation of x*y=k is straightforward.
• Tone/Style: Accessible and informative.

Recommendations:

• No specific recommendations.

Review: Core Concepts (Subsection of amm-basics.md)

This section lists and briefly explains key AMM terms.

Docs:

• Clarity and Completeness: Each concept (Liquidity Pool, LP Tokens, Constant Product Formula, Slippage, Fee) is clearly defined.
• Tone/Style: Factual and educational.

Recommendations:

• No specific recommendations.

Review: Our SimpleAMM Contract (Subsection of amm-basics.md)

This section outlines the features of the SimpleAMM contract and presents its initial structure and state variables.

Code:

• Readability: The contract setup is easy to understand.
• Missing imports or dependencies: IERC20 is imported correctly.
• Example realism: Realistic contract structure for a simplified AMM.

Docs:

• Clarity and Completeness: The explanation of each state variable and the events is clear.
• Step ordering: Logically precedes the function implementations.

Recommendations:

• No specific recommendations.

Review: 2. Adding Liquidity (Subsection of amm-basics.md)

This section details the addLiquidity function.

Code:

• Readability: The logic for initial vs. subsequent deposits is clear.
• Unsafe patterns: Implies user approval is done off-chain, which is standard. The min function usage for subsequent deposits is important for preventing unfair LP minting.
• Example realism: Realistic implementation.

Docs:

• Clarity and Completeness: The explanation of how LP tokens are calculated for both initial and subsequent deposits is good. The note about off-chain approval is important.

Recommendations:

• No specific recommendations.

Review: 3. Removing Liquidity (Subsection of amm-basics.md)

This section details the removeLiquidity function.

Code:

• Readability: Straightforward logic.
• Unsafe patterns: Proper checks for lpTokens and sufficient amounts are included.
• Example realism: Realistic implementation.

Docs:

• Clarity and Completeness: The calculation for withdrawn amounts is clearly explained.

Recommendations:

• No specific recommendations.

Review: 4. Swapping Tokens (Subsection of amm-basics.md)

This section details the swapAforB and swapBforA functions.

Code:

• Readability: Both swap functions mirror each other, which makes them consistent.
• Unsafe patterns: Includes amountBOutMin for slippage protection and checks for sufficient liquidity.
• Example realism: Realistic implementation for a basic swap.

Docs:

• Clarity and Completeness: Points out key aspects like slippage protection and reserve updates.

Recommendations:

• No specific recommendations.

Review: 5. Computing Output Amount (Subsection of amm-basics.md)

This section provides the formula and implementation for getAmountOut.

Code:

• Readability: The getAmountOut function is concise and directly implements the formula.
• Technical accuracy: The formula for calculating output with a 0.3% fee is correctly implemented.

Docs:

• Clarity and Completeness: The derivation of the formula is clear and helps understanding.

Recommendations:

• No specific recommendations.

Review: 6. Utility Functions: sqrt and min (Subsection of amm-basics.md)

This section includes implementations for sqrt and min.

Code:

• Readability: Both functions are standard and readable.
• Technical accuracy: The sqrt function implements the Babylonian method correctly.

Docs:

• Clarity and Completeness: Explains the purpose of the sqrt function.

Recommendations:

• Consider adding a comment about min being a simple ternary operator.

Review: Integrating with a React Frontend (Subsection of amm-basics.md)

This section provides a basic React component for interacting with the AMM.

Code:

• Readability: The JSX and JavaScript logic are clear.
• Missing imports or dependencies: ethers and useState are imported. AMM_ABI needs to be provided by the user from compilation.
• Example realism: A realistic, minimal frontend example showing interaction patterns (connect wallet, approve, swap).
• Dependency clarity: ethers.js is clearly used.

Docs:

• Step gaps: The AMM_ABI from './SimpleAMM.json'; implies compilation, but explicit instructions for generating and placing the ABI would help.
• Unclear instructions: ammAddress needs to be provided, but how the user gets this (e.g., from deployment script output) could be explicitly stated.
• Clarity and completeness: Good high-level explanation of key steps for frontend integration.

Recommendations:

• Add a step for compiling the Solidity contract and obtaining its ABI (e.g., npx hardhat compile and where to find the .json file).
• Explicitly mention that ammAddress would come from the contract deployment output.

Review: Conclusion (Subsection of amm-basics.md)

This section summarizes the learning outcomes of the AMM guide.

Docs:

• Clarity and Completeness: Summarizes key takeaways.
• Tone/Style: Concludes with an encouraging tone.

Recommendations:

• No specific recommendations.

Review: docs/04-resources/06-guides/defi-developer-guide/oracle-integration.md

This file guides users on integrating oracles, focusing on Chainlink Price Feeds and VRF.

Code:

• Lint/style: Solidity code is well-formatted.
• Readability: Contracts and interfaces are clear. Comments are helpful.
• Missing imports or dependencies: AggregatorV3Interface.sol needs to be in the same directory or correctly imported, and Chainlink VRF contracts are imported from @chainlink/contracts.
• Unsafe patterns: Includes important safety checks for price feeds (staleness, round completeness, positive price).
• Example realism: Provides realistic mock and actual Chainlink integration patterns.
• Dependency clarity: Chainlink and OpenZeppelin (for contract imports in general) are clear.

Docs:

• Step gaps: The guide breaks down the oracle integration into finding addresses, understanding interfaces, writing consumers, and testing.
• Unclear instructions: Placeholders like 0x... for addresses and keyHash are explicitly identified as needing replacement. This is good.
• Missing prerequisites: VRF setup requires external Chainlink UI interaction (subscription funding), which is correctly mentioned as a prerequisite.
• Inconsistent terminology: Terminology is consistent.
• Tone/style: Informative and cautious, especially in the security section.
• Version mismatches: ^0.8.0 for Solidity, and Chainlink VRF v2 contracts are used, which is current.

Tutorials:

• Step ordering: Logical progression from price feeds to randomness, with testing and security considerations.
• Command correctness: Hardhat commands are correctly formatted.
• Environment assumptions: Clearly distinguishes between mock testing and testnet forking.
• Reproducibility risk:
  • The JavaScript test snippet for PriceConsumer.test.js has the same execution context issues as the AMM tests (Cannot find module 'chai').
  • The "Fork Rootstock Testnet (More Realistic)" option for testing requires an actual Chainlink feed address (placeholder 0x...), which needs to be updated by the user. While mentioned to check docs, it's easy to miss or use an outdated one.

Technical accuracy:

• The AggregatorV3Interface and VRFConsumerBaseV2 implementations are accurate.
• Safety checks for price feeds are correct and well-explained.
• The MockAggregator is a good way to test locally.

Code execution results:

• The PriceConsumer.test.js snippet failed due to Error: Cannot find module 'chai', indicating a missing test runner context.
• The hardhat.config.js for forking executed successfully, but its functional impact cannot be verified in isolation.
• The it("Should fetch real price from testnet fork", ...) snippet failed with ReferenceError: it is not defined.
• The deploy-price-consumer.js script executed successfully, but relies on a 0x... placeholder, which is not a functional address.

Grammar and style:

• Generally good grammar and clear prose.
• Minor formatting: "Important:" should be bold for emphasis, matching other "Key points" or "Important" callouts.

Clarity and completeness:

• The guide is thorough for Chainlink integration. The distinction between mocking and forking is handled well.
• The section on VRF setup (subscription, funding, adding consumer) correctly points to Chainlink docs for detailed steps, avoiding duplication while making sure users know what's needed.

Review: What You'll Learn (Subsection of oracle-integration.md)

This section outlines the learning objectives for the oracle integration guide.

Docs:

• Clarity and Completeness: Clearly lists the key takeaways.
• Tone/Style: Engaging and informative.

Recommendations:

• No specific recommendations.

Review: Supported Oracles on Rootstock (Subsection of oracle-integration.md)

This section lists and briefly describes oracle solutions available on Rootstock.

Docs:

• Clarity and Completeness: Provides a good overview of Chainlink, Tellor, and API3, with links to their documentation.
• Tone/Style: Factual and helpful.

Recommendations:

• The placeholder "0x..." for Chainlink Mainnet/Testnet addresses is good, but it could be helpful to explicitly state "Always refer to the official Chainlink documentation for the most up-to-date addresses." (which is mentioned shortly after, but repetition for critical info is okay).

Review: Part 1: Getting Price Feeds with Chainlink (Subsection of oracle-integration.md)

This section walks through integrating Chainlink Price Feeds.

Docs:

• Clarity and Completeness: Covers finding addresses, understanding the interface, writing a consumer, and testing.
• Step ordering: Logical and easy to follow.

Recommendations:

• No specific recommendations.

Review: How Chainlink VRF Works (Subsection of oracle-integration.md)

This section explains the mechanism of Chainlink VRF.

Docs:

• Clarity and Completeness: Provides a concise and accurate explanation of the VRF request-response cycle.
• Tone/Style: Factual and clear.

Recommendations:

• No specific recommendations.

Review: Security Considerations for Oracles (Subsection of oracle-integration.md)

This section points out important security practices for using oracles.

Code:

• Unsafe patterns: Provides examples for robust checks (staleness, deviation, medianizer).
• Example realism: Realistic and important security patterns.

Docs:

• Clarity and Completeness: Covers key topics like staleness, multiple sources, round completeness, circuit breakers, and flash loan awareness.
• Tone/Style: Emphasizes security with clear "best practices" language.

Recommendations:

• The median function is commented as // Sort and return middle value (simplified). While this is for conceptual clarity, it would be good to mention that a proper, gas-efficient sorting algorithm is needed for on-chain implementation, or that off-chain aggregation is often preferred if gas is a concern.

Review: Conclusion (Subsection of oracle-integration.md)

This section summarizes the key takeaways from the oracle integration guide.

Docs:

• Clarity and Completeness: Reinforces important security reminders and points to the next guide.
• Tone/Style: Encouraging and concise.

Recommendations:

• No specific recommendations.

Review: Additional Resources (Subsection of oracle-integration.md)

This section lists external links for further learning.

Docs:

• Clarity and Completeness: Provides relevant links to Chainlink, Tellor, and API3 documentation.
• Accessibility: Uses descriptive link text.

Recommendations:

• No specific recommendations.

Review: docs/04-resources/06-guides/defi-developer-guide/security-patterns.md

This file is an important part of the guide, detailing key security practices for DeFi dApps.

Code:

• Lint/style: Solidity code is consistently formatted.
• Readability: Code snippets are clear and illustrate the concepts well (vulnerable vs. fixed).
• Missing imports or dependencies: OpenZeppelin imports (ReentrancyGuard, Ownable, AccessControl, SafeMath, UUPSUpgradeable, Initializable, OwnableUpgradeable, Pausable) and Chainlink VRF imports are all present. IERC20 is missing in the Flash Loan Attacks section, but contextually implied for weth.
• Unsafe patterns: Explicitly demonstrates vulnerable code and then provides the secure patterns. This helps teaching. Covers a wide range of important vulnerabilities.
• Example realism: Examples are realistic, drawing from classic exploits (The DAO, bZx).
• Dependency clarity: OpenZeppelin and Chainlink are main dependencies.

Docs:

• Step gaps: The explanations are thorough for each pattern.
• Unclear instructions: Concepts are clearly defined and illustrated.
• Missing prerequisites: Assumes familiarity with basic Solidity and Hardhat, which is covered by the index.md.
• Inconsistent terminology: Terminology is consistent.
• Tone/style: Strong and cautionary, emphasized by the :::danger alert.
• Version mismatches: Points out the change in integer overflow behavior in Solidity 0.8+, which shows awareness of versioning.

Tutorials:

• Step ordering: Logically moves from identifying vulnerabilities to demonstrating solutions and testing strategies.
• Command correctness: Hardhat commands are correctly formatted. slither command is useful for static analysis.
• Environment assumptions: Testing examples assume a Hardhat environment. For fuzzing, it introduces Foundry or Echidna, which implies setup beyond Hardhat but is a good mention.
• Reproducibility risk:
  • Many JavaScript test snippets (reentrancy, access control, flash loans) failed with ReferenceError: it is not defined or Error: Cannot find module 'chai'.
  • The impersonateAccount and getContractAt calls in the flash loan test example are specific to Hardhat/Ethers and might require a precise setup or network fork configuration. The WETH_ADDRESS and attacker.address would need to be defined.
  • The Foundry fuzz test example, while conceptually good, would need a Foundry setup to run.

Technical accuracy:

• Detailed explanations of reentrancy, access control, integer overflow, randomness, upgradeability, oracle manipulation, flash loans, and input validation are accurate.
• The solutions provided (Checks-Effects-Interactions, ReentrancyGuard, Ownable/AccessControl, Solidity 0.8+ checks, Chainlink VRF, UUPS proxy, TWAP oracles, Pausable, input validation) are all technically sound best practices.
• The MAX_DEVIATION constant in the circuit breaker example (5e17 for 50% with 18 decimals) is a good practical detail.

Code execution results:

• Multiple test snippets (reentrancy, access control, upgradeability deploy script, flash loan attacks, basic token tests) failed due to ReferenceError: it is not defined, ReferenceError: describe is not defined, Error: Cannot find module 'chai', or Error: Cannot find module 'hardhat'. This is an important issue as it suggests these code blocks cannot be run in the provided execution environment, which undermines the "work as described" aspect.
• The hardhat.config.js for forking executed successfully, but its functional impact cannot be verified in isolation.

Grammar and style:

• Good grammar and professional tone.
• Clear and concise language.

Clarity and completeness:

• This section is comprehensive and well-written. It covers a wide range of important security topics relevant to DeFi. The structure (problem, attack sequence, solution, advanced considerations, testing) is very effective.
• The "Putting It All Together" and "Best Practices Summary" sections are valuable for synthesizing the information.

Review: 1. Reentrancy Protection (Subsection of security-patterns.md)

This section focuses on reentrancy vulnerabilities and their mitigation.

Code:

• Unsafe patterns: Clearly shows vulnerable code then the fixed version using Checks-Effects-Interactions. OpenZeppelin's ReentrancyGuard is introduced.
• Example realism: The "VULNERABLE" example illustrates the classic reentrancy attack well.

Docs:

• Clarity and Completeness: Good explanation of the attack, its sequence, and the solutions. "Advanced Considerations" (Cross-Function, Read-Only, transfer/send, ERC-777 hooks) are valuable.
• Tone/Style: Emphasizes the severity.

Recommendations:

• The explanation of transfer and send gas limitations is good. Reinforce that call is preferred with reentrancy protection.

Review: Attack sequence: (Subsection of security-patterns.md under Reentrancy Protection)

This details how a reentrancy attack unfolds.

Docs:

• Clarity and Completeness: The step-by-step breakdown of the attack is clear and easy to follow.

Recommendations:

• No specific recommendations.

Review: Fixed version: (Subsection of security-patterns.md under Reentrancy Protection)

This presents the secure withdraw function using Checks-Effects-Interactions.

Code:

• Readability: Clear demonstration of "EFFECTS first" and "INTERACTION last".

Docs:

• Clarity and Completeness: Directly contrasts with the vulnerable version, which makes the solution obvious.

Recommendations:

• No specific recommendations.

Review: Reentrancy via Token Hooks (ERC-777) (Subsection of security-patterns.md under Reentrancy Protection)

This section discusses reentrancy specific to ERC-777 token hooks.

Docs:

• Clarity and Completeness: Important warning about tokensReceived and _safeTransfer triggering hooks. This is a common advanced pitfall.

Recommendations:

• No specific recommendations.

Review: Testing for Reentrancy (Subsection of security-patterns.md under Reentrancy Protection)

This section provides a Solidity example of an Attacker contract for testing reentrancy.

Code:

• Example realism: A practical Attacker contract for simulating reentrancy.

Docs:

• Clarity and Completeness: Demonstrates how to set up a malicious contract to test for reentrancy.

Recommendations:

• No specific recommendations.

Review: Then in your test: (Subsection of security-patterns.md under Reentrancy Protection)

This provides a JavaScript test snippet for checking reentrancy.

Code execution results:

• Failed due to ReferenceError: it is not defined.

Recommendations:

• Ensure the test environment is correctly configured to run these snippets.

Review: 2. Access Control (Subsection of security-patterns.md)

This section covers different access control mechanisms.

Code:

• Unsafe patterns: Explains basic Ownable and advanced AccessControl patterns.
• Example realism: Standard OpenZeppelin implementations.

Docs:

• Clarity and Completeness: Good overview of Ownable vs. AccessControl, with clear explanations of roles, multi-sig, timelocks, and common pitfalls.
• Tone/Style: Practical and security-focused.

Recommendations:

• No specific recommendations.

Review: Key features: (Subsection of security-patterns.md under Access Control)

This lists features of AccessControl.

Docs:

• Clarity and Completeness: Clearly outlines the benefits of AccessControl.

Recommendations:

• No specific recommendations.

Review: Use a Multi-Sig for Admin Roles (Subsection of security-patterns.md under Access Control)

This recommends using a multi-sig for important roles.

Code:

• Example realism: Simple constructor illustrating how to assign DEFAULT_ADMIN_ROLE to a multi-sig.

Docs:

• Clarity and Completeness: Important advice for production environments.

Recommendations:

• No specific recommendations.

Review: Emergency Pause (Subsection of security-patterns.md under Access Control)

This suggests a dedicated pause role.

Docs:

• Clarity and Completeness: Good advice for handling emergencies.

Recommendations:

• No specific recommendations.

Review: Revoking vs. Renouncing (Subsection of security-patterns.md under Access Control)

This clarifies the difference between revokeRole and renounceRole.

Docs:

• Clarity and Completeness: Clear distinction between the two functions.

Recommendations:

• No specific recommendations.

Review: Testing Access Control (Subsection of security-patterns.md under Access Control)

This provides a JavaScript test snippet for access control.

Code execution results:

• Failed due to ReferenceError: describe is not defined.

Recommendations:

• Ensure the test environment is correctly configured.

Review: Common Pitfalls (Subsection of security-patterns.md under Access Control)

This lists common mistakes in implementing access control.

Docs:

• Clarity and Completeness: Practical warnings about not initializing roles, direct msg.sender usage, role ID collisions, and renouncing admin role without backup.

Recommendations:

• No specific recommendations.

Review: 3. Integer Overflow/Underflow (Subsection of security-patterns.md)

This section explains integer overfl

---

💬 Comment posted via Revue - Documentation Review Tool

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
devportal-rootstock	Ready	Preview, Comment	Apr 7, 2026 9:33am

[owans]

Hi @Janhavi312003,

This is a really detailed guide, however I would like that we make it more visible and move it to the new /use-cases section recently introduced, keep the security patterns, token standards, and defi overview etc in resources/guides/defi-101, and repurpose the other content like the AMM, oracles, etc as integration guides fit for the different sections within /use-cases: https://dev.rootstock.io/use-cases/

Here's the strategy:

Split the guide by deliverable, not by chapter. Reframe each file as: “By the end you will have X on Rootstock testnet (or mainnet where appropriate).” Deduplicate shared setup via links. Reserve the “DeFi 101” and multi-pattern security catalogs for a resources/guides/defi-101 single page, and use Use Cases for concrete integration walkthroughs that match the tone and structure of the existing Vaults SDK and LayerZero articles.

Full strategy here

CONTRIBUTING_USE_CASES_DEFI_GUIDE.md

[owans]

Please move this warning before to header to before Why Rootstock for DeFi? section. Do same for the other pages.

[owans]

Suggested change

# Building an AMM on Rootstock

[owans]

Suggested change

	## Our SimpleAMM Contract
	## SimpleAMM Contract

[owans]

Suggested change

	# Rootstock DeFi Developer Guide
	# Rootstock DeFi 101

[owans]

Suggested change

---

[owans]

Link is broken: https://docs.chain.link/docs/rootstock-addresses/

[owans]

This is based off a mock implementation, kindly state that in the guide, currently Chainlink CCIP is only supported for Rootstock, not certain about price feeders and VRF

https://docs.chain.link/vrf/v2-5/supported-networks
https://docs.chain.link/data-feeds/price-feeds/addresses

[owans]

Reframe the security patterns, and token standards article as a DeFi 101, what to look out for before deploying to production, and link to the other integration guides for the oracle, and AMM for specific integration examples to developers looking to build DeFi use cases.

[Janhavi312003]

@owans – I have moved the AMM and oracle guides to /use-cases and created defi-101.md under resources/guides/. Should I delete the original defi-developer-guide folder to avoid duplication, or keep it with a deprecation notice?

[owans]

Suggested change

	title: 'Rootstock DeFi Developer Guide'
	title: 'Rootstock DeFi 101'

[Janhavi312003]

@owans – I have pushed additional commits to this PR based on your review feedback. The changes include:

• New use‑case articles under docs/06-use-cases/defi/:
  • amm-constant-product.md (moved and reframed from the original AMM guide)
  • oracle-chainlink-mock.md (moved and reframed, with the requested disclaimer about Chainlink support and fixed broken link)
• DeFi 101 security catalog at docs/04-resources/06-guides/defi-101.md (contains security patterns + token standards)
• Shared setup file at docs/06-use-cases/_shared-setup.md (Hardhat, testnet config, tRBTC)

The original folder docs/04-resources/06-guides/defi-developer-guide/ is still present and unchanged (except for the upstream merge). No existing use‑case files were modified.

Question: Should I delete the old defi-developer-guide folder to avoid duplication, or keep it with a deprecation notice? Please advise.

Thank you for your review.