SDK cutover — Platform SDK B: remove the legacy dpp types (drop org.dashj.platform)

[HashEngineering]

Goal

Remove the remaining org.dashj.platform types from the wallet and delete the dash-sdk-java / dash-sdk-kotlin dependencies, so no part of the legacy platform SDK survives in the build.

Platform SDK A retires the legacy client and drops the native artifact. This issue retires what is left: the value objects, enums, and utilities the wallet uses as its internal domain model.

Why this is a separate issue

The Kotlin SDK's queries return JSON strings, not typed models — Identities.fetch, all five Voting.*, all four Dpns.* all return String? on the pinned 0.1.0-v42int4. So these types are not swapped for SDK equivalents; they are replaced by wallet-owned models plus parsing. That is mechanical, independently testable work with no network behavior in it, and it should not be entangled with the client cutover.

What gates this issue

Most of it is not gated at all — see "Work that is not gated" below, which is the bulk of the file churn and can start immediately.

Two parts are. The txMetadata items sit behind #1540, which sits behind the upstream encrypted-document surface. That surface is the single upstream dependency for the whole legacy-platform-SDK removal track, not just for #1540: the wallet cannot drop the dpp TxMetadataItem while still calling BlockchainIdentity.publishTxMetaData, and it cannot stop calling that until the SDK has somewhere to publish to. The DPNS helpers (blocker 1) are the other gated part, and that one is a much smaller ask.

Scope

Roughly 57 files beyond Platform SDK A's 26 — about 83 files in total once type users that do not import the package directly are included. The churn is concentrated in a handful of types, not spread evenly:

Type	Usage	Replacement
dpp.identifier.Identifier	217 mentions across 45 files	wallet-owned id type, or raw ByteArray / base58 String as the SDK uses
dashpay.UsernameStatus, UsernameRequestStatus, IdentityStatus, UsernameInfo	122 mentions across 14 files	wallet enums — the SDK has no opinion on these; they are wallet state-machine concepts
sdk.platform.Names.normalizeString	46 call sites	see blocker 1
sdk.platform.Names.isUsernameContestable	22 call sites	see blocker 1
sdk.platform.DomainDocument accessors (normalizedLabel, label, dashUniqueIdentityId, dashAliasIdentityId, normalizedParentDomainName)	~86 mentions	wallet model over the SDK's JSON
dpp.document.Document, dpp.contract.DataContract, dpp.identity.Identity	~25 mentions	wallet models over the SDK's JSON
dpp.voting.* (Contenders, ResourceVoteChoice, Vote, Epoch, BlockInfo, ContenderWithSerializedDocument, ContestedDocumentResourceVotePoll, …)	~20 mentions	voting.VoteChoice for casting; wallet models for read shapes
wallet.TxMetadataItem / TxMetadata / TxMetadataDocument / WalletUtils	txMetadata payload	see blocker 2
dpp.util.Cbor, Converters, HashUtils, toHex, toHexString	12 sites	trivial wallet-side ports
dpp.errors.concensus.*	11 sites	already dead after Platform SDK A — delete
dapiclient.MaxRetriesReachedException, NoAvailableAddressesForRetryException, GrpcExceptionInfo	7 sites	already dead after Platform SDK A — delete
sdk.KeyType, sdk.Purpose	3 sites	identity.KeyType / identity.KeyPurpose — near-direct swap

Blockers

1. DPNS label helpers — SDK-side ask

• Names.normalizeString (46 sites) — normalizeDpnsLabel exists in v42int4 on PlatformWalletPersistenceHandlerKt as a JVM-public static but is Kotlin-internal, so wallet Kotlin cannot call it. Needs a visibility change upstream, a Java shim, or a wallet-side port.
• Names.isUsernameContestable (22 sites) — does not exist anywhere in the SDK on any branch reviewed. Add upstream or port.

These are the only two items in this issue that cannot be resolved wallet-side alone. Both are pure functions on Names$Companion with no JNI dependency, which is why they survive Platform SDK A.

2. TxMetadataItem model and protobuf — gated on #1540, and the choice is effectively made

The legacy dpp provides TxMetadataItem (19 fields, toObject(), toProtobuf(), toJson(), getSize(version)) and dpp/src/main/proto/wallet-utils.proto. The SDK provides neither, by design — the payload is opaque to it, and there is no .proto for TxMetadataItem anywhere in the platform repo.

