> For the complete documentation index, see [llms.txt](https://docs.usefarlight.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usefarlight.com/architecture/deployment.md). # Building and deploying the contracts Building and testing the Farlight contracts, standing up a new environment with the deploy script, and finding the addresses that are live on Robinhood Chain. The contracts are a Foundry project in the `contracts/` directory at the root of the Farlight repository. This page covers the build, the test suite, the deploy script and local development. ## Which addresses are live There is one authoritative record of what is deployed on Robinhood Chain (chain ID 4663): `contracts/deployments/4663.json` in the repository. The platform reads the same addresses from the `deployment` row of its protocol parameters, and the Observatory, the public loan explorer, shows the `LoanDesk` address on its parameters panel. Treat any address that is missing from that file as untrusted. Every deployment has its source verified on Blockscout. ## Build and test ```bash cd contracts forge soldeer install # forge-std and OpenZeppelin into dependencies/, no git submodules forge build forge test -vv ``` The suite holds 65 tests in five files, each built on the shared `Base.t.sol` fixture: | File | What it exercises | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Origination.t.sol` | A syndicate of three lenders; the LTV ceiling; an ineligible borrower and an ineligible lender; an APR mismatch; cancelled offers; standing offers reused across several loans; the relayer path; the exposure cap; the guardian pause; fills drawn from idle capital | | `Repayment.t.sol` | Accrual per slice, checked against the worked example in the documentation; the minimum interest period; full and partial repayment; top-ups; repayment during grace and while paused; repayment by a third party | | `CollateralAuction.t.sol` | Tracking of the health factor; a full Dutch auction through to the distribution of proceeds; partial buys; the liquidator role; default after grace; sequencer grace; the oracle pause; the move cap; the closed-market haircut; separating out opt-outs; in-kind settlement; the requirement for a stream report | | `Rollover.t.sol` | The rules for opening; the linear rate; clearing with a new syndicate; failure and default; the rate ceiling; cancellation by the borrower; liquidation while a refinance is open | | `Policy.t.sol` | Bootstrap and the timelock; the scope of the guardian; validation of parameters; expiry and revocation of attestations; removal of an issuer; the gated slice token transfer; withdrawal of fees; one-shot wiring | ## Deploying to a new environment Copy `.env.example` to `.env` and provide at least these two values: ``` PRIVATE_KEY= ROBINHOOD_RPC= ``` Then run the script: ```bash source .env forge script script/Deploy.s.sol --rpc-url robinhood --broadcast --verify ``` One run deploys and configures the complete set, in this sequence: 1. `PolicyController`, `AccessRegistry`, `AttestationStore`, `PriceGate`, `SliceToken`, `Treasury`, `LoanDesk`, `CollateralAuction`, `RolloverAuction`. 2. Parameters, while the controller is still in bootstrap mode: tiers A to C, the initial collateral tokens with their exposure caps, USDG as the loan token, terms of 7, 14, 30 and 90 days, the loan, auction, refinance and fee parameters, and the whitelist of idle-capital vaults. 3. Oracle feed configuration, together with the Chainlink Sequencer Uptime Feed. 4. `IdleVaultAdapter`, then `SliceToken.setDesk`, `IdleVaultAdapter.setDesk` and `LoanDesk.wire`. 5. `finishBootstrap()`, followed by the transfer of ownership to the governance multisig. | Variable | Meaning | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | `USDG`, `STOCK_TOKEN`, `STOCK_FEED`, `VAULT` | Live addresses of the settlement asset, the first collateral token, the Chainlink feed for that token, and the idle-capital vault | | `SEQUENCER_FEED` | The Chainlink L2 Sequencer Uptime Feed | | `MARKET_STATUS_SOURCE` | A contract that exposes `marketStatus()`, used to classify the trading session | | `STREAM_ADAPTER` | The Data Streams verifier adapter that auction pricing relies on | | `GOV`, `GUARDIAN` | The governance multisig and the pause guardian | | `TIMELOCK_DELAY` | In seconds. After bootstrap is finished it can never again be set below 3600. | | `ATTESTATION_ISSUER` | The KYC signer allowed to issue attestations | | `FINISH_BOOTSTRAP` | Set to `true` and the script's final step places `PolicyController` behind the timelock | When it finishes, the script records the addresses in `contracts/deployments/.json`. ## Local development On a local Anvil chain, leave the live addresses blank. The script then deploys mock tokens, a mock Chainlink aggregator and a mock ERC-4626 vault, and attests the deployer for every role. From there the full loan lifecycle can be run from the command line: 1. Mint mock USDG to a lender and mock Stock Tokens to a borrower, and approve `LoanDesk` from both. 2. Produce a `LendOffer` signature over EIP-712 typed data. The domain is `Farlight`, version `1`, the local chain id, and `LoanDesk` as the verifying contract. 3. As the borrower, call `originate(request, "", [offer], [signature])`. 4. Read `debtOf`, `healthFactor` and the slice token. 5. Move the mock feed with `MockAggregatorV3.set()` and call `CollateralAuction.startAuction`, or call `repay`. Mocks never form part of a production deployment. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.usefarlight.com/architecture/deployment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.