> For the complete documentation index, see [llms.txt](https://docs.metalex.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.metalex.tech/building-on-the-protocol/how-to/gate-with-conditions.md).

# Gate state transitions with conditions

Attach condition contracts to scripification, rounds, deals and secondary settlement, and write a custom condition

A condition is a contract implementing `ICondition`. Attaching conditions lets a company require any onchain check before scrip is minted or redeemed, an investor joins a round, a deal proceeds or a secondary trade settles.

```solidity
interface ICondition {
    function checkCondition(
        address _contract,
        bytes4 _functionSignature,
        bytes memory data
    ) external view returns (bool);
}
```

[Conditions](/building-on-the-protocol/reference/conditions.md) documents the built-in conditions (`lexchexCondition`, `NonUSNationalityCondition`, `IssuerApprovalRecertificationCondition`, `OrCondition`). The secondary-trading conditions live in [`src/libs/conditions/secondary/`](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/src/libs/conditions/secondary/README.md) and cover eligibility, holding periods, holder caps, Reg S distribution compliance, Rule 144 and Section 4(a)(7) disclosure, CFIUS, a kill switch and more.

## Attach conditions where the protocol accepts them

Pass conditions as an `address[]` (or `ICondition[]`) to the call that creates the gated thing. Secondary trades are the exception: the DealManager keeps their conditions as standing lists.

### Scripification and de-scripification

Set both lists when you deploy the scrip:

```solidity
IIssuanceManager(issuanceManager).deployCyberScrip(
    certAddress,
    typeRestrictionHooks,
    certToScripConditions,   // ICondition[] gating scripifyCert
    scripToCertConditions,   // ICondition[] gating convertScripToCert
    /* ...remaining args... */
);
```

### Fundraising rounds

Round-wide conditions go in the `Round` built with `RoundLib.setAgreement` (`roundConditions`). Per-EOI conditions go in `submitEOI(..., conditions, ...)`.

### Deals

Pass them as the `conditions` argument of `DealManager.proposeDeal`.

### Secondary trades

The company sets these lists once on the DealManager, and the DealManager evaluates them at post, accept and finalize:

```solidity
// exemption-pathway conditions (also enables/disables the pathway)
dealManager.setPathwayThresholdConditions(pathway, conditions, enabled);
// fund-specific conditions applying to every offer
dealManager.setSpvThresholdConditions(conditions);
// conditions evaluated only at finalization
dealManager.setClosingConditions(conditions);
```

These lists accept only contracts implementing the typed `ISecondaryTradingCondition`, and the setters check for it through ERC-165. [Run a secondary trade](/building-on-the-protocol/how-to/run-a-secondary-trade.md) shows the lists in use.

## Write a custom condition

`checkCondition` receives the calling contract, the function selector and arbitrary `data`, so a condition can encode any onchain check:

```solidity
contract MinBalanceCondition is ICondition {
    IERC20  immutable token;
    uint256 immutable minimum;
    constructor(IERC20 t, uint256 m) { token = t; minimum = m; }

    function checkCondition(address, bytes4, bytes memory data)
        external view returns (bool)
    {
        address subject = abi.decode(data, (address));
        return token.balanceOf(subject) >= minimum;
    }
}
```

Deploy it and pass its address in any `ICondition` list on this page.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.metalex.tech/building-on-the-protocol/how-to/gate-with-conditions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.