"On-chain" or just a public spreadsheet?
Compare an illustrated linked history with an editable grid, then examine the real checks behind token control, tamper evidence and change history. This animation does not verify a project or compute cryptographic hashes.
The tamper test
Run the experiment
Claim vs reality checklist
| Claimed feature | What it requires | Blockchain | Shared spreadsheet |
|---|---|---|---|
| Token control | Network, token rules and authorized accounts | ERC-721 ownership and approval checks | Edit permission is not token ownership |
| Tamper evidence | Retained commitments and validation rules | Depends on hash validation and consensus | Change history and backups may record edits |
| Signatures | Verified signatures over defined data | Depends on protocol and wallet rules | Not inherent to a cell; inspect the system |
| Smart contracts | Deployed code, state and execution rules | Supported on programmable platforms | Formulas are not network smart contracts |
| Evidence quality | Assumptions, provenance and independent checks | Consensus is not proof of off-chain truth | Access and history depend on configuration |
Questions to investigate
Ask for the contract address
Ask which network, contract or asset identifier, and token ID the claim concerns. Verify that the identifier matches the intended project; an address alone does not establish authenticity.
Check a transaction
Inspect the claimed transaction on the stated network, its status and token transfer details. A transfer alone does not establish sale price, associated rights or the authenticity of an off-chain item.
Check authorization rules
Identify current owners, operators and administrative permissions. Deployer identity may differ from current control, and contract wallets may need multiple signers. Do not sign an unfamiliar message merely to investigate a claim.
Ask what the evidence actually proves
Does a colored cube prove that a record was hashed, signed or agreed by a network?
This six-cube animation contrasts an illustrated linked history with an illustrated editable grid. Its buttons assign display states and colors; they do not calculate any hash, edit a workbook, verify signatures or contact a blockchain. Use it to ask which checks a real system would need, then inspect the actual implementation and records.
No records, fingerprints, private keys, smart contracts or consensus checks are implemented here. Red cubes are authored animation states, not cryptographic failures. There is no export, persistent history or project verification. The example does not establish that any unnamed NFT project committed fraud.
Try a worked example
Start in linked-history mode. Tamper with record #3 makes cube 3 yellow, cubes 4–6 red, and the first two cubes stay blue. Switch mode: the button resets all six states and arranges them in a grid. Tamper again: only cube 3 turns yellow; other cubes stay gray. Reset clears the color states in the current mode. These are programmed visual responses, not measured security outcomes.
Read the animation honestly
The linked layout has six cubes and five visible connectors. Tamper assigns state “tamper” to the third cube and “bad” to the last three. Grid mode hides connectors. Changing modes also resets the states; it does not transfer an edited record between two storage systems. Drag changes the camera angle, and Reset leaves that angle and the current mode in place.
A genuine hash-linked history compares recomputed commitments with retained values. An editor could rewrite data and its hashes together unless another trusted commitment or network rule prevents acceptance. The animation implements neither comparison nor that protection; its cube colors cannot demonstrate tamper resistance.
Separate token control from broader ownership
For an Ethereum ERC-721 token, inspect the network, contract address and token ID together, then the owner and approved operators. The standard supports approved transfers, so “only the private-key holder can move it” is too broad. A token ownership entry does not by itself establish copyright, authenticity of associated media or a promised off-chain service. Ethereum: ERC-721 token standard
A smart contract is network-executed code and state at an address. Its code, permissions and external data dependencies matter; the word “blockchain” does not guarantee correct business logic. Some wallets are contracts with multiple signers, so a deployer signature alone is not a universal project-control test. This page requests no wallet interaction. Ethereum: Smart contracts
Compare configured systems rather than labels
A shared workbook can restrict edits and provide change history. Microsoft’s Show Changes documentation describes reviewing who changed what, where and when, including previous cell values. Availability and coverage depend on the workbook and supported environment; these controls do not automatically make cells cryptographically signed. “No history” is therefore not a valid general claim about spreadsheets. Microsoft: Show workbook changes
For either system, ask who may change records, which actions are logged, how independent copies or backups are checked, and what happens when credentials or administrators are compromised. Consensus establishes agreement under a protocol’s assumptions; it does not make an entered real-world claim irrefutable.
Sources and further reading
- Ethereum: ERC-721 token standard
Token identifiers, ownership queries and operator approvals; not proof of real-world rights or this animation.
- Ethereum: Smart contracts
Network code and state, external-data limits and multisignature contracts; not a security certification.
- Microsoft: Show workbook changes
Available workbook change-history features; not cryptographic equivalence with a blockchain.