This kanban board shows our team’s progress across bug reports, feature requests and incident reports.

Backlog

Next up

In Progress

In Review

Done

Track Our Progress

Currently by my reading of the docs, i’m able to update a DIDDoc with VMs of type:<ul><li><code>Ed25519VerificationKey2020</code></li><li><code>EcdsaSecp256k1VerificationKey2019</code></li><li><code>RsaVerificationKey2018</code></li></ul>(source) <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://docs.cheqd.io/product/advanced/sdk/did-module#supported-key-types">https://docs.cheqd.io/product/advanced/sdk/did-module#supported-key-types</a> Although the source code seems to indicate:<ul><li><code>JsonWebKey2020</code> (key types ECDSA, Ed25519 &amp; RSA are seemingly supported)</li><li><code>Ed25519VerificationKey2020</code></li><li><code>Ed25519VerificationKey2018</code></li></ul>(source) <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/cheqd/cheqd-node/blob/2089162a071d1a741696a256457d656fa9457968/x/did/types/diddoc_verification_method.go#L17">https://github.com/cheqd/cheqd-node/blob/2089162a071d1a741696a256457d656fa9457968/x/did/types/diddoc_verification_method.go#L17</a>It would be nice if it was also possible to push <code>Multikey</code> VM types. Anecdotally, i’ve seen this VM grow in popularity over the years, as it is able to represent a huge range of key types with a single VM type, and is also compact. Similar properties to JsonWebKey2020, but arguably more compact and could be overtaking it in popularity.The support for the VM could be done in the same way as JsonWebKey2020 - limited scope to ed25519, ecdsa &amp; rsa key type support.Supporting multikey VMs in cheqd DID Docs may improve interoperability in systems which prefer Multikey to it’s alternatives (e.g. JsonWebKey2020)

Multikey VerificationMethod support

George Mulhearn

From Timo (Animo) Maybe we should update the cheqd anoncreds method to compress the status list (or anoncreds in general)? It's quite inefficient to put it as an array like this: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://resolver.cheqd.net/1.0/identifiers/did:cheqd:mainnet:fdd80fdc-8756-491d-838d-ccd705b2776a/resources/c95a79db-fb74-4b00-a114-faa8ac12d629">https://resolver.cheqd.net/1.0/identifiers/did:cheqd:mainnet:fdd80fdc-8756-491d-838d-ccd705b2776a/resources/c95a79db-fb74-4b00-a114-faa8ac12d629</a>

Credo

ACA-Py

Compress AnonCreds status lists

cheqd Product Team

UX/UI Issue: Low/ModeratePriority: Low/ModerateWe need to come up with a better way to identify which credentials are which in this list.If I need to delete one or more of 131072 indices how do I know what I am deleting?ExampleWhat if I am closing a department of 100 staff and moving them to a different department or something, how do I know who is who? We need to name the credentials, or be able to click them and have a modal, or some sort of search which will pull data from fields.<img data-width="100%" data-align="left" alt="" data-featurebase-content-key="67ff201042ee2fbfa416d563/post/6932eb9b01cff301a318544a/019aeee4-9908-7fae-97c7-35cb62ed2c08/b64u-aW1hZ2UucG5n.png" src="https://67ff201042ee2fbfa416d563.featurebase-attachments.com/c/post/6932eb9b01cff301a318544a/019aeee4-9908-7fae-97c7-35cb62ed2c08/b64u-aW1hZ2UucG5n.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260524T230000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260524%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=9889cbfb04d41cd88c78cee975cb9ad95983872dd85f3877becc27411ba63db9" data-featurebase-content-filename="image.png">

To Do / To Fix

cheqd Studio

Staging: Studio: Credential Identification - UX

Matthew Arnold

Revocation registries have limited size to a relatively small amount of entries. It would be fantastic to bump the size, and improve the efficiency of how these are stored and indexed on ledger

cheqd Network

Improve revocation registry size

I have been soft logged out twice while trying to review this page section, the second time while filling out my last ticket. Can we please check the session timer again?

Studio: Staging: Session timer

Please create documentation around how multiple resources can be batched together into a single transaction / block. Currently, there is no clear way to achieve this. A diagram showing the logic would be very helpful