Nominally there are two options: copy the model and .proto into the wallet and own them here, or push them upstream into the SDK. In practice the second is not realistic. The encrypted-document surface those types would serve has been attempted seven times upstream, landed once (dashpay/platform#4277) and was reverted within fourteen hours (#4279); the only live PR (#4243) is stale and conflicting. See the upstream history table in #1540. Adding a new model plus protobuf to that same area is not a plan with a timeline behind it — and if #1540 takes the option of folding the surface onto our own integration build, we are maintaining the port regardless.

Recommendation: own the model and the .proto in the wallet. It matches the SDK's stated payload boundary, and it is the only version of this that does not depend on upstream.

Note the dependency: this item cannot be done ahead of #1540. The wallet cannot drop the dpp TxMetadataItem while it is still calling BlockchainIdentity.publishTxMetaData, whose signature takes List<TxMetadataItem>. So this work sits behind #1540, which sits behind the upstream surface.

Work that is not gated

None of this touches txMetadata or the DPNS helpers, so it can proceed while #1540 is blocked:

• Identifier — 217 mentions across 45 files. The largest single item in the issue.
• The four status enums (UsernameStatus, UsernameRequestStatus, IdentityStatus, UsernameInfo) — 122 mentions across 14 files, plus the Room ordinal question below.
• Document / DataContract / Identity / DomainDocument models over the SDK's JSON.
• The voting read shapes (Contenders, Epoch, BlockInfo, ContenderWithSerializedDocument, ContestedDocumentResourceVotePoll).
• Utility ports — Cbor, Converters, HashUtils, toHex, toHexString (12 sites).
• Straight deletions — the dpp.errors.concensus.* branches (11 sites) and the dapiclient exception types (7 sites), both dead once SDK cutover — Platform SDK A: retire the legacy platform client (stop loading libsdklib) #1540 lands but harmless to remove ahead of it if the paths are already unreachable.
• sdk.KeyType / sdk.Purpose → identity.KeyType / identity.KeyPurpose (3 sites), subject to the Room ordinal constraint.
• Re-typing the adapter boundary in SdkVotingQueries / SdkIdentityVerifyWrites (see below).

That is the majority of the ~83 files. Sequencing this first also de-risks #1540's remaining work, since the model layer it will need already exists.

Room persistence — migration hazard

database/BlockchainStateRoomConverters.kt:100-126 persists legacy enums by ordinal:

• UsernameStatus (toUsernameStatus / fromUsernameStatus, :100-106)
• IdentityStatus (toRegistrationStatus / fromRegistrationStatus, :110-115)
• sdk.KeyType (toCurrentMainKeyType / fromCurrentMainKeyType, :120-126)

Replacement enums must preserve ordinal order, or the change needs a Room migration. Existing installs carry these values.

fromIdentity (:140) also writes a legacy Identity CBOR blob to a column. The read side is already dead — toIdentity (:146) is @Deprecated and returns null unconditionally — so only the write path and the column need retiring.

Adapter boundary

service/platform/sdk/SdkVotingQueries.kt and SdkIdentityVerifyWrites.kt were deliberately written to return legacy dpp types (Contenders, Epoch, BlockInfo, ContenderWithSerializedDocument, Document, DataContract) so their callers would not have to change during Phase 1. Re-typing that boundary — and every caller behind it — belongs to this issue.

Worth confirming before starting

v42int4 added an org.dashfoundation.dashsdk.dpns package (a DPNS name marketplace: buy/sell, price history, sync). Nothing the wallet uses today — but it is the first place the SDK returns typed models instead of JSON: DpnsMarketplace.Companion.decodeName / decodeNames / decodeStates / decodeHistory / decodeSyncSummary all hand back data classes.

That is exactly the shape this issue needs for identities, documents, and voting. Ask the SDK team whether the same typed-decode treatment is planned for the core queries before building the wallet-side model layer — if it is, a large part of this issue's scope goes away; if it is not, that is worth knowing before writing 45 files' worth of models.

Acceptance

• No org.dashj.platform reference remains in wallet/src or wallet/test.
• dash-sdk-java and dash-sdk-kotlin are removed from wallet/build.gradle; the dppVersions block and dppVersion property are deleted.
• Room reads back existing rows unchanged, or ships a migration.
• txMetadata publish/fetch works with the wallet-owned item model.

Prerequisites: #1540 complete for the txMetadata items (the client is gone, so the remaining references are type-only). The DPNS helper asks (blocker 1) resolved or ported. Everything under "Work that is not gated" can start before either.

Not gated on dashj Phase 2 or Phase 3 — this is wallet-internal type churn on a different dependency.