> For the complete documentation index, see [llms.txt](https://docs.ethosis.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ethosis.org/architecture/deployment.md). # Build, test and deploy The contract code is a Foundry project under `contracts/` at the root of the Ethosis repository. ## Live addresses `contracts/deployments/4663.json` in the repository is the single authoritative record of the contracts deployed on Robinhood Chain (chain ID 4663). The platform loads the same addresses from the `deployment` row of its protocol parameters, and the explorer displays the `LoanDesk` address on its parameters panel. An address that does not appear in that file should not be trusted. The source of every deployment is verified on Blockscout. ## Building and running the tests ```bash cd contracts forge soldeer install # forge-std and OpenZeppelin into dependencies/, no git submodules forge build forge test -vv ``` There are 65 tests spread across five files, all of which build on the shared `Base.t.sol` fixture: | File | What it exercises | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Origination.t.sol` | A three-lender syndicate, the LTV ceiling, an ineligible borrower and an ineligible lender, APR mismatch, cancelled offers, standing offers reused across loans, the relayer path, the exposure cap, the guardian pause, fills drawn from idle capital | | `Repayment.t.sol` | Per-slice accrual checked against the documented worked example, the minimum interest period, full and partial repayment, top-ups, repayment during grace and while paused, repayment by a third party | | `CollateralAuction.t.sol` | Health factor tracking, a complete Dutch auction with proceeds distribution, partial buys, the liquidator role, default after grace, sequencer grace, oracle pause, the move cap, the closed-market haircut, splitting out opt-outs, in-kind settlement, the stream report requirement | | `Rollover.t.sol` | Opening rules, the linear rate, clearing with a new syndicate, failure and default, the rate ceiling, borrower cancellation, liquidation during a refinance | | `Policy.t.sol` | Bootstrap and the timelock, the guardian's scope, parameter validation, attestation expiry and revocation, removal of an issuer, the gated slice token transfer, fee withdrawal, one-shot wiring | ## Standing up a new environment Start from `.env.example`, copy it to `.env`, and fill in at least these two values: ``` PRIVATE_KEY= ROBINHOOD_RPC= ``` Then run the deploy script: ```bash source .env forge script script/Deploy.s.sol --rpc-url robinhood --broadcast --verify ``` A single run of the script deploys and configures the whole set, in this order: 1. `PolicyController`, `AccessRegistry`, `AttestationStore`, `PriceGate`, `SliceToken`, `Treasury`, `LoanDesk`, `CollateralAuction`, `RolloverAuction`. 2. Parameters, set while still in bootstrap mode: tiers A to C, the initial collateral tokens and 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, plus the Chainlink Sequencer Uptime Feed. 4. `IdleVaultAdapter`, followed by `SliceToken.setDesk`, `IdleVaultAdapter.setDesk` and `LoanDesk.wire`. 5. `finishBootstrap()`, then transfer of ownership to the governance multisig. | Variable | Meaning | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `USDG`, `STOCK_TOKEN`, `STOCK_FEED`, `VAULT` | Live addresses for the settlement asset, the first collateral token, that token's Chainlink feed, and the idle-capital vault | | `SEQUENCER_FEED` | The Chainlink L2 Sequencer Uptime Feed | | `MARKET_STATUS_SOURCE` | A contract exposing `marketStatus()`, used to classify the session | | `STREAM_ADAPTER` | The Data Streams verifier adapter used for auction pricing | | `GOV`, `GUARDIAN` | The governance multisig and the pause guardian | | `TIMELOCK_DELAY` | In seconds. Once bootstrap is finished it can no longer be set below 3600. | | `ATTESTATION_ISSUER` | The KYC signer permitted to issue attestations | | `FINISH_BOOTSTRAP` | Set to `true` to lock `PolicyController` behind the timelock as the script's final step | The script writes the resulting addresses to `contracts/deployments/.json`. ## Working locally Against a local Anvil chain, leaving the live addresses blank makes the script deploy mock tokens, a mock Chainlink aggregator and a mock ERC-4626 vault, and it attests the deployer for every role. The whole loan lifecycle can then be driven from the command line: 1. Mint mock USDG to a lender and mock Stock Tokens to a borrower, and have both approve `LoanDesk`. 2. Sign a `LendOffer` as EIP-712 typed data (domain `Ethosis` / `1` / the local chain id, with `LoanDesk` as the verifying contract). 3. From the borrower, call `originate(request, "", [offer], [signature])`. 4. Inspect `debtOf`, `healthFactor` and the slice token. 5. Push the mock feed with `MockAggregatorV3.set()` and call `CollateralAuction.startAuction`, or call `repay`. No mock ever forms 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.ethosis.org/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.