Improve / Understand batching logic

Error creating DID Internal error: Error: Error: Broadcasting transaction failed with code 1 (codespace: undefined). Log: insufficient fee: need at least 213962289640, got 50000000000 Encountered this error during did creation in Cheqd Studio Dashboard.

Abnormal gas fee request

User

Hi, I get the following error while calling the “account/create” endpoint for getting a token so that my client can use the API endpoints of cheqd studio. Maybe the error: "Internal Error: Cannot read properties of undefined (reading 'kid')" is a bug? See the attached picture to replicate the error. Regards, Sid <img data-width="100%" data-align="left" data-featurebase-content-key="67ff201042ee2fbfa416d563/post/68ebdc7a64c0ad476a5c40a5/0199d955-167e-7dd1-9d93-67dfad8c33ae/b64u-U2NyZWVuc2hvdCAyMDI1LTEwLTEyIDE4NDgyOS5qcGc.jpeg" data-featurebase-content-filename="Screenshot 2025-10-12 184829.jpg" src="https://67ff201042ee2fbfa416d563.featurebase-attachments.com/c/post/68ebdc7a64c0ad476a5c40a5/0199d955-167e-7dd1-9d93-67dfad8c33ae/b64u-U2NyZWVuc2hvdCAyMDI1LTEwLTEyIDE4NDgyOS5qcGc.jpeg?X-Amz-Expires=3600&amp;X-Amz-Date=20260524T230000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260524%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=dba3f2c03f73d46f420c346a0d07f875b30507b323d234b0964eedaa481f6ba9">

Completed

account/create

sid030sid

<pre><code class="language-typescript">isDIDArray: (value: Validatable) =&gt; {
		const res = new DIDArrayValidator().validate((value as string[]).map((v) =&gt; (v.includes('#') ? v.split('#')[0] : v)));
		if (!res.valid) {
			throw new Error(res.error);
		}
		return true;
	},</code></pre>Am I write to consider this a fix for checking the authentication property for the update did api endpoint validator in Cheqd Studio? <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/cheqd/studio/blob/140dcea007da52f0fc4aea1eb6f2ca65aef0327c/src/controllers/api/did.ts#L131">https://github.com/cheqd/studio/blob/140dcea007da52f0fc4aea1eb6f2ca65aef0327c/src/controllers/api/did.ts#L131</a> I am attempting to update the authentication but its failing during validation unless I make the above change.

Cheqd Studio Update DID

Luke Nispel

Bug: SeverePriority: HighThis is too much of a major bug.Unfortunately, the result from verifying a suspended credential is returned as still being valid. This is extremely misleading.And in addition, a revoked credential in my list comes back as valid when I verify.Using the features of our own platform, revocation appears to not to be working.<img data-width="100%" data-align="left" alt="" data-featurebase-content-key="67ff201042ee2fbfa416d563/post/6932ef9707b23bceadb1cab6/019aeef7-14d9-77a0-92d9-e2a7257f698f/b64u-aW1hZ2UucG5n.png" src="https://67ff201042ee2fbfa416d563.featurebase-attachments.com/c/post/6932ef9707b23bceadb1cab6/019aeef7-14d9-77a0-92d9-e2a7257f698f/b64u-aW1hZ2UucG5n.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260524T230000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260524%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=c326ee98f709a2676d46d0fc71b316562446460ffca1fe20eaa562760a007e0c" data-featurebase-content-filename="image.png"><img data-width="100%" data-align="left" alt="" data-featurebase-content-key="67ff201042ee2fbfa416d563/post/6932ef9707b23bceadb1cab6/019aeef6-c6d6-7a7f-aef9-17c65ac88469/b64u-aW1hZ2UucG5n.png" src="https://67ff201042ee2fbfa416d563.featurebase-attachments.com/c/post/6932ef9707b23bceadb1cab6/019aeef6-c6d6-7a7f-aef9-17c65ac88469/b64u-aW1hZ2UucG5n.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260524T230000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260524%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=7f2c2109f4262ee5b3e6847ce6051903c633ff27a7a413e7dd281ee45e7ef7b5" data-featurebase-content-filename="image.png"><img data-width="100%" data-align="left" alt="" data-featurebase-content-key="67ff201042ee2fbfa416d563/post/6932ef9707b23bceadb1cab6/019aeef3-d962-74cf-b0e1-7fcb89cc42bd/b64u-aW1hZ2UucG5n.png" src="https://67ff201042ee2fbfa416d563.featurebase-attachments.com/c/post/6932ef9707b23bceadb1cab6/019aeef3-d962-74cf-b0e1-7fcb89cc42bd/b64u-aW1hZ2UucG5n.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260524T230000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260524%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=1a6ab0c7fd4667ddcc38008242ffab48770d513724b6e9875cd4c60a579c50a6" data-featurebase-content-filename="image.png"><img data-width="100%" data-align="left" alt="" data-featurebase-content-key="67ff201042ee2fbfa416d563/post/6932ef9707b23bceadb1cab6/019aeef4-61ab-7c2a-ba88-7cc8e1d77081/b64u-aW1hZ2UucG5n.png" src="https://67ff201042ee2fbfa416d563.featurebase-attachments.com/c/post/6932ef9707b23bceadb1cab6/019aeef4-61ab-7c2a-ba88-7cc8e1d77081/b64u-aW1hZ2UucG5n.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260524T230000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260524%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=bcca0d1a8ec71d608db2e170b670f9f142b929bd66896beb255675d06b966e4d" data-featurebase-content-filename="image.png">

