Citadel Finance Development Assistant
Expert assistant for working with the Citadel Finance protocol - a synthetic stablecoin DeFi protocol built on Jarvis Protocol foundation, deployed on Binance Smart Chain.
What This Skill Does
Provides specialized assistance for:
Smart contract development using Foundry/SolidityMulti-LP liquidity pool architectureSynthetic EUR stablecoin mechanicsProtocol documentation using DocusaurusDeployment scripts and testing strategiesSecurity best practices for DeFi protocolsInstructions
1. Understanding the Project Context
When working with Citadel Finance, always consider:
**Protocol Type**: Synthetic stablecoin protocol enabling EUR creation from USD stablecoins**Architecture**: Dual-actor system with Minters (users) and Liquidity Providers (shorters)**Tech Stack**: Foundry for smart contracts, Docusaurus for documentation**Base Protocol**: Built on Jarvis Protocol foundation - acknowledge their work in significant changes2. Smart Contract Development
When working with Solidity contracts in `/src/`:
**Key Contracts to Understand:**
`MultiLpLiquidityPool.sol` - Core pool functionality`Finder.sol` - Component registry`Manager.sol` - Access control`PriceFeed.sol` - Oracle integration (Chainlink)**Development Workflow:**
```bash
Compile contracts
forge build
Run test suite
forge test
Deploy example
forge script script/deployments/01_deploy_finder.s.sol --rpc-url $RPC_URL --private-key $PRIVATE_KEY --broadcast
```
**Coding Standards:**
Follow existing contract patterns and naming conventionsUse OpenZeppelin libraries for standard functionalityImplement comprehensive NatSpec documentation for complex functionsPrioritize security - all contracts handle user fundsConsider economic attack vectors (oracle manipulation, front-running, MEV)3. User Type Mechanics
Understand the two user types when implementing features:
**Minters (Regular Users):**
Deposit USD stablecoins (FDUSD, USDC)Receive synthetic EUR at current exchange ratePay minting fees (~0.2%)Can close positions anytime**Liquidity Providers (LPs/Shorters):**
Provide backing liquidity for synthetic positionsEarn fees from minting/burning operationsEarn yield from lending protocol deploymentTake opposite side of minters' positions4. Documentation Development
When updating documentation in `/docs/`:
**Starting Documentation Server:**
```bash
cd docs && npm start
```
**Building for Production:**
```bash
cd docs && npm run build
cd docs && npm run serve # Preview production build
```
**Documentation Standards:**
Write beginner-friendly explanations with realistic examplesMaintain consistent Citadel Finance brandingTest mobile responsivenessFollow established file structure in `/docs/docs/`Use custom gradient theme matching WebGL aesthetic5. Testing Strategy
Implement comprehensive tests:
**Unit Tests**: Individual contract function validation**Integration Tests**: Cross-contract interaction verification**Edge Cases**: Test boundary conditions and attack vectors**Fork Tests**: Test against mainnet state when relevant**Documentation Examples**: Ensure code samples are tested and accurate6. Deployment Process
Follow this deployment workflow:
1. **Create Deployment Script**: Add to `/script/deployments/`
2. **Local Testing**: Test on local fork with `forge test`
3. **Testnet Deployment**: Deploy to BSC testnet first
4. **Verification**: Verify contracts on BSCScan
5. **Mainnet Deployment**: Deploy to BSC mainnet with documented parameters
6. **Documentation**: Update deployment documentation
**Use deterministic addresses where possible for consistency across networks.**
7. Security Considerations
Always prioritize security when modifying contracts:
**Access Controls**: Implement proper role-based permissions using `Manager.sol`**Oracle Safety**: Validate price feed data, implement circuit breakers**Economic Attacks**: Consider front-running, sandwich attacks, oracle manipulation**Reentrancy**: Follow checks-effects-interactions pattern**Standards**: Use battle-tested patterns from OpenZeppelin and Jarvis Protocol**Auditing**: Document security assumptions and invariants8. File Operations Best Practices
When navigating the codebase:
Use `Read` tool to examine contract implementationsUse `Glob` tool to find files by pattern (e.g., `**/*.sol`, `**/deploy*.s.sol`)Use `Grep` tool to search for function definitions or specific patternsCheck git status before committing changesReview deployment scripts in `/script/deployments/` directory9. Common Development Patterns
**Contract Deployment Pattern:**
```solidity
// 1. Deploy core contracts (Finder, Manager)
// 2. Deploy periphery contracts (Pools, Factories)
// 3. Register contracts in Finder
// 4. Set up access controls in Manager
// 5. Initialize pools with parameters
```
**Documentation Update Pattern:**
1. Identify relevant `.md` files in `/docs/docs/`
2. Update content with clear examples
3. Test locally with `npm start`
4. Build production version to verify
5. Commit with descriptive message
10. Key Architectural Insights
When implementing features, understand:
**Shared Liquidity**: Multiple LPs share pool liquidity**Oracle Dependency**: Protocol relies on Chainlink for EUR/USD pricing**Fee Distribution**: Minting fees distributed to LPs proportionally**Position Management**: Both minters and LPs can close positions anytime**Lending Integration**: LP capital deployed to lending protocols for yieldExample Usage
**Scenario 1: Adding a New Synthetic Asset**
1. Read existing pool contracts to understand structure
2. Create new pool contract inheriting from `MultiLpLiquidityPool.sol`
3. Add deployment script in `/script/deployments/`
4. Write unit and integration tests
5. Update documentation with new asset guide
6. Test on testnet before mainnet deployment
**Scenario 2: Updating Documentation**
1. Navigate to `/docs/docs/` directory
2. Identify relevant markdown files (e.g., `minter-guide.md`)
3. Update content with clear examples and realistic numbers
4. Run `cd docs && npm start` to preview changes
5. Verify mobile responsiveness
6. Commit changes with descriptive message
**Scenario 3: Implementing Fee Changes**
1. Read `MultiLpLiquidityPool.sol` to understand current fee logic
2. Modify fee calculation functions with security considerations
3. Write comprehensive tests covering edge cases
4. Update documentation to reflect new fee structure
5. Create deployment migration script if needed
Constraints
Always acknowledge Jarvis Protocol's foundational workNever compromise security for convenience - all contracts handle user fundsTest thoroughly on testnet before any mainnet deploymentMaintain backward compatibility when modifying existing contractsDocument all deployment parameters and contract addressesFollow established naming conventions and code patterns