New keys, old address: where does the next transfer go?
Generating a fresh key pair is straightforward. Updating everyone who knows your receiving address is harder. Applications may still refer to the old account, and someone may send it another transfer tomorrow, even after you have moved today's balance elsewhere.
Account migration needs an authorized connection between the accounts: who approves the move, how the old address resolves afterward, and which state can follow it. New keys alone do not answer those questions.
ArcBlock's US11388010B2, filed in 2019 and granted in 2022, describes recording that relationship on a blockchain. This article explains the design, then checks the address behavior against a specific SDK source revision. A patent description is not a feature guarantee for every network or wallet. The publication record provides the bibliographic details.
What the old address remains useful for
Consider a hypothetical old address A and a new address B derived from a fresh key pair.
In the flow described by claim 1, a migration transaction includes the old address, new address, and new public key. The original private key signs it. The system establishes the migration relationship and uses it when processing later transactions directed to the old account, routing incoming transfers to the new account under the disclosed rules.
A remains an address that other people know and that older records contain. B is the migration target. Keeping A useful does not make A and B identical, or preserve the old key's authority over future operations.
If B later migrates to C, the system also needs to resolve the relevant destination through that history. Claims 6 and 7 address migration ancestry and intermediate accounts. Wallet display changes cannot implement this behavior by themselves; the chain needs corresponding execution rules.
A forwarding address is a useful analogy, with a significant condition: the system must verify who can establish the forwarding relationship. Otherwise someone could redirect another person's incoming transfers.
Rotation, migration, and recovery
| Operation | Question it addresses | What it does not establish |
|---|---|---|
| Key rotation | Which verification key should an identifier or account recognize now? | Whether the address must change or stay fixed |
| Account migration | How does the system connect an old account to a new target? | That every asset, credential, and file moves automatically |
| Recovery after loss | How can control be restored without the everyday control key? | That knowing an address is enough to regain control |
Systems may use overlapping names for these operations. Examine what authorizes the change: a particular key, a group of participants, or another arrangement configured in advance.
The patent's migration flow above requires a signature from the original private key. If that key has been lost entirely and no separate recovery arrangement is available, migration cannot produce the missing signature. If the key was exposed instead of lost, both you and an attacker may be able to sign. Submission of your migration request is not evidence that it has already taken effect.
The Learning lesson on DID recovery covers another distinction: restoring control of an identifier does not automatically restore the keys needed to decrypt older files.
The SDK migration changes the address
The publicly distributed source of @ocap/client and @ocap/tx-protocols version 1.20.2 makes the terminology concrete. The following observations concern those packages; deployed networks may run different code.
The client's migrateAccount implementation takes from and to wallets. It puts to.address and to.publicKey into the migration payload and submits the transaction using from.
The execution code requires the target address to differ from the sender and to match the target public key. The target account must not already exist. After the relevant checks, it creates the target account state and records migration relationships between the accounts.
Describing this API as replacing a public key while leaving the account address unchanged is therefore inaccurate. A query using an old address may follow the migration relationship and return the new account state, which can obscure the distinction. The account management guide provides API parameters and an example.
The migration flow also handles fees and gas. Continuity of account state should not be presented as a guarantee that the numerical balance stays identical.
Historical signatures and current authority
A signed record was created with A's key last month. Does migrating to B today make that record unverifiable?
Signature verification asks whether the signed content verifies against the corresponding public key and has remained intact. Current authority asks whether the system still permits that key to act for the account now. These are separate decisions. Claim 5 addresses using the old public key to verify signatures created before migration.
Retaining that public key for historical verification does not grant it renewed authority. Removing its authority over future operations does not erase earlier signatures either.
Applications still need relevant context, including which account a record concerns and the state under which it was created. Accepting a present-day request solely because its signature is mathematically valid can miss a migration, revocation, or permission change that has already taken effect.
What follows the account?
The patent distinguishes transferable tokens from cases involving non-transferable tokens, whose rules prevent direct transfer to another account. Claim 3 concerns transferable tokens; claims 10 and 16 describe non-transferable tokens remaining with the original account. Migration is therefore not a universal instruction to move everything associated with an account.
Off-chain objects require separate attention. An application may identify its users by A. A credential may have been issued specifically to A. A file may use an unrelated encryption key. Whether these objects recognize the relationship between A and B depends on their own verification, update, and access rules. A migration record neither reissues a credential on its issuer's behalf nor reconstructs a lost decryption secret.
A balance shown on the wallet home screen is an incomplete acceptance test. Check sign-in, access to older data, and acceptance of credentials in the applications that actually use them.
How to verify a migration
Start with disposable accounts on a test network. Establish the relevant software version, transaction costs, and target-address requirements before proceeding. Moving a real account should not be the first exercise in learning this API.
You can run these checks yourself or ask your wallet or network provider for the results.
A useful check begins with A migrating to B. Confirm that the transaction has taken effect, then compare raw account records with queries that follow migration relationships. Check how new operations signed by the old key are handled, whether the new account can act under the applicable rules, and where a later transfer to A is credited. If repeated migration is supported, move B to C and inspect resolution starting from A.
Keep results for rejected cases too: migration to the same address, an existing target account, and a target public key that does not match its address. Check insufficient funds separately: this source revision does not force rejection when funds cannot cover migration costs. Cost behavior and exact errors depend on the version. A successful response from a button is not proof that the chain completed a state change.
Compare the outcomes with the version actually running on your network. Reading the published implementation can explain a rule; it does not establish that a particular deployment executes it.
When migration is unsuitable
If a program only needs permission for a limited task, consider delegation. Granting narrow authority and migrating an account to a new controlling key solve different problems.
A client cannot supply this migration design unilaterally if the target network lacks its rules. It is also unsuitable where a business requirement demands an unchanged address. If the old key is unavailable, inspect the recovery arrangements established beforehand.
After a key change, the useful continuity is a relationship the system can verify: old entry points resolve to the intended destination, new operations use current authority, and historical records retain their basis for verification. Check those outcomes separately for addresses, assets, and application data.