Studio: Staging: Verification of Suspended Credential

1) Using Credo v0.5.14-0.5.17 create a cheqd did, with or without an existing DIDDoc. 2) Then immediately after successful creation, add a DIDCommV1 Service endpoint to the DIDDoc of the created did. 3) And then update the cheqd did with the newly updated DIDDoc.Step 3 should result in the following error:'unknownError: failed to execute message; message index: 0: there should be at least one valid signature by did:cheqd:testnet:52ae96fb-66cd-4945-9914-39b7ff638243 (old version): invalid signature detected'With the did referenced in the error message being the did that was created in step 1.

DID Registrar

Unable to update Cheqd did with DIDComm V1 Service endpoint on Credo

James Clark

From Glenn (CEO @ Affinidi)One of your engineers (<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/DaevMithran">https://github.com/DaevMithran</a>) submitted a PR to integrate Cheqd into our DID Resolver - thank you! Unfortunately we can’t push this to release because the Cheqd code is being sourced from the OWF git repo which hasn’t been published on <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://crates.io">crates.io</a> and <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://crates.io">crates.io</a> is failing it because it is pedantic on package names etc. I had a Quick Look at the OWF repo code <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/openwallet-foundation/vcx/tree/main/did_core/did_methods/did_cheqd">https://github.com/openwallet-foundation/vcx/tree/main/did_core/did_methods/did_cheqd</a> It is old, out of date and needs some love 😊 I am going to hold the Cheqd implementation as it is breaking our own CICD toolchain (and it is pulling in a rather large git repo). Do you have a preference on the following solutions: <ol><li>Pull the Cheqd DID implementation out of OWF and you publish a standalone Rust Library of the Cheqd resolver. Affinidi can then integrate with this cleanly</li><li>If you have dev documentation on the gRPC details of resolving Cheqd DID’s, I can whip up a did-cheqd native crate for you (similar to the other DID-methods in the eco-system).</li></ol>

Van Glenn (CEO bij Affinidi)Een van jullie engineers (<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/DaevMithran">https://github.com/DaevMithran</a>) heeft een PR ingediend om Cheqd te integreren in onze DID Resolver – bedankt! Helaas kunnen we dit niet naar de release pushen omdat de Cheqd-code afkomstig is uit de OWF-git-repo die nog niet is gepubliceerd op <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://crates.io">crates.io</a> en <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://crates.io">crates.io</a> keurt het af omdat het erg strikt is op het gebied van pakketnamen enz. Ik heb even snel gekeken naar de code in de OWF-repo <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/openwallet-foundation/vcx/tree/main/did_core/did_methods/did_cheqd">https://github.com/openwallet-foundation/vcx/tree/main/did_core/did_methods/did_cheqd</a> Die is oud, verouderd en kan wel wat liefde gebruiken 😊 Ik ga de Cheqd-implementatie even in de wacht zetten, omdat deze onze eigen CICD-toolchain verstoort (en het haalt een vrij grote git-repository binnen). Heb je een voorkeur voor de volgende oplossingen: <ol><li>Haal de Cheqd DID-implementatie uit OWF en publiceer een op zichzelf staande Rust-bibliotheek van de Cheqd-resolver. Affinidi kan hier dan netjes mee integreren</li><li>Als je dev-documentatie hebt over de gRPC-details van het oplossen van Cheqd DID's, kan ik een did-cheqd native crate voor je in elkaar zetten (vergelijkbaar met de andere DID-methoden in het ecosysteem).</li></ol>

Cheqd Rust Resolver - De implementatie op Crates.io mislukt

DID Resolver

Cheqd Rust Resolver - Crates.io deployment failing

Fraser Edwards

I wanted to reach out about an operational challenge we’re experiencing with <code>cheqd/did-resolver</code> and <code>cheqd/did-registrar</code> that a fallback mechanism could solve.The Problem: We’re running into issues with testnet accessibility. When your testnet nodes are behind the firewall (blocking p2p connections), our self-hosted node can’t join the network, which breaks our applications that are configured to use our local endpoints.Current Manual Workaround:<ol><li>Testnet nodes go behind firewall → our node can’t sync</li><li>We manually update deployments to point at official endpoints (<code>grpc.cheqd.network:443</code>, <code>https://rpc.cheqd.network</code>)</li><li>When firewall is removed → our node can rejoin the network</li><li>We manually update deployments back to our local endpoints</li></ol>This creates a lot of operational overhead and requires manual intervention every time network accessibility changes.Proposed Solution: Could you add automatic fallback functionality to both projects? Something like:<ul><li>did-resolver: Try our gRPC endpoint first, if connection fails (<code>5xx</code>, or <code>Connection Refused</code>) → automatically fall back to <code>grpc.cheqd.network:443</code></li><li>did-registrar: Try our RPC endpoint first, if connection fails (<code>5xx</code>, or <code>Connection Refused</code>) → automatically fall back to <code>https://rpc.cheqd.network</code></li></ul>The Flow We’re Envisioning:<ol><li>Try primary endpoint (our node)</li><li>On connection error → switch to official endpoints</li><li>When primary comes back online → switch back automatically</li></ol>This would eliminate the need for manual deployment updates every time testnet accessibility changes and make our infrastructure much more resilient to network-level issues.

Ik neem contact op in verband met een operationeel probleem dat we ondervinden met <code>cheqd/did-resolver</code> en <code>cheqd/did-registrar</code>, dat met een noodoplossing zou kunnen worden verholpen.Het probleem: we ondervinden problemen met de toegankelijkheid van het testnet. Wanneer uw testnet-knooppunten zich achter de firewall bevinden (waardoor p2p-verbindingen worden geblokkeerd), kan ons zelfgehoste knooppunt geen verbinding maken met het netwerk, waardoor onze applicaties die zijn geconfigureerd om onze lokale eindpunten te gebruiken, niet meer werken.Huidige handmatige oplossing:<ol><li>Testnet-knooppunten staan achter een firewall → onze node kan niet synchroniseren</li><li>We werken de implementaties handmatig bij zodat ze naar officiële eindpunten verwijzen (<code>grpc.cheqd.network:443</code>, <code>https://rpc.cheqd.network</code>)</li><li>Wanneer de firewall wordt verwijderd → kan onze node weer verbinding maken met het netwerk</li><li>We werken de implementaties handmatig bij naar onze lokale eindpunten</li></ol>Dit zorgt voor veel operationele overhead en vereist handmatige tussenkomst telkens wanneer de netwerktoegankelijkheid verandert.Voorgestelde oplossing: Kunt u automatische fallback-functionaliteit toevoegen aan beide projecten? Iets als:<ul><li>did-resolver: Probeer eerst ons gRPC-eindpunt; als de verbinding mislukt (<code>5xx</code> of <code>Connection Refused</code>) → schakel dan automatisch over naar <code>grpc.cheqd.network:443</code></li><li>did-registrar: Probeer eerst ons RPC-eindpunt, als de verbinding mislukt (<code>5xx</code> of <code>Connection Refused</code>) → schakel dan automatisch over naar <code>https://rpc.cheqd.network</code></li></ul>De flow die we voor ogen hebben:<ol><li>Probeer het primaire eindpunt (onze node)</li><li>Bij verbindingsfout → overschakelen naar officiële eindpunten</li><li>Wanneer het primaire eindpunt weer online is → schakel automatisch terug</li></ol>Dit zou de noodzaak van handmatige implementatie-updates telkens wanneer de toegankelijkheid van het testnet verandert, elimineren en onze infrastructuur veel veerkrachtiger maken tegen problemen op netwerkniveau.

Reserve-eindpunten voor DID-resolver / DID-registrar

Fallback Endpoints for DID Resolver / DID Registrar

I raised an issue here that may be related to my problem but mainly is just a noted missing dep in the @cheqd/studio code <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/cheqd/studio/issues/694">https://github.com/cheqd/studio/issues/694</a>

Missing validator Dep

An Anonymous User

Raised on behalf of Timo from AnimoOn the P256 signing in Credo (brought this up a long time ago). When i add an authentication using Askar as KMS it fails, but if I use Node crypto directly it succeeds. It's odd as we have been using our P256 signing with Askar with a lot of other implementation correctly, but it's probably something to do with encoding then I guess?Additional context:We are going to add P-256 signing in Paradym, and if cheqd can support it we will also enable this for Cheqd DIDs. It's not high priority, mainly wanted to share this behvaiour that it does work with another crypto implementation

P256 signing fails when using Askar as KMS

Opened on behalf of Timo / Animo Bug raised in GitHub:<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/cheqd/sdk/issues/436">https://github.com/cheqd/sdk/issues/436</a>DID Spec mentions:<blockquote>The value of the serviceEndpoint property MUST be a <a target="_blank" rel="nofollow" class="link" href="https://infra.spec.whatwg.org/#string">string</a>, a <a target="_blank" rel="nofollow" class="link" href="https://infra.spec.whatwg.org/#string">map</a>, or a <a target="_blank" rel="nofollow" class="link" href="https://infra.spec.whatwg.org/#ordered-set">set</a> composed of one or more <a target="_blank" rel="nofollow" class="link" href="https://infra.spec.whatwg.org/#string">strings</a> and/or <a target="_blank" rel="nofollow" class="link" href="https://infra.spec.whatwg.org/#string">maps</a>.</blockquote><h3 style="text-align: start">How can we reproduce this bug?</h3><ol><li>Update a did document, where there is a service having <code>serviceEndpoint</code> that is a string.</li></ol>(I think it also applies to creating a did doc).<h3 style="text-align: start">Environment</h3>Not applicable<h3 style="text-align: start">Bug prevalence</h3>No response<h3 style="text-align: start">Which browser/client application did you encounter the bug in? (if applicable)</h3>No response<h3 style="text-align: start">Relevant log output</h3>

SDK expects serviceEndpoint to be an Array of Strings

<pre><code>Transaction with ID 904E70D7044638A0A37103E32C00DB1031BD0198B08F25CEED7AA2B3F78AD061 was submitted but was not yet found on the chain. You might want to check later. There was a wait of 60 seconds </code></pre>We suddenly got this error when submitting a status list to cheqd mainnet for did <code>did:cheqd:mainnet:c3a49697-6282-4fda-a0d9-c81d2f76e9fe</code> and revocation registry definition <code>did:cheqd:mainnet:c3a49697-6282-4fda-a0d9-c81d2f76e9fe/resources/9ed8e025-2697-477c-a49a-3ec8da44de3e</code>

Unknown error writing to Cheqd mainnet

Internal error: You passed an empty string for 'flow_data[subscription_update_confirm][items][0][price]'. We assume empty values are an attempt to unset a parameter; however 'flow_data[subscription_update_confirm][items][0][price]' cannot be unset. You should remove 'flow_data[subscription_update_confirm][items][0][price]' from your request or supply a non-empty value.