> For the complete documentation index, see [llms.txt](https://pool-party-xyz.gitbook.io/pool-party-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pool-party-xyz.gitbook.io/pool-party-docs/pool-party-v2-docs/core-concepts/deposits-and-self-custody.md).

# Deposits & Self-custody

#### Deposits & Self-custody

Self-custody, here, means your claim on a pool is bound to your wallet and enforced by the protocol.

#### **How a deposit works**

When you deposit into a pool, the pool's contract records your share, tied to your wallet. You do not receive a share token, and there is nothing to hold or transfer. Your position lives on-chain inside the contract, and only your wallet can access or withdraw it. When you exit, your shares are redeemed for the matching slice of the pool's holdings, according to the pool's terms.

#### **Why it is self-custodial**

Because your claim is bound to your keys, no manager or intermediary can move it, seize it, or block it arbitrarily. The contract, not a company, decides what happens, and it follows the pool's mandate.

#### **What self-custody protects, and what it does not**

Self-custody protects control: no one can take your position out from under you. It does not remove market risk or strategy risk. The value of your share rises and falls with the pool's holdings. It also does not remove smart-contract risk.

{% hint style="info" %}
Self-custody is about control, not about a guaranteed outcome. You keep control of your position; the outcome depends on the strategy and the market.
{% endhint %}

***

***

***

Every member of a workspace has a role. The role determines what actions they can perform across the workspace and its projects.

## Roles overview

There are five roles, ordered from least to most privileged:

| Role         | Best for                                                        |
| ------------ | --------------------------------------------------------------- |
| **Guest**    | External stakeholders who only need to see published deploys    |
| **Viewer**   | Internal users who need read-only access to drafts and settings |
| **Editor**   | Builders who actively work on projects                          |
| **Reviewer** | People who comment and approve, but don't push changes          |
| **Admin**    | Workspace owners and team leads                                 |

{% hint style="info" %}
Guests don't count towards your member limit, making them ideal for read-only stakeholders.
{% endhint %}

## Permission matrix

The full breakdown of what each role can do:

| Action                       | Guest | Viewer | Reviewer | Editor | Admin |
| ---------------------------- | :---: | :----: | :------: | :----: | :---: |
| View published deploys       |   ✓   |    ✓   |     ✓    |    ✓   |   ✓   |
| View drafts                  |   —   |    ✓   |     ✓    |    ✓   |   ✓   |
| Comment on deploys           |   —   |    —   |     ✓    |    ✓   |   ✓   |
| Trigger builds               |   —   |    —   |     —    |    ✓   |   ✓   |
| Edit project settings        |   —   |    —   |     —    |    ✓   |   ✓   |
| Manage environment variables |   —   |    —   |     —    |    ✓   |   ✓   |
| Invite members               |   —   |    —   |     —    |    —   |   ✓   |
| Change roles                 |   —   |    —   |     —    |    —   |   ✓   |
| Manage billing               |   —   |    —   |     —    |    —   |   ✓   |
| Delete projects              |   —   |    —   |     —    |    —   |   ✓   |

## How permissions flow

Roles are assigned at the **workspace level** and apply to every project in that workspace. There's no per-project override.

If you need finer-grained access — for example, contractors who should only see one project — create a separate workspace for that work and invite them there.

{% hint style="warning" %}
Per-project roles are a frequently requested feature and are on our [roadmap](https://example.com/roadmap). For now, the workspace boundary is the boundary of access.
{% endhint %}

## Changing someone's role

Workspace admins can change any member's role at any time:

1. Go to **Workspace settings → Members**
2. Find the member and click the role dropdown next to their name
3. Select the new role and confirm

The change takes effect immediately — the member doesn't need to re-authenticate.

## Removing a member

Removing a member revokes their access immediately. Any content they created stays in the workspace.

{% hint style="danger" %}
If you're using SSO, removing a member from your identity provider does **not** automatically remove them from the workspace unless SCIM provisioning is enabled.
{% endhint %}


---

# 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://pool-party-xyz.gitbook.io/pool-party-docs/pool-party-v2-docs/core-concepts/deposits-and-self-custody.md?ask=<question>&goal=<endgoal>
```

`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.