authVault documents fail to deserialize after backward-compatible authVaultAccess contract update

[PastaPastaPasta]

Summary

After submitting a backward-compatible DataContractUpdate for Yappr auth vault contract 64RTgHjGXhtiN9t5S4u6hVDps7oHuTBaaHrQEFYcxt9M, reads of authVault documents started failing with:

protocol: Corrupted Serialization: error reading string from serialized document

The update was accepted by Platform and the contract now reports version 2.

Expected

A contract update that only changes authVaultAccess should not break reads of existing authVault documents, especially because the authVault schema itself is unchanged.

Actual

After the update:

• authVaultAccess queries still work
• authVault queries fail
• direct getDocument / sdk.documents.get(...) for an existing authVault also fails

This reproduces outside the app in a standalone Node script using @dashevo/evo-sdk@3.1.0-dev.1, so it does not appear to be an application-layer bug.

Contract

Contract ID:

64RTgHjGXhtiN9t5S4u6hVDps7oHuTBaaHrQEFYcxt9M

Contract version after update:

2

Schema delta

Only authVaultAccess changed. authVault did not.

Pre-update (v1)

{
  "authVault": {
    "properties": {
      "version": { "type": "integer", "position": 0 },
      "secretKind": { "type": "string", "enum": ["login-key", "auth-key"], "position": 1 },
      "ciphertext": { "type": "array", "byteArray": true, "position": 2 },
      "iv": { "type": "array", "byteArray": true, "position": 3 },
      "bundleHash": { "type": "array", "byteArray": true, "position": 4 },
      "updatedAt": { "type": "integer", "position": 5 },
      "active": { "type": "boolean", "position": 6 }
    }
  },
  "authVaultAccess": {
    "properties": {
      "vaultId": { "type": "array", "byteArray": true, "position": 0 },
      "kind": { "type": "string", "enum": ["password", "passkey-prf"], "position": 1 },
      "label": { "type": "string", "position": 2 },
      "status": { "type": "string", "enum": ["active", "revoked"], "position": 3 },
      "wrappedDek": { "type": "array", "byteArray": true, "position": 4 },
      "iv": { "type": "array", "byteArray": true, "position": 5 },
      "kdfType": { "type": "string", "position": 6 },
      "pbkdf2Salt": { "type": "array", "byteArray": true, "position": 7 },
      "pbkdf2Iterations": { "type": "integer", "position": 8 },
      "credentialId": { "type": "array", "byteArray": true, "position": 9 },
      "credentialIdHash": { "type": "array", "byteArray": true, "position": 10 },
      "prfInput": { "type": "array", "byteArray": true, "position": 11 },
      "rpId": { "type": "string", "position": 12 }
    }
  }
}

Post-update (v2)

{
  "authVault": {
    "properties": {
      "version": { "type": "integer", "position": 0 },
      "secretKind": { "type": "string", "enum": ["login-key", "auth-key"], "position": 1 },
      "ciphertext": { "type": "array", "byteArray": true, "position": 2 },
      "iv": { "type": "array", "byteArray": true, "position": 3 },
      "bundleHash": { "type": "array", "byteArray": true, "position": 4 },
      "updatedAt": { "type": "integer", "position": 5 },
      "active": { "type": "boolean", "position": 6 }
    }
  },
  "authVaultAccess": {
    "properties": {
      "vaultId": { "type": "array", "byteArray": true, "position": 0 },
      "kind": { "type": "string", "enum": ["password", "passkey-prf", "auth-key"], "position": 1 },
      "label": { "type": "string", "position": 2 },
      "status": { "type": "string", "enum": ["active", "revoked"], "position": 3 },
      "wrappedDek": { "type": "array", "byteArray": true, "position": 4 },
      "iv": { "type": "array", "byteArray": true, "position": 5 },
      "kdfType": { "type": "string", "position": 6 },
      "pbkdf2Salt": { "type": "array", "byteArray": true, "position": 7 },
      "pbkdf2Iterations": { "type": "integer", "position": 8 },
      "credentialId": { "type": "array", "byteArray": true, "position": 9 },
      "credentialIdHash": { "type": "array", "byteArray": true, "position": 10 },
      "prfInput": { "type": "array", "byteArray": true, "position": 11 },
      "rpId": { "type": "string", "position": 12 },
      "authKeyId": { "type": "integer", "minimum": 0, "maximum": 4294967295, "position": 13 }
    }
  }
}

Minimal repro

Using @dashevo/evo-sdk@3.1.0-dev.1 on testnet:

import { EvoSDK } from '@dashevo/evo-sdk';

const sdk = EvoSDK.testnetTrusted({ settings: { timeoutMs: 8000 } });
await sdk.connect();

