How can software act while your main key stays offline?
A program needs to submit a few blockchain transactions for you every day. Put the account's main private key on its server and the program can run unattended. If that server is compromised, an attacker may gain every permission controlled by that key. Sign each transaction yourself instead, and you must remain involved in every operation.
Delegation offers another arrangement: you sign a transaction granting permission, and the program uses its own key to act within that permission. The system must check both whether the signature is valid and whether its signer currently has authority to perform the operation. A separate key alone does not establish limited authority.
ArcBlock's US11245514B1 describes such an arrangement. Delegation state is stored on the blockchain; a delegate signs with an independent key; validating nodes consult that state when checking a transaction. Filed in 2019 and granted in 2022, the patent provides the basis for this explanation. It is not a current feature list for every ArcBlock product. The publication record contains the bibliographic details.
What the two keys establish
The delegator grants authority. The delegate receives permission to act. They can be different people, or two accounts controlled by the same person: one holding the main key, the other used by an online program.
To grant permission, the delegator signs a transaction identifying the delegate and the permitted operations. Nodes validate that transaction and update the corresponding delegation state. Later, the program signs a delegated transaction with the delegate's private key. The transaction must also identify the account on whose behalf it acts.
The signatures serve different purposes. The first supports the claim that the account owner granted permission. The second supports the claim that a holder of the delegate key signed this transaction and that the signed content has not changed. The second signature does not create permission absent from the first grant. Nor does it establish that the operation matches an intention the owner never expressed as an enforceable rule.
A validating node therefore needs both signature verification and the relevant permission state. A valid signature cannot make a revoked permission usable. An existing permission cannot make a forged signature valid. Claim 1 of the original patent combines permission checking with verification using the delegate's public key.
Follow a delegated task
Consider a hypothetical example for explaining the mechanism. An account permits a program to make at most three transfers within a specified period, totaling no more than ten asset units. These numbers are teaching examples, not product defaults. Which assets and operations can be constrained this way depends on the executing system.
The owner starts by specifying the permitted operation and limits, then signs and submits the grant. The program should rely on it only after the grant takes effect under the chain's rules. A wallet reporting that a transaction was sent does not establish that the permission state has changed.
Suppose the first delegated transfer moves two units. The program signs with the delegate key. The system checks the delegation relationship, the operation and its limits, and the signature. If the transfer executes, subsequent checks should use updated usage records. A second transfer of three units brings usage to five units across two operations.
| Next request | Expected decision under these hypothetical rules |
|---|---|
| A third transfer of four units within the permitted period | Nine units across three operations satisfies the stated limits |
| A fourth transfer of one unit | The count limit is exceeded even though the total would only reach ten units |
| A transfer of six units immediately after the second transfer | The total would reach eleven units, exceeding the amount limit |
| A different operation that was never granted | The transfer allowance does not supply permission for that operation |
Claim 7 of the original patent describes limits on transaction count and quantity over specified periods. The table combines those constraints into an example. A real system still needs to define units, time boundaries, and whether failed transactions consume an allowance; the example does not answer those implementation questions.
Concurrent requests matter too. Two requests might arrive together, each attempting to use the last permitted operation. An implementation must order its checks and usage updates consistently so both cannot pass against the same outdated record. A screen displaying “three operations maximum” does not establish that this behavior has been implemented.
When revocation takes effect
Claim 2 describes revoking permission through a subsequent transaction. Revocation changes the authority that nodes consult when executing later transactions. It does not erase the delegate key or reverse completed operations.
Suppose the program submits its third transfer while the owner notices a problem and submits a revocation. The order in which someone clicked two buttons does not determine the outcome. If the delegated transfer executes under a valid grant first, a later revocation does not undo it. If revocation changes the applicable state first, a subsequent transaction relying on that permission should be rejected. An application needs to report status according to the chain's confirmation rules, rather than treating submission of a revocation as the end of all exposure.
An attacker who obtains the delegate key may still exercise permissions that remain active. Count, amount, and operation limits can reduce what that key can do. Their protection depends on how narrowly they are set, whether they are enforced, and whether the owner can revoke in time. Separate keys reduce the need to keep the main key continuously exposed online; the online program still needs protection.
There is a practical question to settle before relying on this arrangement: if the main key is offline, who can sign the revocation when something goes wrong? Offline storage can reduce exposure while increasing the time needed to regain signing access.
How to apply the mechanism
Start with one concrete task. Identify the delegate, the operation, and the restrictions it actually needs. Then establish which rules the system enforces. A daily limit written in a description is not an enforced daily limit.
A useful acceptance exercise includes rejection before a grant, success within a valid grant, rejection beyond its scope, and rejection of a formerly valid request after revocation takes effect. Check how concurrent requests affect counters and how failures are reported. Retain transaction identifiers for the grant, execution, and revocation so unexpected outcomes can be reconstructed.
The existing delegate permissions guide illustrates the SDK calls for granting, exercising, and revoking permission. Package versions, endpoints, and supported limit fields must be checked against the deployment being used. The guide's older test service is not assumed to remain available, and the hypothetical numbers above are not presented as executable configuration.
AI agents need more than a wallet considers the wider question of whom an agent represents, what authorizes it, and how results can be checked. Blockchain delegation addresses part of the signing and permission problem. It does not supply business judgment: a program can perform an unwanted operation that is nevertheless within its granted authority.
When delegation is a poor fit
If the task is reading an album or calling an ordinary service, examine that service's access controls first. Delegating a task does not by itself require a blockchain transaction. The Learning introduction to delegated access starts with that everyday setting.
For occasional operations with major consequences, approval by the owner for each operation may be preferable. Delegation enables automation but asks the owner to describe acceptable behavior in advance. If that scope cannot be expressed clearly, or the executing system does not enforce it, an advance grant may not be worthwhile.
Losing the main key is a separate problem. Delegation allows another key to exercise existing authority; it does not automatically establish account recovery. Key replacement, account migration, and cancellation of old permissions depend on additional rules. A delegate being able to submit a few remaining transactions does not establish that the account can be recovered.
Why the main key can stay offline
Claim 4 describes storing the delegator's private key offline. The important step is that a grant has already entered the system. Later permitted transactions can be verified using the delegate's signature, so they need not repeatedly invoke the main key. The signatures needed to create grants, change arrangements, and respond to incidents still require their own provisions.
The related US11838405B1 is a continuation application whose claims also address conditions and revocation. Those concepts did not first appear in the later grant. Each document has its own claims; the continuation record explains the relationship.
The program can act unattended because it has its own signing key and a permission that the system checks as state changes. The main key can appear less often; the basis for authority must remain available. A revealing test of limited delegation is whether the same delegate key can still get a transaction executed after it exceeds its scope or its permission has been revoked.