A wallet activity list can tell you that a transaction happened without explaining what an application can still do. After a swap, the purchased tokens may appear in your balance while an earlier spending permission remains active. A useful Web3 ledger records both the movement of assets and the authority granted over them.
This is a recordkeeping practice, not a custody service. A spreadsheet cannot sign transactions, revoke permissions, or recover keys. The Web3 altcoin ledger guide introduces that distinction; this article develops a practical way to document wallet interactions so later reviews do not depend on memory.
Separate connections, permissions, and transactions
A website connection, a token approval, and a completed transfer answer different questions. A connection describes an interaction between a wallet interface and a site. An approval gives a specified spender authority involving a specified token. A transfer records an actual movement. Combining these into a single activity category hides the difference between access and use.
MetaMask's explanation of smart contract allowances distinguishes disconnecting a dapp from revoking its approval. For conventional onchain approvals, revocation also requires an onchain transaction and a network fee. Closing a browser tab is therefore insufficient evidence that an allowance ended.
Build your notes around observable events. Use descriptions such as connection removed, approval confirmed, and transfer confirmed. Avoid one broad label like finished, because completing a trade says nothing about whether every related permission remains usable.
Identify the wallet and the spender precisely
Start each permission record with the network, wallet address, token contract, and spender address. A ticker helps a human scan the record, but it should never be the matching key. Two contracts can display the same symbol. Likewise, a familiar application name can refer to several contracts or deployments.
Keep the visible application label beside the exact address it requested. Record how you verified that association, when you checked it, and whether it remains uncertain. A label copied from an interface is a useful clue, not independent proof of identity.
For teams, keep wallet ownership notes in a separate address register. An address label such as operations wallet describes your internal assignment. It does not prove who currently controls the signing keys, and it should not be used to infer legal ownership from a blockchain entry.
Use three linked registers
A compact system can use three tables joined by your own interaction identifier. This makes it possible to follow one visit to a dapp without forcing unrelated evidence into the same row.
- Interaction register: date, site label, domain, wallet, network, intended action, and any connection or signature notes.
- Permission register: token identity, spender, permission type, requested limit, observed current allowance, and the block or time of that observation.
- Transaction register: transaction hash, status, actual token movements, fee asset, fee quantity, and links to related permission entries.
Keep requested and observed values separate. A prompt showing a proposed limit does not establish that the approval succeeded. Similarly, a submitted revocation is not a completed revocation while its transaction is pending.
Add a small status vocabulary: proposed, submitted, confirmed, rejected, and unresolved. Define these labels in the workbook so another reviewer applies them consistently. Store the original evidence separately from your interpretation, allowing the interpretation to change without erasing what you originally saw.
Choose an evidence retention location that another authorized reviewer can access. A row pointing to an unavailable screenshot is harder to verify than one tied to preserved data and an exact network reference.
Follow a hypothetical swap from start to finish
Suppose a wallet holds 500 units of an example token. An application requests permission to spend 120 units, and the user subsequently swaps 30. These numbers illustrate the records; they describe no actual token or trading result.
The approval entry records the proposed 120 units, the spender, and the approval transaction. After confirmation, a balance check still shows 500 units. The permission did not itself represent the purchase or the transfer of those 120 units.
The swap entry records the actual 30 units sent, the output token and quantity received, and the fee in its own asset. If a later allowance query returns 90 units, record that result with its observation block. Do not infer the allowance solely by subtraction, because contract behavior and intervening activity need checking.
Finally, link the interaction to both transactions. A reader can now see the original intent, the permission granted, the assets moved, and the remaining authority. The DeFi position ledger walkthrough extends this method when a swap leads into lending or liquidity provision.
Give signatures their own evidence trail
Some signing requests do not immediately create a transaction hash. This is not enough to classify them as harmless or irrelevant. ERC-2612, for example, defines signed token approvals that can be submitted later, with fields including the owner, spender, value, nonce, and deadline.
For a permission-bearing signature, record the displayed purpose, relevant contract and network, limit, expiration information, and whether you can verify subsequent use. Do not invent a transaction identifier for the moment of signing. If a later transaction uses the authorization, connect that confirmed event to the earlier signature record.
A deadline can govern when a signed permit may be submitted; it does not automatically mean that an allowance created by using that permit expires at the same moment. Read the particular permission mechanism before assigning an end date.
Review current state as well as history
Begin a review from a complete list of the wallets and networks in scope. A clean result on one network says nothing about another. For each known permission, compare the recorded spender and asset identity with a current state observation. Preserve the historical record even when the current allowance is zero.
When an entry cannot be matched, put it in an exception list with a concrete question: Was this spender replaced? Was the permission granted through a different mechanism? Is the source missing older events? The next reviewer should know what evidence would resolve the issue.
After an authorized revocation, capture its hash, final status, and the resulting permission state. A failed transaction belongs in the history but does not establish that the permission changed. Your ledger documents the result; changing a cell from active to revoked has no effect on the contract.
Use the Web3 ledger reference page as the stable home for these definitions when several people maintain the same records.
Common mistakes that weaken a permission review
One mistake is treating a zero token balance as a zero allowance. Record the two observations independently. Another is grouping spenders by application name and accidentally hiding a contract you have never reviewed. Preserve full addresses even when the display shortens them.
Do not treat every NFT permission like a fungible token spending limit. Collection-wide operator permissions and permissions for individual tokens need different fields. Mark the scope explicitly instead of squeezing both into an amount column.
Finally, avoid storing recovery phrases, private keys, or reusable secret credentials in review notes. Reviewers need identifiers and evidence, not signing authority. Broader balance checks belong in the crypto reconciliation process.
Questions that arise during review
Does an approval prove that tokens were spent?
No. Treat it as evidence of permission. Look for the corresponding confirmed asset movement before recording a spend, and keep approval fees distinct from the assets involved in the later action.
Can an empty transaction export prove there are no permissions?
No. The export may have a limited date range or omit a relevant mechanism. Record its coverage and use current permission observations where available. Absence from one file is a statement about that file.
Should a disconnected application disappear from the ledger?
Keep the historical interaction and record its connection status separately. Removing the row would make it harder to explain why the permission exists or which action originally required it.
A useful ledger makes authority visible
The strongest permission record connects intent, authorization, execution, and current state without confusing them. Start with one wallet, identify its contracts precisely, and resolve uncertain entries through evidence. Over time, this creates an understandable history of application access while leaving custody and transaction approval in the wallet where they belong.
