hiveOperationAuthority does not match Hive consensus for owner changes, and cannot express mixed custom_json

[feruzm]

resolveOperationAuthority in src/utils/hiveOperationAuthority.ts:37 maps an account_update2 payload that sets owner to 'active'. Hive requires owner authority for that change. Hive's own test matrix has both the active-signed update and the posting-signed update failing (https://gitlab.syncad.com/hive/hive/-/issues/520).

The function is typed (operation: Operation) => 'posting' | 'active', so it cannot express 'owner' at all. src/utils/hiveOperationAuthority.test.ts has no owner case either.

Why it is reachable: the resolver serves the hive-uri path (src/providers/hive/hive.ts:750 and src/hooks/useLinkProcessor.tsx:648), where operations arrive from an external link. A hive://sign/... link whose account_update2 sets owner is currently routed to active signing. The broadcast is then rejected on chain, so the user sees a confusing failure rather than a clear "not supported" message.

Mobile has no owner signing path regardless: mobilePlatformAdapter.ts decrypts only the posting plus active keys and does not implement getOwnerKey, so @ecency/sdk's case 'owner' throws "Owner key not supported by adapter".

Suggested fix: widen the return type to include 'owner', return it when the payload sets owner, then have the hive-uri path reject an owner-authority transaction with an explicit unsupported message instead of attempting an active signature. Add the missing owner test.

Related: @ecency/sdk's OPERATION_AUTHORITY_MAP has the same flat account_update2: 'active' entry, with no payload inspection in getOperationAuthority, so the shared map carries this gap too. Worth a companion issue on vision-web if we want the SDK to be authoritative here.

Found while correcting the add-mutation skill in #3534. That PR documents the correct three-row rule plus this gap; it does not change the resolver.

[feruzm]

Scope correction: this affects both account update operations, not just account_update2.

Hive issue 520 states that its cases 1 to 15 are the same for account_update_operation as for account_update2_operation, which includes the owner cases. So a v1 account_update that sets owner also requires owner authority, with active-signed plus posting-signed attempts failing.

resolveOperationAuthority handles v1 worse than v2. There is no account_update branch at all (grep -c "operationName === 'account_update'" returns 0), so it falls through to the POSTING_AUTH_OPERATION_NAMES default and resolves to 'active' unconditionally. The function's own doc comment asserts this is correct:

account_update (v1) is not listed, so it correctly resolves to active.

That comment is wrong whenever the payload sets owner, and should be corrected along with the code.

@ecency/sdk has the same flat pair at authority-map.ts:51-52:

account_update: 'active',
account_update2: 'active',

So the fix list grows by one branch plus one comment: widen the return type to include 'owner', return it when either operation sets owner, reject owner-authority transactions on the hive-uri path with an explicit unsupported message, then add owner tests for both versions.

[feruzm]

Second consensus mismatch in the same function, found while correcting the add-mutation skill.

custom_json may populate exactly one authority list. A payload carrying both required_auths and required_posting_auths is rejected by Hive outright: issue 632 case 2.3 records "An error occurs - the operation is not added to the blockchain."

resolveOperationAuthority never reads required_posting_auths at all (grep -c returns 0). It resolves purely on required_auths, so a mixed payload becomes 'active', gets signed, then is refused by the chain. The user sees an opaque broadcast failure rather than "this operation is malformed".

@ecency/sdk shares the defect at authority-map.ts:123-125: getCustomJsonAuthority returns 'active' as soon as required_auths is non-empty, without checking whether the posting list is also populated.

Since this lands in the same function as the owner-authority gap, the issue is retitled to cover the function rather than one operation. Fix list is now:

• widen the return type to include 'owner', then return it when account_update or account_update2 sets owner
• reject a custom_json that populates both authority lists, rather than resolving it to active
• have the hive-uri path surface an explicit unsupported or malformed message instead of attempting a signature
• add tests for owner on both account update versions, plus the mixed custom_json case
• correct the doc comment claiming v1 "correctly resolves to active"

PR #3534 documents all of this in the skill. It does not change the resolver.

[feruzm]

Correction to my previous comment. I had the custom_json rule wrong, so the mixed-authority half of this issue should be rescoped.

I cited Hive issue 632 case 2.3 for "Hive rejects a mixed payload outright". That test predates HF28. Checking the protocol source instead:

• custom_json_operation::validate() in libraries/protocol/hive_operations.cpp does not reject both lists. It only asserts num_auths = required_auths.size() + required_posting_auths.size() is greater than zero, plus a membership cap.
• libraries/protocol/transaction.cpp gates the restriction on allow_strict_and_mixed_authorities, with the comment "Up to HF28 posting authority cannot be mixed with active authority in same transaction". Before HF28 it asserted !required_active.size(); after HF28 it does not.
• Mainnet reports current_hardfork_version 1.28.0, so mixed authorities are valid on chain today.

So a mixed custom_json is valid on Hive and unsupported by this app, which is a different defect from the one I described.

The mobile limitation is real and worth stating: resolveTxRequiredAuthority collapses an entire transaction to one 'posting' | 'active', and src/providers/hive/hive.ts:750-755 then decrypts exactly one key from that. A payload needing both a posting signature and an active signature cannot be signed by that flow at all.

Revised item for the fix list, replacing my earlier one:

• detect a custom_json that populates both authority lists and surface it as unsupported by this client, rather than resolving it to 'active' and producing a transaction signed with one key that the chain will reject for a missing signature

The owner-authority half of this issue is unaffected and still stands.