SDK and Contract Operations

Raphael contracts can be integrated with standard ABI clients. Use Raphael's verified ABIs and addresses; upstream interfaces are useful references, but they are not deployment records.

Basic liquidity

A typical add-liquidity flow is:

1. read token decimals and pool state;
2. call the router's quote function for the intended deposit;
3. compute minimum accepted amounts from an explicit slippage policy;
4. approve the router;
5. call the appropriate add-liquidity function with a future deadline.

Basic pool positions are normally fungible ERC-20 LP tokens.

To remove liquidity, ensure the router can spend the LP tokens and pass minimum token outputs.

Basic-pool fees and staking

Depending on the deployed interfaces:

• claim unstaked LP fees from the pool or fee contract;
• approve the gauge to spend LP tokens;
• stake with the gauge deposit function;
• unstake with the gauge withdrawal function;
• claim emissions using the gauge reward function.

The economic consequences of staking are covered in Fees, Staking and Gauges.

Concentrated positions

A concentrated-liquidity flow normally uses the nonfungible position manager:

1. resolve token order, current price and tick spacing;
2. choose valid lower and upper ticks;
3. estimate token amounts;
4. approve both tokens;
5. mint an ERC-721 position;
6. optionally approve and deposit the token ID into a compatible gauge.

Collect fees before burning an empty position. A position can generally be burned only after liquidity, fees and gauge rewards have been handled.

Transaction safety

Every state-changing integration should:

• verify chain ID 4663 or 46630 as intended;
• use checksummed verified addresses;
• set deadlines;
• set minimum outputs;
• simulate before submission;
• handle ERC-20 tokens with non-standard return values carefully;
• wait for a suitable confirmation policy;
• surface revert reasons and the submitted transaction hash.