中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC084

A person who can change a blockchain record is not necessarily entitled to make that change. A person named as “owner” in an application may still need other evidence to establish what is owned, under which agreement and under which law.
The useful response is to separate the questions rather than choosing one record as a universal answer. What happened technically? Which action did the organisation permit? What rights are claimed? Who has the authority and responsibility to examine the conflict?
This lesson uses a fictional museum documentation dispute. It is an evidence-reading exercise, not legal advice or a decision about anyone’s real property. The applicable jurisdiction, complete agreements and legal conclusions are deliberately not supplied. No reader is asked to recover an account, move an asset, alter a live record or contact a claimant.
Choose your reading route
In this guide
- 1. Ask “ownership of what?”
- 2. Define the fictional evidence packet
- 3. Keep five questions in separate columns
- 4. Card A: a permitted maintenance update
- 5. Card B: the application accepts an action outside the mandate
- 6. Card C: the signing address is known, but the human actor is not
- 7. Card D: a claimant’s document does not complete its own interpretation
- 8. A role change can contain a capability without settling ownership
- 9. Assign responsibility for each unresolved question
- 10. Write an evidence note that does not overclaim
- 11. Exercises with explained answers
- 12. Frequently asked questions
- 13. Sources and further reading
- Read sections 1–3 to identify the different objects and authorities.
- Work through sections 4–7 to classify the disputed evidence.
- Use sections 8–10 to assign resolution responsibilities without inventing legal outcomes.
- Finish with the exercises, answers and FAQ.
Back to contents · Next section
1. Ask “ownership of what?”
A digital artwork can involve several objects at once: a physical component, a software file, intellectual-property rights, an exhibition permission, a storage account and a database record describing the collection.
Owning or controlling one does not automatically answer the others. An application field named “owner” is still a field whose meaning depends on the system and surrounding arrangements.
Our museum example concerns record R7, which describes a fictional digital installation Q. The record contains a version reference and an organisation label. It is not itself a complete contract transferring every right connected with Q.
The museum’s existing lesson on variable artworks explains why identity, installation parameters, technology and permissions need separate documentation. Here we focus on a narrower problem: what happens when technical control and claimed entitlement point in different directions? The Artwork That Changes Every Time It Is Installed
Before evaluating a claim, write its object precisely. “J owns the record-editing account”, “J may exhibit Q” and “J owns all rights in Q” are different propositions. Evidence supporting one should not silently migrate to another.
Back to contents · Next section
2. Define the fictional evidence packet
At accepted state B100, R7 points to documentation version V1 and displays organisation label Museum M. Address K has the application’s editor role.
Technician T is assigned to operate K for the museum. The supplied internal mandate permits maintenance updates only when curator C approves the exact replacement version. It does not permit T to assign ownership, grant exhibition rights or transfer intellectual-property rights.
The application checks K’s editor role but does not itself check the curator’s offchain approval. This gap between technical capability and organisational permission is a stated feature of the toy.
Storage provider S holds a readable copy of the documentation under a supplied service arrangement requiring it to retain a recoverable copy for the museum. That arrangement does not grant S ownership of Q.
Board B has a separate, supplied procedure for revoking and replacing the editor role. We do not infer any further powers from that role-management ability.
Claimant J presents a document that appears to assign some rights concerning Q. The packet does not establish the signer’s authority, the exact rights covered or which applicable law determines its effect.
These assumptions let us make some clear findings while leaving the ownership dispute unresolved.
Back to contents · Next section
3. Keep five questions in separate columns
The first column is technical capability. At B100, can a valid request from K pass the application’s editor-role check? The answer is yes, under the supplied model.
The second is organisational permission. Did the curator approve the exact maintenance update? This is a separate fact because the application does not enforce that approval.
The third is claimed entitlement. What rights does J claim, and what does the document actually support? An unresolved document cannot be turned into a proved assignment.
The fourth is custody or service responsibility. What must S retain or return under the supplied arrangement? Access to the bytes is not the same question as ownership of the installation.
The fifth is resolution authority. Who can change the editor role, evaluate the disputed evidence or determine a legal outcome? Different people or institutions may answer different parts.
UNIDROIT’s 2023 Principles on Digital Assets and Private Law distinguish factual control from proprietary rights and explain that a change in control need not establish a transfer of those rights. We use this as an international conceptual reference, not as a declaration that the Principles govern this museum or automatically apply as Mainland Chinese law. UNIDROIT Principles, commentary 6.1 and 6.5
Back to contents · Next section
4. Card A: a permitted maintenance update
In the first independent card, C authenticates an instruction approving V2 as the exact replacement documentation version. The packet establishes that T carries out that instruction through K.
The accepted resulting state points R7 to V2 and retains the Museum M label. Other supplied application conditions are satisfied.
Two conclusions are supported. The technical update succeeded, and the action met the stated internal mandate. Neither conclusion assigns ownership of Q to T or K.
The fact that T performed maintenance does not make T the author of every component, the owner of the installation or the person entitled to license it. Those are different claims requiring different evidence.
A careful report might say: “R7 now references V2; the update matched curator C’s authenticated maintenance instruction.” It should not say: “K has proved ownership of Q.”
This is the simplest card, but it establishes the discipline needed for the disputed ones: describe exactly what the evidence proves, including the relevant permission scope.
Back to contents · Next section
5. Card B: the application accepts an action outside the mandate
Start again from B100. In this independent card, the packet explicitly establishes that T changes R7 to V3 and changes the organisation label to J, without curator approval.
The application accepts the request because K still has the editor role and all its technical checks pass. The resulting state displays V3 and J.
Technically, the edit occurred. Organisationally, it falls outside the supplied mandate. The model gives T neither the required approval for V3 nor authority to assign rights by changing the label.
It does not follow that J now legally owns Q. It also does not follow, from this exercise alone, that T committed a particular crime or owes a particular legal remedy. Those conclusions require applicable law, complete facts and appropriate adjudication.
There is no contradiction between “the application accepted the request” and “the action was outside the stated mandate”. The two sentences refer to different rules.
This is an important accountability gap. If a system checks only an address role, a technically accepted operation may still need organisational review. A valid signature cannot supply a missing curator instruction that the signature never represented.
Back to contents · Next section
6. Card C: the signing address is known, but the human actor is not
Consider a different evidence packet. An accepted edit is associated with a valid signature for K, but the records do not establish which human or process used the key at that time.
We know the request passed the supplied signature and role checks. We do not know whether T personally acted, another authorised process used K or some other circumstance explains the signature.
Do not fill that gap by accusing T merely because T normally operates the address. Equally, do not assert compromise without evidence. The correct result is an unresolved attribution question.
NIST’s Digital Signature Standard describes technical uses of signatures for data integrity and signatory authentication. Applying those mechanisms to a named human still depends on the surrounding identity and key-management evidence. Our toy signature result is not a complete investigation of who actually operated a device. FIPS 186-5
The evidence owner would need records relevant to that question, such as the authorised process, device access and approval trail, subject to appropriate privacy and authority constraints. This lesson does not instruct the reader to collect real personal data or investigate a real employee.
The lesson is simply to preserve the difference between a cryptographic result and an unsupported personal attribution.
Back to contents · Next section
7. Card D: a claimant’s document does not complete its own interpretation
Return to J’s document. Suppose the bytes and the document’s stated signatory can be authenticated. Its title includes “assignment”, but the packet still does not establish the signer’s authority or exactly which rights were assigned.
Document authenticity is progress. It is not the same as resolving authority, scope, validity or priority against another claim.
Perhaps the document concerns a limited exhibition permission. Perhaps it concerns a different version or object. Perhaps other terms alter its effect. Those are possibilities to investigate, not facts to assert.
The worksheet should record what is known: the document identity, date, parties as stated, the object it names and the unresolved clauses or authority questions. It should not choose a convenient meaning because the chain now displays J.
The reverse shortcut is also unsound. If the chain still displays Museum M, that alone does not prove J’s document has no effect. A technical record may lag behind, or may never have been designed to determine that particular right.
The appropriate conclusion remains: the supplied evidence is insufficient to adjudicate J’s ownership claim. A responsible next step is a scoped review by people qualified and authorised to resolve the relevant contractual and legal questions.
Back to contents · Next section
8. A role change can contain a capability without settling ownership
In a separate response card, Board B’s supplied procedure is validly completed. The accepted role state revokes K and grants editing authority to replacement address L.
From that effective state onward, K no longer passes this application’s editor-role check. L can pass it, subject to the application’s other conditions.
This changes the technical capability to make future edits. It does not erase the earlier V3/J entry from history, resolve J’s document, transfer copyright or prove that every copy of K’s key has disappeared.
OpenZeppelin’s pinned AccessControl implementation illustrates role membership checks and role-administrator-controlled grants and revocations. That source supports the limited technical distinction; it does not grant our fictional board authority over an artwork or legal dispute. AccessControl v5.4.0
If the museum wants a corrective record, that is another action requiring its own authority, content and evidence. The role change alone does not automatically restore V1 or V2.
Nor should the correction pretend the disputed edit never happened. In this model, a later record can identify the disputed entry and document the authorised correction while leaving the historical sequence visible.
Back to contents · Next section
9. Assign responsibility for each unresolved question
A resolution plan should separate what each participant can establish.
The technical operator can identify the accepted state, role configuration and exact edit. That is useful evidence, but it does not settle the legal meaning of an assignment.
Curator C can establish whether the stated maintenance approval was issued and which version it covered. C’s approval evidence does not automatically decide every ownership claim.
Storage provider S can demonstrate the retained documentation copy and compliance with its supplied retention duty. Its possession of a readable file does not make it the rights owner.
The museum’s designated case coordinator Z can assemble the evidence, identify contradictions and route legal questions to appropriately qualified review. Z is not given a unilateral power to decide ownership merely by coordinating the case.
Board B can use only the role-management procedure supplied in the model. Broader institutional or legal remedies would need their own authority and applicable rules.
This is accountability in a practical sense: each question has an identified evidence owner and a decision boundary. “The blockchain will resolve it” leaves those responsibilities unassigned.
Back to contents · Next section
10. Write an evidence note that does not overclaim
For Card B, a useful note separates established facts from conclusions not yet supported.
Established: K held the editor role at the relevant state; the application accepted the V3/J edit; the card expressly supplies T as the actor; no curator approval existed; the change fell outside the given internal mandate.
Unresolved: the legal effect of J’s document, the ownership of Q, any consequences under applicable law and the appropriate legally enforceable remedy.
In Card C, the note must change. It cannot carry over Card B’s supplied human attribution. Each card is independent.
This matters because evidence packets often grow over time. A fact established in one incident can accidentally be copied into another report without support. Keeping the case identity and source beside each assertion reduces that risk.
For Mainland readers, actual ownership and regulatory questions require current, applicable legal analysis. An international conceptual framework, a foreign legal article or a successful onchain edit is not a blanket permission statement about real activities.
Back to contents · Next section
11. Exercises with explained answers
Exercise 1: The matching instruction
C approves V2 and T performs exactly that update. Does this make T the owner of Q?
No. It supports a permitted maintenance action under the supplied mandate. Ownership is a different proposition.
Exercise 2: The changed label
The application accepts a change from Museum M to J. Has J’s legal ownership been proved?
No. The record change is established, but the record’s label does not adjudicate the separate entitlement evidence.
Exercise 3: The missing human attribution
A valid K signature is supplied, but the human operator is unknown. Can the report state that T personally made the edit?
No. That would exceed the evidence in Card C. The signature and role result should be reported with the attribution gap.
Exercise 4: The authenticated document
J’s document bytes and stated signatory are authenticated. Does that establish the signer’s authority to assign every right in Q?
No. Authenticity and authority are separate. The scope and applicable legal effect also remain to be examined.
Exercise 5: Revoking K
A valid role change revokes K and grants L. What has changed?
Future role-based editing capability in the specified application. The action does not erase history or resolve the ownership dispute.
Exercise 6: The storage copy
S holds a readable copy under a retention arrangement. Does access prove S owns the installation?
No. The supplied duty concerns retaining a recoverable copy. It grants no ownership of Q.
Exercise 7: A correction without a decision
Can Z, the coordinator, invent a final ownership ruling to make the records consistent?
No. Z’s job is to assemble and route evidence within the supplied authority. A tidy record is not a substitute for an authorised decision.
Exercise 8: A field named owner
What should a reader ask before relying on it?
Which object and rights the field represents, what mechanism changes it, which surrounding agreements or laws give it effect, and what supporting evidence is available.
Back to contents · Next section
12. Frequently asked questions
Does technical control have no legal relevance?
That would also be too broad. Control can be relevant under applicable rules, but its significance must be established rather than assumed to equal ownership automatically.
Can a signature prove permission?
It can be part of permission evidence when the signer, message and authority are properly established. A signature over one request does not automatically prove a different person’s approval or broader entitlement.
Does revoking a role recover every asset?
No. The effect depends on the role and system. Our revocation stops one editing capability and does not alter external files or legal rights.
Is the international reference Mainland law?
This lesson does not make that claim. UNIDROIT’s Principles provide the stated conceptual distinction; actual applicable law must be identified separately.
Must a dispute always end in a chain reversal?
No such remedy is supplied here. Technical corrections, institutional processes and legally available remedies depend on their own conditions.
Back to contents · Next section
13. Sources and further reading
Sources checked on 12 October 2026. The museum, documents, mandates, addresses and cases are fictional.
- UNIDROIT Principles on Digital Assets and Private Law: 2023 Principles, commentary 6.1 and 6.5; factual control and proprietary-right distinctions.
- UNIDROIT overview: adoption at the 10–12 May 2023 Governing Council session and publication on 4 October 2023; international framework context.
- NIST FIPS 186-5: published 3 February 2023; technical signature purposes. The landing page also carries a 12 May 2025 planning note about future corrections.
- OpenZeppelin AccessControl v5.4.0: pinned role-membership and role-management implementation.
- The Artwork That Changes Every Time It Is Installed: broader museum identity, documentation and permission background.
A trustworthy dispute record preserves both what the technology establishes and what remains for authorised human and legal processes to resolve. It does not turn the ability to edit into an automatic right to own.
