Status
What works today
Every capability, its status, where it lives and what it needs. Derived from one manifest — this page, the documentation badges and the product pages cannot disagree.
26 AVAILABLE
Usable today, through the interface named here.
11 READ ONLY
You can see it. Changing it happens somewhere else.
1 PLANNED
Decided and specified. Not built.
4 NOT AVAILABLE
Deliberately absent. The reasoning is written down.
Access
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Sign in and pick a project Needs: A provisioned organization and a console user. | AVAILABLE | Sign in → Projects | POST /v1/console/login · GET /v1/console/projects | — | Docs |
| Apply for an organization account An application is recorded, not granted. An operator reviews and provisions it. | AVAILABLE | Sign in → Apply for one | POST /v1/console/register | — | Docs |
| Grant a role to a person | AVAILABLE | Security → Members | GET/POST .../members · .../members/:id/roles | ADMIN | Docs |
| Read separation-of-duties settings Changing them from a browser form deserves its own ceremony, and there is no route for one. | READ ONLY | Security | GET /v1/console/projects/:id/settings | ADMIN, AUDITOR | Docs |
Agents
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Freeze and release an agent Needs: A registered agent. Release is ADMIN only. | AVAILABLE | Agents → an agent | POST /v1/console/projects/:id/agents/freeze · /release | ADMIN, APPROVER | Docs |
| Register a new agent Needs: A did:key created outside Bengar, with `bengar id create`. | AVAILABLE | Agents → Register an agent | POST /v1/console/projects/:id/agents | ADMIN | Docs |
| See the agents in a project Listing and reading are all this screen does. Registering an agent has no endpoint anywhere in the product. Needs: At least one registered agent. | READ ONLY | Agents | GET /v1/console/projects/:id/agents | ADMIN, APPROVER, AUDITOR, POLICY_AUTHOR | Docs |
| Let an agent spend the organization's on-chain funds Deliberately outside v1, and not a missing feature. An agent may request an action and a permit may bound what it requests; a permit does not grant access to an organization's chain signing key, and there is no route — direct, indirect or automatic — from one to the other. A permit that could sign would be a bearer instrument for whatever the key can do. Whether an agent should ever move on-chain funds is a separate decision with its own threat model. | NOT AVAILABLE | — | — | — | Docs |
Permits
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Issue a permit Not from the Console, on purpose: there is no issuer-key custody workflow, and a button there would be inventing an authority rather than exposing one. Needs: An issuer identity. | AVAILABLE | The CLI: `bengar permit issue` | — | — | Docs |
| Register an issued permit Needs: A verifiable permit artifact. | AVAILABLE | Permits → Verify and register | POST /v1/console/projects/:id/permits | PERMIT_ISSUER | Docs |
| See the permit registry An inventory. Issuing happens in the CLI and registering needs PERMIT_ISSUER. | READ ONLY | Permits | GET /v1/console/projects/:id/permits | ADMIN, PERMIT_ISSUER, AUDITOR | Docs |
Policy
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Publish a policy version Needs: POLICY_AUTHOR, which an administrator can now grant. | AVAILABLE | Policies → Author a policy | PUT /v1/console/projects/:id/policy | POLICY_AUTHOR | Docs |
| Simulate a decision against the policy Needs: An active policy version and at least one registered agent. | AVAILABLE | Policies → Simulate | POST /v1/console/projects/:id/policy/simulate | ADMIN, POLICY_AUTHOR, AUDITOR | Docs |
| Activate a policy version Needs: An inactive version to activate. | AVAILABLE | Policies → Activate | POST /v1/console/projects/:id/policy/activate | POLICY_AUTHOR | Docs |
| Read the active policy and its versions Reading the active version and the history. Publishing and activating are POLICY_AUTHOR. | READ ONLY | Policies | GET /v1/console/projects/:id/policy · /policy/versions | ADMIN, POLICY_AUTHOR, AUDITOR, APPROVER | Docs |
Approvals
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Approve or reject, with a passkey Needs: APPROVER, an enrolled passkey, and a provisioned Custody approval key — all three now have a screen. | AVAILABLE | Approvals → an approval → Review and approve | POST .../approvals/:id/challenge · .../challenges/:id/complete | APPROVER | Docs |
| See the approval queue Reading the queue and one approval. Deciding is APPROVER. | READ ONLY | Approvals | GET /v1/console/projects/:id/approvals | ADMIN, APPROVER, AUDITOR | Docs |
Credentials
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Enrol a passkey Needs: A signed-in session. | AVAILABLE | Security → Your passkeys → Register a passkey | POST /v1/console/webauthn/registration/options · /registration | — | Docs |
| See and disable your passkeys Needs: An enrolled passkey. | AVAILABLE | Security → Your passkeys | GET /v1/console/webauthn/credentials | — | Docs |
| Provision or retire a Custody approval key Needs: A principal holding APPROVER. | AVAILABLE | Security → Approval signing | POST .../principals/:id/approval-keys · .../approval-keys/:id/retire | ADMIN | Docs |
| Create, list and revoke API keys | AVAILABLE | API Keys | GET/POST /v1/console/projects/:id/api-keys · .../:id/revoke | ADMIN | Docs |
Execution
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Reconcile an UNKNOWN execution Needs: An execution whose outcome is UNKNOWN. | AVAILABLE | Executions → Reconcile | POST /v1/console/projects/:id/executions/:id/resolve | ADMIN | Docs |
| Authorize an agent action Needs: An API key, an agent, a permit and an active policy. | AVAILABLE | The API: POST /v1/authorize | POST /v1/authorize | — | Docs |
| See executions and filter by status Listing and filtering. Only an execution needing reconciliation offers an action, and only to ADMIN. | READ ONLY | Executions | GET /v1/console/projects/:id/executions | ADMIN, AUDITOR, APPROVER | Docs |
Audit
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Read the audit trail | AVAILABLE | Audit | GET /v1/console/projects/:id/audit · /control-plane | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR | Docs |
| Verify an audit event against its anchor Needs: An anchored audit event. | AVAILABLE | Proofs | POST /v1/console/projects/:id/proofs/verify | ADMIN, AUDITOR | Docs |
Assets
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| Browse assets, holders and transfers | AVAILABLE | Scan → Assets | GET /v1/assets (Indexer) | — | Docs |
| Provision the organization's chain signing key | AVAILABLE | Console → Assets | POST /v1/console/projects/{projectId}/chain-key | ADMIN | Docs |
| Issue an asset from the Console Needs: An organization signing key, provisioned on the Assets page, and a funded chain account to pay the fee. | AVAILABLE | Console → Assets → Create an asset | POST /v1/console/projects/{projectId}/asset-intents | ADMIN | Docs |
| Mint, burn and transfer from the Console Needs: The same signing key. A FIXED asset has no mint at all. | AVAILABLE | Console → Assets → an asset | POST /v1/console/projects/{projectId}/asset-intents | ADMIN | Docs |
| See the organization's treasury address and balance Needs: An organization signing key, provisioned on the Assets page. | AVAILABLE | Console → Assets → Treasury | GET /v1/console/projects/{projectId}/treasury | ADMIN, AUDITOR | Docs |
| Send from the organization's treasury Needs: A signing key, a funded account, and a policy that allows the transfer. Holding the key is not permission. | AVAILABLE | Console → Assets → Treasury → Review transfer | POST /v1/console/projects/{projectId}/treasury/intents | ADMIN | Docs |
| See whether an asset is Trust gated The Console shows the gating organization, the policy version and how many keys may authorize a movement. It does not issue authorizations: one is issued per movement by the organization that opened the gate, so moving a gated asset from the Console is refused by the chain. | READ ONLY | Console → Assets → an asset | GET /v1/assets/{id}/gating (Indexer) | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR | Docs |
| Freeze or blacklist a holder Not part of the v1 protocol model. `x/assets` has no freeze, account freeze, blacklist, clawback, seizure or forced transfer, and no message that could express one. Freeze carries legal and policy consequences that outlive the code, so it would need its own decision gate and its own threat model rather than arriving as a setting. | NOT AVAILABLE | — | — | — | Docs |
| Administer somebody else's asset Not part of the v1 protocol model. There is no generic administrator and no owner-of-everything: creating an asset confers no standing authority, mint authority is scoped to one asset, and burning is something a holder does to its own balance. A burn authority over another account would be seizure under another name. | NOT AVAILABLE | — | — | — | Docs |
| Transfer or rotate an asset's mint authority Not part of the v1 protocol model. Mint authority is fixed at creation and there is no message that rotates, delegates or replaces it — which is what makes it readable: whoever holds it held it from the beginning. Metadata is immutable for the same reason. | NOT AVAILABLE | — | — | — | Docs |
Network
| Capability | Status | Where | API | Role | Docs |
|---|---|---|---|---|---|
| See the network's status and how fresh the read model is | AVAILABLE | Console → Network → Overview | GET /v1/console/projects/{projectId}/network | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR, PERMIT_ISSUER | Docs |
| Browse validators and their delegations Reading only. Moniker and commission are not shown because the read model does not hold them — both live in a message body and in no event. | READ ONLY | Console → Network → Validators | GET /v1/console/projects/{projectId}/network/validators | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR, PERMIT_ISSUER | Docs |
| See staking as the read model records it Reading only, and there is no total: a slash moves tokens without moving shares, so a sum of delegations is not a sum of stake and the Console does not present one. | READ ONLY | Console → Network → Staking | GET /v1/console/projects/{projectId}/network/staking | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR, PERMIT_ISSUER | Docs |
| Read proposals and both authorities Reading only. Voting as an organization is a chain transaction signed by an organization's key, and there is no control for it here. | READ ONLY | Console → Network → Governance | GET /v1/console/projects/{projectId}/network/governance | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR, PERMIT_ISSUER | Docs |
| Read the network treasury's payments The **network's** community pool, not an organization's treasury. Its funding is deliberately inactive and spending needs a passed proposal and an N-of-M consent together, neither of which happens here. | READ ONLY | Console → Network → Treasury | GET /v1/console/projects/{projectId}/network/treasury | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR, PERMIT_ISSUER | Docs |
| Operate a validator, delegate, or vote Blocked by network milestones rather than by the Console. A validator operation is undefined as a product before node productization, and admission rules are a separate decision — so there is no screen, and offering one first would be an interface inventing an authority. | PLANNED | — | — | — | Docs |
Why some things are built and still not usable
Bengar separates duties deliberately: an administrator cannot approve, author policy or register a permit. That is right. What is not right yet is that no screen grants those roles — so a newly provisioned organization has one ADMIN and no way to create an approver.
Rather than describe those capabilities as available, they are marked BACKEND ONLY with the blocker named. That is the honest reading, and it is what somebody planning around Bengar needs.