v2.31.0

Release date: November 20, 2025

New features

Added Alias Directory layouts

Two layouts have been added related to Alias Directory and those are Alias Directory Setup and Alias Directory Participant Domain. These two layouts enable users to set up a ledger as an alias directory and onboard a new alias directory participant.

Controlling how proofs are selected for status quorum evaluation

We added support for controlling how the proofs of a record are selected when evaluating the quorum for a status transition. This is done through quorum.proofSelection property in the config of status policies:

  {
    "handle": "my-status-policy",
    "schema": "status",
    "config": {
      "quorum.proofSelection": "latest-chain" | "entire-set"
    },
    "values": [...]
  }

When quorum.proofSelection is latest-chain (default): Only the most recent consecutive proofs from the end of the chain with matching status are eligible for quorum checks. If a proof with a different status is encountered, previous proofs are ignored. This enforces strict sequential ordering. When quorum.proofSelection is entire-set: All proofs for the target status, regardless of their order or position in the chain, are eligible for quorum checks. This mode relaxes proof ordering and allows for more flexible status transitions. This gives fine-grained control to policy authors over how strictly the record status change proofs must be ordered when determining if a quorum has been met. Check out About Status Policies for further details and examples.

Improvements

Unified filters for studio application

Now filters for custom data (When available) and filters for root data of the records are shown in the same component. This removes visual noise from unused filters and allows a better visualization of filtering combinations.

Handling errors from bridges when forwarding anchor calls

When forwarding anchor operations to a bridge, the ledger now provides more robust error handling:

• Structured bridge errors: When a bridge returns a well-formed error response (with data, hash, and meta fields), the ledger validates the hash and proofs before relaying the error to the client. This ensures error responses from bridges are cryptographically verified.
• Invalid bridge responses: If a bridge returns a malformed response or fails proof validation, the ledger returns a forward.invalid-response error (502 status) to indicate the bridge response was unverifiable.
• Authentication failures: Bridge authentication errors (401/403) are now treated as internal failures and return a forward.unexpected-error (500 status) rather than exposing bridge authentication details to clients.
• Consistent error propagation: All bridge errors are properly structured and include appropriate status codes, making it easier to diagnose issues when working with external alias directories or bridge systems.

This improvement ensures that anchor forwarding maintains the same security and integrity guarantees as local operations, even when delegating to external systems. Check out Responses and Errors for more details.

Fixes

Studio

Fixed issue with users getting 403/500 errors, due to CSRF token validation not working correctly in cases where user has multiple tabs open.

Fixed multiple clicks in submit button causing issues during login.

Ledger-SDK

• Proof verification is now skipped when response code is 204 (no content) and response body is empty. This fixes issues when verifying proofs in drops, since ledger does not sign the payload in these requests.

CLI

• Added --output json option for list commands. For example: minka wallet list --output json or minka intent list -o json. This option will only output a json array of records which can be used for bash scripting commands.