> For the complete documentation index, see [llms.txt](https://docs.ibis.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ibis.app/reference/security-and-audits.md).

# Security and disclosure

Ibis uses role permissions, a Timelock and pause controls to govern changes to the platform and its facilities. Ibis also accepts reports of suspected vulnerabilities in the platform or its apps.

## Timelock delay and execution

The Timelock makes a scheduled governance action wait before it can execute.

The Proposer schedules the exact actions and their earliest execution time becomes visible onchain. The chosen delay must be at least the minimum then in force. Once that delay has elapsed, the appointed Executor can execute the same actions, provided any specified prerequisite action has completed and the affected facility or component accepts them. Elapsed time alone does not execute an action.

The Canceller can stop an action while it is waiting or ready to execute, without waiting through another Timelock delay. A cancelled action must be scheduled again and wait through a new delay before execution. Cancellation cannot undo a completed action, and a ready action has no automatic expiry.

A failed execution leaves the action uncompleted and available for another attempt if it remains scheduled. When actions are grouped into one transaction, failure of any action leaves the whole group unapplied.

Changes to the minimum delay must themselves pass through the Timelock using the existing delay. They affect future scheduling, not the execution time of actions already scheduled.

[Roles and responsibilities](/platform/roles-and-permissions.md#timelock-and-governance-roles) defines the Proposer, Executor and Canceller and the actions controlled by the Timelock.

## Pauses, freezes and resumption

The Admin or Guardian can pause facility activity, freeze accrual or hold principal delivery immediately. The Platform Guardian can pause platform activity or suspend the approved-address registry authority immediately. Clearing these controls requires a delayed Timelock action.

A platform pause blocks new deposits, new withdrawal requests, withdrawal execution, Epochs settlement, share transfers and sales, and conversion of unpaid withdrawals into shares after default. Facility pauses can restrict individual activities. Existing claimable balances remain claimable, and repayment, pending-deposit refunds and recovery claims remain available under their state, settlement and eligibility requirements. A pause does not turn an unfunded withdrawal into a claimable balance.

An ordinary activity pause does not stop yield accrual. An accrual freeze stops it without later catch-up for the frozen time. A principal-delivery hold keeps undelivered principal in the facility; clearing the hold and releasing withheld principal are separate Timelock-controlled actions.

An address freeze is a separate compliance control. The Admin can set or clear it immediately, and the Timelock can also clear it after a delay. Clearing it does not grant wallet approval or release value already held in the compliance escrow; an escrow release requires its own delayed action and re-screening.

## Upgrades and authority limits

The Timelock controls upgrades to the platform's stable component addresses, including facilities and the shared services. The Admin, Guardian and Executor have no independent upgrade power through those roles; an upgrade must be scheduled and executed through the Timelock.

The waiting period exposes proposed changes before execution and gives the Canceller time to stop them. It does not establish that a change is correct or require a lender vote. An upgrade can change platform behavior, and changes to governance permissions or the delay can change the control model itself. Loss or nonparticipation of the required role holders can leave delayed actions unavailable, including resumption after a pause.

The Admin retains immediate economic powers: share seizure can cancel a lender's shares or move them into the compliance escrow, and a Continuous facility's principal-delivery split can redirect future deliveries. These actions have their own bounds and state requirements; they do not all pass through the Timelock. Participants therefore rely on the conduct of both the Admin and delayed governance.

Claims pay only funded balances. Restricted payouts stay attributed to their beneficiary in the compliance escrow, and release requires delayed authorization and screening again. The [liquidity accounting rules](/platform/liquidity-accounting.md) describe the cash reserved for obligations; role separation and a waiting period do not supply missing cash or prevent borrower losses.

## Audits

The Ibis smart contracts have been audited by Spearbit and Certora.

| Firm     | Critical findings | High findings | Medium findings |
| -------- | ----------------- | ------------- | --------------- |
| Spearbit | 0                 | 0             | 0               |
| Certora  | 0                 | 0             | 0               |

## Responsible disclosure

Report a suspected vulnerability in Ibis or its apps to <security@ibis.financial> and send support questions through [Support and integration](/reference/integrating-with-ibis.md).

### Report contents

Provide enough information to reproduce the issue and understand its impact.

* Name the affected host or network.
* For an affected onchain component, use its name from [Networks and addresses](/reference/deployed-contracts-and-addresses.md).
* Give the steps that reproduce the issue.
* State the impact: what the issue allows and which participants or funds it affects.

### Testing and publication

Ibis asks researchers not to test against live facilities or other people's accounts and wallets, and not to disclose a report publicly before Ibis and the researcher agree on a disclosure timeline.