const contractId = '64RTgHjGXhtiN9t5S4u6hVDps7oHuTBaaHrQEFYcxt9M';

const authVaultAccess = await sdk.documents.query({
  dataContractId: contractId,
  documentTypeName: 'authVaultAccess',
  limit: 1,
});
console.log('authVaultAccess ok', authVaultAccess.size);

const authVault = await sdk.documents.query({
  dataContractId: contractId,
  documentTypeName: 'authVault',
  limit: 1,
});
console.log('authVault ok', authVault.size);

Actual result:

authVaultAccess ok 1
protocol: Corrupted Serialization: error reading string from serialized document

Owner-filtered query also fails:

await sdk.documents.query({
  dataContractId: contractId,
  documentTypeName: 'authVault',
  where: [['$ownerId', '==', '3TvXzxbW2w2zeaTwXjXyLwjjN9M3UXzYy8d1w4Gv272x']],
  limit: 1,
});

Direct get for an existing vault id also fails:

await sdk.documents.get(
  contractId,
  'authVault',
  'GEcUCZVRbMng5ozZGcFAy5TPZMF5diN4Pm9o311PrC6t'
);

Notes

• The contract fetch itself succeeds and reports version 2
• authVaultAccess continues to deserialize correctly
• authVault schema appears unchanged between v1 and v2
• This suggests a regression in document decoding after contract update rather than a problem in the app query layer

[PastaPastaPasta]

I investigated this against the current testnet state and local deserialization code.

Verdict: partial confirmation.

The breakage described in this issue is real, but the root cause is narrower than "changing authVaultAccess broke authVault".

What I verified

Using live DAPI reads from testnet for contract 64RTgHjGXhtiN9t5S4u6hVDps7oHuTBaaHrQEFYcxt9M:

• getDataContract returns the current contract successfully
• getDocuments(authVaultAccess, limit=1) returns document bytes that deserialize successfully
• getDocuments(authVault, limit=1) returns document bytes, but decoding fails with:
  • Corrupted Serialization: error reading string from serialized document

So the failure is not in the app layer; the raw bytes coming back from Platform already reproduce the decode problem.

Key observation

The fetched live contract currently decodes as config v0, which means:

• config.version() == 0
• sized_integer_types == false

I then took the same live authVault document bytes and tried decoding them under two schema interpretations:

1. the live fetched contract as returned today
2. the same authVault schema, but rebuilt under config v1 with sized integers enabled

Result:

• decode with the live fetched contract: fails
• decode with the same schema under sized-integer config: succeeds

That means the issue is not that the authVault schema itself became incompatible. The issue is that the contract/config currently used to interpret stored authVault docs no longer matches the way those docs were serialized.

Why authVault fails specifically

The first app-level field in authVault is:

• version (type integer, position 0)

The live authVault bytes look consistent with that field having been stored as a sized integer. But when the contract is interpreted as config v0, the deserializer falls back to legacy integer semantics, reads the wrong width for the first field, and then becomes misaligned. The next field (secretKind, a string) is then read from the wrong offset, producing the exact error observed here:

• error reading string from serialized document

The sampled authVaultAccess document does not trip the same problem because its early fields do not force the same integer-width mismatch before variable-length decoding starts, so deserialization stays aligned for that sample.

Why this update appears to have been accepted

This looks like a config/version downgrade acceptance gap.

In the current codebase:

• contract version rules for protocol 11 already say config v1 is the minimum/current format
• but protocol 11 validation still uses validate_config_update = 0

That matters because the stronger config-update guard lives in the newer validation path: it explicitly rejects downgrading from config v1 to config v0 / disabling sized integers, since that can break deserialization of existing documents.

So the likely sequence is:

1. existing documents were written with sized-integer semantics
2. the updated contract now resolves as legacy config v0
3. Platform accepted that update on protocol 11 because the stricter config-update validation was not active there
4. reads of existing authVault docs now fail

Conclusion

So I would classify this as:

• real regression: yes
• exact root cause as reported: not quite

The authVaultAccess change is correlated with the bad update, but the actionable root cause appears to be that the resulting on-chain contract is being interpreted with the wrong config/version semantics for existing authVault documents.

The specific thing to inspect next is the contract update path: where a v1/sized-integer contract can end up persisted or reserialized as config v0 during update on protocol 11.

I also built a focused local proof harness using the live contract bytes + live document bytes from testnet, and it reproduces exactly this behavior:

• authVault fails under the fetched live contract
• authVault succeeds under the same schema when sized integers are enabled
• authVaultAccess succeeds under the fetched live contract

[houariblr]

I can help investigate this. I'm a Rust/C developer. Is there a bounty for fixing this?