# Compliance & Permissioning

#### Overview

The Trade Float Vault is designed to support **institutional participation** while preserving the transparency and programmability of on-chain infrastructure.

Access is **permissioned at the user level**, while the underlying vault logic, accounting, and settlement activity remain **open and verifiable on-chain**.

This approach enables compliant participation without relying on opaque, off-chain capital management.

#### Permissioned User Access

Interaction with the Trade Float Vault is restricted to approved participants.

Permissioning is applied at the wallet level and governs who may:

* deposit capital
* redeem receipt tokens
* initiate or approve settlement activity
* operate treasury controls (where applicable)

Permissioning ensures that only users who meet eligibility and compliance requirements can interact with the vault.

#### KYC and Onboarding

All users are required to complete applicable onboarding and compliance checks prior to accessing the vault.

This may include:

* identity and entity verification
* beneficial ownership disclosure
* sanctions and screening checks
* acceptance of applicable terms

Once approved, users onboard designated wallets that are authorised to interact with the vault.

#### Jurisdiction-Aware Controls

Participation in the Trade Float Vault may be subject to jurisdictional restrictions.

The system is designed to support:

* jurisdiction-aware access controls
* routing constraints based on regulatory requirements
* differentiated participation rules where required

These controls help ensure that vault participation aligns with applicable regulatory frameworks across different regions.

#### Approved Wallets and Destinations

Interactions with the vault are limited to approved wallets and destinations.

This includes:

* whitelisting of deposit and redemption wallets
* whitelisting of settlement counterparties
* enforcement of destination controls for outbound payments

These measures reduce operational risk and support compliance and audit requirements.

#### Legal and Structural Considerations

Where required, participation in the Trade Float Vault may be supported by segregated legal wrappers or contractual arrangements.

These structures are designed to:

* support bankruptcy remoteness
* segregate assets from operating entities
* align on-chain activity with off-chain legal frameworks

The specific structure may vary depending on user type, jurisdiction, and regulatory context.

#### Transparency and Auditability

While user access is permissioned, the Trade Float Vault operates with on-chain transparency.

Vault balances, receipt token supply, and deployment activity are visible and verifiable on-chain, enabling:

* independent monitoring by capital providers
* internal audit and reconciliation
* alignment between on-chain records and off-chain reporting

Permissioning does not reduce transparency into how the vault operates.

#### Relationship to DeFi Integrations

The Trade Float Vault is designed to be **open at the protocol level**.

While user access is permissioned, the underlying architecture supports:

* programmatic integration
* composability with other on-chain systems
* transparent interaction patterns

This allows the vault to interface with DeFi-native infrastructure without compromising compliance or control.

#### Compliance Philosophy

The compliance model of the Trade Float Vault is intentionally pragmatic.

Rather than attempting to fully decentralise compliance responsibilities, the system:

* applies controls where legally required
* preserves programmability and transparency
* maintains clear accountability for capital handling

This approach reflects the realities of deploying stablecoin capital into regulated, real-world trade activity.


---

# Agent Instructions: 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:

```
GET https://agridex-2.gitbook.io/agridex-docs/risk-and-compliance/compliance-and-permissioning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
