Verifiable Time Allocation

Abstract

This document specifies time allocation records: a per-week, chain-anchored commitment by a BRC-169 handle to how its holder spent the 168 hours of that week, together with a disclosure mechanism that reveals chosen hours to chosen handles and nothing to anybody else.

A week holds 168 hours and no more. That bound is the whole contribution. An invoice can claim any number of hours; a record whose total is fixed by the calendar cannot, and cannot claim an hour twice. Everything else here — the commitment format, the disclosure ladder, the countersignature — exists to make that bound checkable by somebody who was not there.

The record is a commitment, not a publication. One signed object per week carries a Merkle root over the week's hours and reveals nothing else, not even how many hours were allocated. Disclosure is a separate, later, deliberate act: the holder reveals specific hours to a specific handle, at a chosen level of detail, and the recipient verifies each revealed hour against the root already on chain.

Hours are not transferable, and this document is emphatic about it. An hour may name another handle as the party it was worked for, and that handle may countersign it, but no mechanism moves an hour from one person to another. Time that can be bought is not a record of a life; it is a currency, and section 2 of the Prior Art explains why that has been tried.

No new cryptographic primitive is introduced. The commitment is a BRC-48 PushDrop output, the signatures are BRC-3, disclosure keys are derived under BRC-42 and encrypted under BRC-2, countersignatures are BRC-52 certificates, and delegated allocation is BRC-169 section 9.

Motivation

Time is the one input nobody has more of. It is also the input most often invoiced, most often disputed, and least often evidenced. A timesheet is a claim a person types after the fact into a system their counterparty controls, or their employer controls, or nobody controls. The dispute that follows has no arbiter but the relationship, which is why the honour system survives in professions that would never accept it for money.

Three properties are missing, and they are missing together.

A total that cannot be inflated. A week has 168 hours. Two clients who agree on the calendar agree on that number without trusting each other, so a record constrained to it carries a bound nobody had to be persuaded of. This is a smaller claim than "these hours were worked" and a far more robust one: over-claiming is not forbidden, it is unrepresentable, for the reason section 2.2 gives.

Be precise about who that binds, because the obvious version of the claim is wrong. It does not let one client detect that a freelancer billed three of them for the same hours: a client granted forty hours sees forty, and section 6.2 explains why a total is not provable to somebody who has not been shown the positions. What it does is bound each disclosure against every other disclosure from the same handle. Two clients each shown the placement of their own hours can compare, and the same hour cannot appear in both — one hour, one leaf, one subject. The bound is not "nobody can over-claim"; it is "the same hour cannot be sold twice, and a week cannot hold a 169th".

A moment the claim was made. The difference between a contemporaneous record and a reconstruction is the whole of its evidentiary value, and it is exactly what a timesheet cannot show. A row in a database has whatever timestamp the database was told to write. An output in a block has a height, and a claim committed nine days after the hour it describes is visibly a different kind of claim from one committed within the hour. This document does not forbid late allocation — a hard deadline only moves the lie earlier — it makes lateness a published property of every hour, and lets whoever is relying on the record decide what they will accept.

Disclosure that is an act rather than a setting. Time data is unusually revealing. When somebody works discloses their employment, their religion, their health, their childcare arrangements and their sleep, and it discloses these from the shape of a week rather than from any label attached to it. A system that stores this in a vendor's table and offers a sharing toggle has already lost: the vendor sees everything, the toggle governs only what the vendor chooses to honour, and nothing that has been shared can be recalled. Here nothing is legible by default, including to the ecosystem host; a disclosure names a recipient, a slice and a level of detail; and it is irreversible in the only honest sense, which is that the holder can stop granting and cannot un-grant.

What this is not for

A document that argues only for its mechanism invites its own worst deployment, so this one says at the outset where it should not go.

It is not a productivity instrument, and it deliberately provides nothing to optimise. There are no streaks, no scores, no comparisons and no leaderboards, because a record of how somebody lived stops being true the moment it becomes a target — Goodhart's observation applies with unusual force to a measure the subject writes themselves. Section 7.8 makes this a requirement on clients rather than a hope.

It is not an employer's tool. The screenshot-and-keystroke category of workplace surveillance solves a different problem for a different party, and the mechanism here would serve it badly and serve it anyway if pointed at it. What limits that is not the protocol but the fact that disclosure originates with the subject; what does not limit it is anything, if the subject needs the job. Section 9 is blunt about coercion, because it is the primary threat and it is not a cryptographic one.

And it is not proof that any work was done. It proves a claim was made, when it was made, that it fits inside a week, and that it has not silently changed. Section 8 says so in those terms, and says what countersignature does and does not add.

Prior Art

Five bodies of work bear on this. The design borrows from the first two, diverges sharply from the third, refuses the fourth outright, and inherits a warning from the fifth.

Verifiable credentials and selective disclosure. The W3C Verifiable Credentials Data Model, and the selective-disclosure schemes built over it, established the shape used here: commit once, reveal per-verifier, prove the revealed part against the commitment. Section 6's field commitments are the ordinary construction, not a novelty, and it is worth saying so rather than presenting a Merkle tree as an invention. What is specific to this document is the slice: a credential discloses attributes of a subject, while a time record discloses a subset of 168 positions, and the positions themselves are the sensitive part.

Trusted timestamping. The second of the three properties above — a moment the claim was made, attested by somebody other than the claimant — is the most established part of this design and the part most likely to be mistaken for new. RFC 3161 specified a Time-Stamp Protocol in 2001, in which an authority signs a hash together with a time; its weakness is the authority, which can be compelled, can backdate, and has to be trusted about the one fact it exists to establish. OpenTimestamps replaced the authority with a chain, anchoring a Merkle root in a Bitcoin transaction so that the timestamp is attested by proof of work rather than by a signature, and it is the direct ancestor of section 3.1.

What this document adds to that lineage is not the anchoring but what is anchored. A timestamp proves a document existed; a commitment here proves a bounded claim existed, and the bound is what a timestamp alone cannot supply. Section 3.4's lateness is the timestamp read the other way round — not "this existed by then" but "this was recorded this long after the fact" — which is the more useful direction when the thing being dated is a claim about the recent past.

Time tracking as a product category. Harvest, Toggl, Clockify and Tempo record hours for billing; RescueTime and its successors record them for self-knowledge; Hubstaff, Time Doctor and ActivTrak record them for employers, with screenshots and keystroke counts. The first group produces a claim in the user's own database, which the client is asked to trust. The third produces evidence the worker cannot audit, dispute or withhold. Neither produces something a third party can check without trusting the operator, and neither constrains the total: a timesheet application will accept a fiftieth hour on Tuesday without complaint, because it is recording what it was told rather than allocating from a budget.

The legal profession's six-minute billing increment is the sharpest illustration of where fine granularity leads. Dividing an hour into ten units did not make the record more truthful; it made the smallest claimable unit small enough that the act of recording became continuous, and it is now the standard example in the literature on how measurement deforms the work being measured. Section 2.3 keeps the hour indivisible for that reason and not for a technical one.

Time as currency. Time banking is the closest and most instructive relative. Edgar Cahn's Time Dollars, from 1980, and Ithaca HOURS, from 1991, both made an hour of somebody's labour into a transferable unit that could be earned, held and spent. The idea has a forty-year record and a real literature, and it is a genuinely different proposal from this one in a single respect that changes everything: there, an hour moves.

This document refuses transfer, and the refusal is load-bearing rather than conservative. An hour that can be transferred can be accumulated, so the 168-hour bound — the only property here that anybody has to trust arithmetic rather than a person for — dissolves immediately. It can be bought, so a record of how somebody spent their week becomes a record of what they could afford. And it can be demanded, which is a worse thing to be able to do to a person than to ask them for money. Time banking accepted all three consequences deliberately, in exchange for a medium of exchange denominated in something everyone has equally. That is a coherent trade and it is not this one. Section 5.1 forbids transfer at the level of the mechanism rather than by convention, because a rule of this importance that a client could quietly relax is not a rule.

Non-transferable tokens as a general construct were argued for in Decentralized Society: Finding Web3's Soul (Weyl, Ohlhaver and Buterin, 2022), and proof-of-attendance schemes such as POAP are the widely deployed instance. Both establish the pattern of a token that marks rather than moves. Neither addresses a budget: attendance tokens accumulate without bound, which is appropriate for attendance and fatal for time.

The critique of clock-time itself. E. P. Thompson's "Time, Work-Discipline, and Industrial Capitalism" (Past & Present, 1967) traced how the clock reorganised labour, replacing task-orientation with time-orientation and, with it, a particular kind of discipline. Shoshana Zuboff's The Age of Surveillance Capitalism (2019) describes the modern form, in which the record of a life becomes an asset held by somebody else. Neither is an argument against measuring time, and this document does not pretend they are. They are an argument that a mechanism for quantifying a life should be honest about what it enables, should default to revealing nothing, and should refuse the features that make quantification compulsory. Sections 7.8, 9 and the Security Considerations are what that argument looks like written as requirements.

Specification

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119. They are used sparingly, and where interoperability or a privacy property actually breaks; the rest of this document describes a mechanism.

Throughout, "handle" and "resolve" have the meanings given in BRC-169 sections 2.1 and 5.7.

1. Terminology

• Hour: one of the 168 positions in a week. The unit of allocation, and indivisible.
• Week: an ISO-8601 week, beginning Monday 00:00 UTC. Identified as 2026-W31.
• Allocation: a claim that a given hour was spent in a given way. An hour is either allocated or untracked; untracked is the default and is not a category.
• Budget: the 168 hours of a week. Conserved, per section 2.2.
• Commitment: the signed, chain-anchored object binding a handle to a week's allocations without revealing them, per section 3.
• Disclosure: the act of revealing chosen fields of chosen hours to a chosen handle, per section 6.
• Grant: the signed object authorising and describing one disclosure.
• Subject: an optional handle an hour was worked for. Not a recipient of anything.
• Countersignature: a subject's signed agreement that an hour naming them is accurate, per section 5.3.

2. The Week and the Budget

2.1 Weeks are UTC, and displayed locally

A week is an ISO-8601 week beginning Monday 00:00 UTC, and hour index 0 is the hour beginning at that instant. Hours run 0 to 167.

The record is in UTC and the interface is not. Two clients must agree on which hour an allocation refers to, and they have no shared local time — a user in Auckland and one in Lisbon disagree about which day it is for six hours out of every twenty-four, and a "week" anchored to either of their calendars is not a week the other can verify against. So the wire form fixes UTC, and a client renders it in whatever local frame its user lives in, exactly as it renders satoshis in a currency. A user who moves between zones does not acquire or lose hours; their grid shifts.

Pay periods, contract weeks and fiscal weeks do not align with this and are not meant to. They are a matter for whoever is reading the record, who can sum whatever slice they were granted.

2.2 Conservation

Three bounds hold, and they are the reason this document exists:

1. A week's allocations total no more than 168 hours.
2. No hour is allocated more than once.
3. A calendar day's allocations total no more than 24 hours.

None of the three is a rule a client enforces. All three are properties of the encoding. The commitment of section 3.2 has exactly one leaf per hour and exactly 168 hour-leaves, so a 200-hour week has nowhere to put the extra thirty-two, hour 34 cannot carry two allocations because there is one leaf for it, and a calendar day is twenty-four leaves whatever is written into them. Over-allocation is not refused; it is unrepresentable.

That distinction is the document's central claim and it is easy to state as something weaker. A timesheet application accepts a fiftieth hour on Tuesday and could be programmed not to; the difference here is that there is no fiftieth hour to accept. A verifier therefore needs no bound-checking logic, and an implementer who goes looking for a rejection path has misread the construction.

What a verifier does check is the shape: that the tree carries 256 leaves and that a disclosed index is below 168. A root computed over a wider tree would admit a 169th hour, and that is the only way the bounds could be evaded.

No other constraint is imposed. Earlier drafts of this mechanism suggested a minimum for sleep, a maximum for a working day, and a warning for patterns a circadian model considered implausible. All of that is removed. A specification is not entitled to an opinion about how long its users should sleep, and a client that nags a shift worker, a new parent, an insomniac or somebody in the middle of a deadline has substituted a designer's model of a life for the life being recorded. The arithmetic is the whole of the validation.

2.3 The hour is indivisible

An hour is allocated whole, to one category, with one optional label and one optional subject. There is no half-hour and no fractional allocation across categories.

This is a deliberate refusal of precision rather than a limitation to be lifted later. Finer units do not produce a truer record; they produce a record that costs more to keep and invites the continuous self-accounting the six-minute increment is famous for. A working lunch is one hour of something, and requiring the user to decide which thing is a smaller imposition than requiring them to decide that it was 0.6 of one and 0.4 of another. Where an hour genuinely divides, the honest allocation is the activity that dominated it, and where nothing dominated it, the honest allocation is other.

Untracked hours are not a failure state. A week with sixty hours allocated and a hundred and eight untracked is a complete and valid record of sixty hours.

3. The Commitment

3.1 One object per week

A commitment binds a handle to a week's allocations without revealing them:

{
  "protocol": "metanet-time",
  "version": 1,
  "handle": "@crumbs@nexus.app",
  "week": "2026-W31",
  "counter": 1,
  "root": "<32 bytes, hex>",
  "replaces": null,
  "signature": "<DER, hex>"
}

It is signed by the handle's identity key over the RFC 8785 canonical form of the object without signature, and published as a BRC-48 PushDrop output so that it acquires a block height. The height is the commitment's timestamp and is not carried in the object, because a self-asserted time is the thing this mechanism exists to replace.

A client MAY submit the output to the overlay topic tm_timealloc, discoverable through ls_timealloc, so that a counterparty can find commitments for a handle without being sent them. As BRC-87 establishes no registry, these names are claimed rather than reserved, and an implementer finding either serving something else should raise it against this document.

The commitment reveals nothing about the week. Not the categories, not the labels, not which hours were allocated, and not how many. Its existence discloses that the handle keeps time records at all, which is the one leak the format cannot avoid and which section 9 says to weigh before starting.

3.2 The tree

The root commits to 256 leaves, being the 168 hours and 88 fillers, arranged as a binary Merkle tree of depth 8 with SHA-256(left ‖ right) at each internal node.

Each hour has four field commitments, so that a disclosure can reveal an hour's category without revealing its label:

salt(i, f) = HMAC-SHA-256( weekSecret, uint8(i) ‖ f )
c(i, f)    = SHA-256( salt(i, f) ‖ value(i, f) )
leaf(i)    = SHA-256( c(i,"cat") ‖ c(i,"sub") ‖ c(i,"lab") ‖ c(i,"note") )

where f is one of the ASCII strings cat, sub, lab, note; value is the field's UTF-8 bytes, or the empty string where the field is absent; and an untracked hour has all four values empty. Filler leaves, for i from 168 to 255, are SHA-256( salt(i,"pad") ‖ uint8(i) ).

weekSecret is derived under BRC-42 from the handle's identity key with protocol ID [2, "metanet time"] and key ID the week identifier, so a client holds no salt store and can reconstruct any week from its key alone.

Three details are load-bearing.

Salts are not optional. The category vocabulary of section 4.1 has six members and the label space of a given user is small and guessable. An unsalted commitment to a category is recoverable by trying all eight, so an unsalted tree would publish the whole week to anybody who cared to grind it. Every field commitment MUST be salted, and an implementation that omits the salt has published what it believes it has hidden.

Untracked hours are committed, not omitted. An untracked hour has a leaf of the same shape as any other. If untracked hours were absent from the tree, the shape of the week would be legible from the tree's structure, and the shape is the sensitive part.

Fillers exist so that the tree does not duplicate. Padding a 168-leaf tree by repeating the last leaf admits the well-known second-preimage confusion between a leaf and an internal node; distinct salted fillers avoid it and cost nothing.

3.3 Correction supersedes and does not erase

A later commitment for the same week and handle, carrying a higher counter and the digest of its predecessor in replaces, supersedes it. Verifiers MUST follow the chain and use the highest counter they can find, and MUST reject a commitment whose replaces they cannot resolve, since a break in the chain is how a correction hides what it corrected.

Corrections are expected and are not shameful: people misremember Tuesday. What is not available is silent correction. The prior commitment stays on chain, its height stays visible, and a recipient of a disclosure MUST be shown that an hour was amended, when, and — where they held a disclosure of the earlier version — what it said before.

This answers the question of whether records should be immutable with a third option. Immutable records force people to choose between an inaccurate record and no record. Editable records prove nothing. A superseding chain with visible history is accurate and evidential, and it puts the cost of frequent revision where it belongs, on the credibility of the person revising.

3.4 Lateness is a property of every hour

An hour's lateness is the difference between the height at which its commitment was confirmed and the height at the end of the hour it describes. It is computed by the verifier from facts already on chain, is not asserted by anybody, and cannot be forged downward.

There is no allocation deadline. A user may commit a week years afterwards, and the record will say so. This is a deliberate reversal of the obvious design: a two-week window would let a reconstruction inside the window pass as contemporaneous, and would make an honest late record impossible, so it would suppress exactly the records that admit what they are. Publishing lateness instead moves the judgement to the party relying on it, which is where it belongs — a client paying an invoice may insist on hours logged within a day, a grant body reviewing six months of volunteering may not care, and neither has to argue with a rule set by this document.

A client MUST display lateness wherever it displays an allocation to a third party, since a verifier who cannot see it is relying on a record whose most load-bearing property has been hidden. A client SHOULD also show a user the lateness their allocation will carry before they commit it: discovering afterwards that a week's work is stamped "logged 11 days late" is a surprise the interface could have prevented.

4. Categories, Labels and Subjects

4.1 Categories are a closed set

An allocated hour carries exactly one category, from:

work · care · learning · sleep · health · personal

The set is closed and normative. An open vocabulary would make two users' records incomparable, which costs the mechanism most of its value to a grant body, an auditor or anybody aggregating across people; and a user-defined vocabulary is what the label of section 4.2 is for.

Six is fewer than the first draft of this section carried, and the cuts matter more than the survivors.

care is first-class, covering care of children, of the elderly, of the sick and of a household. The most common objection to quantified time is that it renders visible only the work that was already counted, and a vocabulary with no word for unpaid care would make that objection correct by construction.

sleep is its own category, and is not folded into rest. It is around a third of the budget, it is involuntary, and it is not substitutable for anything. Merging it with discretionary rest destroys the informativeness of both, because a combined total of sixty cannot be read — fifty-six and four is a different life from fifty and ten, and the same number. Nor does merging buy any privacy: section 6.2 establishes that position is disclosed by any disclosure at all, so anybody shown a week's placements sees the nightly block whatever it is labelled. The category is a noun and not a target; section 2.2 permits no bound but arithmetic, and nothing here recommends an amount.

There is no volunteer and no civic. Both name a relationship to a beneficiary rather than a kind of activity, and that relationship is the subject field of section 4.3. Three hours at a food bank is work with subject @foodbank, which is also the form a grant body can actually use, since it identifies the organisation rather than the sentiment. Keeping civic while refusing volunteer would not have survived its own reasoning.

There is one residual and not two. personal is discretionary time — leisure, meals, company, doing nothing — and there is no other beside it, because two residuals are not reliably distinguishable and a closed vocabulary whose members users cannot tell apart produces comparability that is not real. Where nothing fits, the honest answer is untracked, which is candid about carrying no information where other would pretend to carry some.

health is the holder's own — treatment, recovery, exercise — as distinct from care, which is somebody else's.

4.2 Labels are the user's own

An hour MAY carry a label: free UTF-8, up to 64 bytes, chosen by the user. Project Alpha, the Tuesday deposition, Mum. Labels are never normative, never compared across users, and never interpreted by a client beyond grouping a user's own hours.

The separation matters at disclosure. A category is coarse enough to be worth sharing widely; a label is often the single most sensitive thing in the record, and section 6 makes them independently disclosable for that reason.

4.3 Subjects name who an hour was for

An hour MAY name a subject: a fully-qualified handle, per BRC-169 section 2.4. This is the beneficiary or counterparty — the client the work was for, the organisation volunteered at, the person cared for.

Naming a subject transfers nothing and grants nothing. It does not disclose the hour to the subject, does not oblige them, and does not appear anywhere they can see until the holder discloses it to them. A subject who has been disclosed to may countersign, per section 5.3.

Because a subject is a handle, BRC-169 section 2.3's confusability rules apply exactly as they do to a payee: a homoglyph in a subject field misattributes a life's work to a stranger, and a client MUST resolve and display subjects in fully-qualified form.

5. Allocation To and For Other Handles

This section answers the question the mechanism most often prompts, which is whether hours can be given away. They cannot, and three adjacent things that can be done are frequently mistaken for it.

5.1 Hours are not transferable

No mechanism in this document moves an hour between handles, and a client MUST NOT provide one. There is no send, no gift, no pooling, no team account that hours accrue to, and no market.

The reasons compound. Conservation dies first: an hour that can be received is an hour that can be accumulated, and a handle holding four hundred hours in a week has destroyed the only property here that does not rest on trusting somebody. The record stops being about a life: a transferable hour measures purchasing power, and a wealthy handle would show a fuller week than a hard-working one. And it creates a thing that can be demanded: an employer who can ask for your money can be refused more easily than one who can ask for your hours, because the hours are visibly there and visibly yours. The refusal is at the level of the mechanism rather than of convention because a rule this important that a client could quietly relax is not a rule.

An organisation wanting a team's total does not pool hours. It collects disclosures from each member and adds them up, which produces the same figure and keeps every hour attributable to the person who lived it.

5.2 Directed allocation is not transfer

An hour that names a subject (section 4.3) remains entirely the holder's. work, labelled Project Alpha, subject @client@lkup.net, is the ordinary billable hour: it counts against the holder's 168, appears in the holder's record, and is disclosed at the holder's discretion. The subject's own week is untouched.

This is the primitive the freelance and volunteer cases actually need, and conflating it with transfer is what makes people ask for transfer.

5.3 Countersignature is what turns a claim into evidence

A subject who has been disclosed an hour naming them MAY countersign it: a BRC-52 certificate, with the subject as certifier, over the hour's leaf digest and the commitment root it belongs to.

This is the mechanism's answer to its own central weakness. Nothing in sections 2 or 3 establishes that any work was done; they establish that a bounded, timed, tamper-evident claim was made. A countersignature adds a second party's signed agreement, which is a different and much stronger object — and a client MUST render a countersigned hour distinguishably from an uncountersigned one, because presenting them alike lets the weaker claim borrow the credibility of the stronger.

Three limits, stated because a countersignature invites over-reading. It attests agreement, not occurrence: a counterparty can be mistaken or complicit. It is voluntary, and its absence means nothing — many honest hours will never be countersigned, and a client MUST NOT present a missing countersignature as doubt. And it is a public claim by its signer, subject to BRC-169 section 10's attribution rules, which is what makes it worth anything and also what makes signing one a considered act.

A countersignature also discloses the relationship. A certificate by @client over an hour of @alice's says that the two deal with each other, to anybody who sees it, which is more than either party disclosed by the allocation itself. Where that matters the countersignature should be delivered to the holder and not published, in which case it is evidence the holder can produce on request rather than a public fact — weaker as a signal, and the same strength where it is actually used.

5.4 Delegation is BRC-169 section 9

An assistant, bookkeeper or agent MAY allocate on a holder's behalf under a delegation certificate, within its scope and expiry. Delegated allocation counts against the holder's own budget, is attributable to both parties, and MUST be marked as delegated wherever the hour is disclosed. A delegate cannot commit a week the holder could not commit, and cannot countersign on the holder's behalf as a subject.

5.5 A request is a proposal, never an instruction

A counterparty MAY ask a holder to allocate an hour, correct one, or countersign one. Such a request is a message. A client MUST NOT execute it, MUST NOT pre-fill a commitment from it without the user acting, and MUST render it as the counterparty's text, per BRC-218 section 2.4. A mechanism whose records could be written by whoever asks loudest would be a worse timesheet than the one it replaces.

6. Disclosure

6.1 Nothing is legible by default

A commitment discloses no allocation to anybody: not to the public, not to the subject of an hour, not to the ecosystem host, and not to the overlay that indexes it. Every disclosure is a deliberate, signed, recorded act by the holder.

6.2 A disclosure is a slice and a field mask

Two independent choices decide what a recipient learns.

The slice selects hours: a set of weeks, optionally narrowed to given categories, labels or subjects. The field mask selects what is revealed about each hour in the slice, from:

Position is disclosed by any disclosure at all, and this is the property implementers most often miss. Revealing that hour 34 is allocated reveals that the holder was working at 10:00 on Tuesday, which over a few weeks establishes a schedule, and a schedule discloses employment, observance, caring responsibilities and health without a single label being shared. A client MUST state this at the point of granting, in those terms. "Category only" sounds narrow and is not.

Consequently the useful aggregate — how many hours, without which — is not provable by this construction. A holder can assert a total, and a recipient can verify a total only by receiving the underlying positions. Section 10 records zero-knowledge aggregation as the obvious extension and does not specify it; an asserted total MUST be labelled as asserted, and MUST NOT be rendered in the visual language of a verified one.

6.3 The grant

{
  "protocol": "metanet-time-grant",
  "version": 1,
  "grantor": "@crumbs@nexus.app",
  "grantee": "@client@lkup.net",
  "weeks": ["2026-W31", "2026-W32"],
  "categories": ["work"],
  "labels": ["Project Alpha"],
  "fields": ["cat", "sub", "lab"],
  "expires": 934560,
  "signature": "<DER, hex>"
}

The grant is signed over its RFC 8785 canonical form and delivered to the grantee's messagebox (BRC-169 section 7). It travels with an encrypted payload carrying, for each hour in the slice, its index, the revealed field values and their salts, the withheld fields' commitments, and the Merkle path to the root.

The grantee verifies without asking anybody: recompute each revealed field commitment from value and salt, combine with the withheld commitments to rebuild the leaf, walk the path to the root, and compare against the root in the on-chain commitment for that handle and week. Nothing in this path trusts the grantor, a server, or an overlay. The grantor cannot show a recipient an hour that is not in the tree they committed before the conversation began.

expires is a block height after which the grantee's client stops presenting the disclosure as current. It bounds staleness, not access, for the reason section 6.5 gives.

6.4 Standing disclosure

A grant MAY cover future weeks, in which case the grantor's client delivers each week's payload as that week is committed. This is what an ongoing client relationship needs, and it is materially more dangerous than a one-off: it is easy to grant, easy to forget, and the thing it discloses grows every week without anybody deciding again.

A standing grant MUST therefore appear in the holder's standing-authority list (BRC-218 section 5.19), with its slice, its fields and its expiry, and a client SHOULD require it to carry an expiry rather than defaulting to none.

6.5 Revocation is honest about what it cannot do

A holder MAY revoke a grant. Revocation stops future weeks under a standing grant and marks the disclosure as withdrawn in the grantee's client, and it does not and cannot retrieve what was already disclosed. The grantee holds salts and values; they can be copied, and no protocol reaches them.

A client MUST say this plainly at the moment a grant is made — not in a policy, not on revocation, but where the user is deciding. The failure mode this prevents is specific and common: a person shares broadly on the understanding that they can pull it back, discovers they cannot at the moment they most want to, and the interface told them the truth only afterwards.

7. The Interface

This document usually leaves display to clients. It does not here, because a time-tracking interface that is tedious will not be used, and one that is unclear about disclosure will hurt somebody.

Most of what follows is a SHOULD, and deliberately. A specification earns the right to mandate an interface only where getting it wrong breaks interoperability or causes a harm that cannot be undone, and most of this section is neither — it is what a client that wants to be used will do anyway. Two are requirements: 7.5, because over-disclosure cannot be reversed and the preview is what prevents it, and 7.8, because a scored record stops being evidence and the incentive to game it falls on the person the record is about.

7.1 The week is a grid, not 168 objects

A client SHOULD NOT require a user to act on hours one at a time. The natural surface is the week as a 24-by-7 grid, and allocation is a gesture across it: select a span, choose a category, done. Filling in a working week should be a handful of actions and not forty.

An hour is small enough that this matters. Any interface that costs more than a few seconds per day will be abandoned inside a fortnight, and an abandoned record is worse than none, because a partial week looks like a light week.

7.2 Patterns first, corrections after

Most weeks resemble the last one. A client SHOULD let a user define recurring patterns — the working day, the standing commitment, the usual night — and apply them to a week in one action, leaving the user to correct the exceptions. This inverts the labour: the user describes their life once and then edits the deviations, rather than re-describing it weekly.

A pattern is a client-side convenience. It commits nothing until the user commits the week, and a client SHOULD NOT auto-commit a patterned week without the user seeing it, or the record becomes a description of an intention.

7.3 The budget is always visible, and untracked is neutral

Allocated, untracked and remaining hours are shown whenever a week is edited. Conservation is the point of the mechanism and it should be legible rather than discovered at the moment a commit is refused.

Untracked hours SHOULD NOT be rendered as a deficit, a gap, an incompletion or anything else that reads as a reproach. No progress bar toward 168, no "you have 43 hours unaccounted for". Most people will track one part of their life and not the rest, and that is a correct use of this document rather than a partial one.

7.4 Lateness is shown before committing

Per section 3.4, and stated here as an interface requirement because it is where it takes effect: the user sees what lateness their allocation will carry before they commit it, and sees it in the terms a verifier will — "this will be recorded as logged 6 days after the fact" — rather than as a timestamp they must subtract.

7.5 Disclosure is previewed as the recipient

A client MUST be able to render a holder's record as a named grantee will see it, before the grant is signed, and MUST offer that preview as part of granting rather than as a setting elsewhere.

This is the single most important requirement in this section. Access-control lists are notoriously hard to reason about forwards: people can answer "what will my client see?" and cannot reliably answer "which categories has my client got?" — and the second question is what every permissions screen asks. Rendering the record from the recipient's side converts a rule into a page, and the user checks it the way they would check a letter before sending it.

The preview MUST show what is not included as well as what is, since the risk being guarded against is over-disclosure and an omission is invisible in a page that shows only what is present.

7.6 A grant is an act, not a toggle

Granting passes a structured confirmation naming the grantee in fully-qualified form, the slice, the fields, the expiry, and the irreversibility of section 6.5. It is recorded, it appears in the standing list of section 6.4, and it can be found later. A permissions switch that silently begins disclosing a category to a handle is not adequate, whatever it is labelled.

7.7 The recipient sees the shape of what they were given

A grantee's view SHOULD show the slice and fields they hold, who granted them, when, the expiry, and — for each hour — its lateness and whether it has been amended or countersigned. It SHOULD also show what the grant does not cover.

The symmetry with 7.5 is the point. Both parties should be able to see the same boundary from their own side, because most disputes about a disclosure are disagreements about its edges rather than its contents.

7.8 No scores

A client MUST NOT present streaks, completion percentages, productivity scores, comparisons against other users, or leaderboards, and MUST NOT rank categories against one another.

This is a requirement rather than advice because the mechanism is unusually vulnerable to it. The subject writes the record, so any score the client offers is a score the user can raise by writing differently, and the cheapest way to raise every such score is to make the record less true. A measure that becomes a target stops being a measure; here it also stops being evidence, which is the only thing the record was for.

7.9 Correcting is normal

Amendment (section 3.3) SHOULD be as easy as allocation and SHOULD NOT be presented as an exception or an admission. A client that makes correction feel like a confession produces records people leave wrong.

8. What This Does and Does Not Prove

A verified record establishes four things: a specific handle committed to a specific week's allocations; the commitment was confirmed at a specific height, from which lateness follows; the allocations fit within 168 hours and no hour is claimed twice; and the disclosed hours are the ones committed, unchanged, or changed with the change visible.

It bounds a handle's week, not a person's. Conservation is per handle, and BRC-169 handles are assigned by an ecosystem rather than issued against a scarce resource, so somebody willing to hold three handles has three budgets. Nothing here detects that, and nothing here could: the mechanism has no notion of a person, only of a key that signs. What survives is narrower and still useful — a counterparty paying @alice verifies against @alice, and no arrangement of other handles adds an hour to that week or lets the same hour be sold to two of her clients. A relying party who needs the stronger claim needs an identity assurance this document does not provide, and section 5.3's countersignature is the nearest thing to it, since a counterparty who agrees to an hour is agreeing about a specific handle they chose to deal with.

It establishes nothing about the world. It does not show the activity happened, that it took an hour, that it was done competently, or that it was done at all. A person can allocate forty hours of work to a project they never opened, and this document will faithfully record that they claimed so, promptly, within budget.

That is a narrower claim than the category of product this replaces usually makes, and it is worth being precise about why it is still worth having. A timesheet is unbounded, undated in any way its recipient can check, and silently editable. A record here is bounded by arithmetic the recipient can do, dated by a chain the recipient can read, and editable only in public. The dishonest user has been moved from "can claim anything" to "can claim a false thing, within a fixed budget, at a visible time, permanently" — which does not stop them, and does raise the cost and the traceability of every lie considerably.

Countersignature (section 5.3) is the only mechanism that adds a second party's word, and it adds exactly that.

9. When Not to Use This

Where the reader can compel the writer. This is the primary hazard and it is not cryptographic. An employer who can make disclosure a condition of employment has converted a voluntary record into surveillance with extra steps, and every privacy control here becomes theatre because the coerced party will grant whatever is demanded. Nothing in a protocol prevents this. What partially mitigates it is that untracked is the default and a partial record is valid, so a person can hold a record of one part of their life without implying anything about the rest — a property a client destroys the moment it renders untracked hours as missing, which is why section 7.3 discourages it.

That mitigation is thinner than it first appears, and the limit is worth stating rather than leaving to be discovered. A commitment is an on-chain object, so which weeks a handle committed is public even though their contents are not. A reader who can compel disclosure can therefore see the gaps and demand them, and the answer "I did not record that week" is checkable against the chain. Untracked hours are private; uncommitted weeks are not.

Where the work is not hourly. Creative, research and management work is badly described by hours, and a record of it will be either false or unflattering. The measure will not become more accurate by being cryptographic.

Where the record will be read as a character reference. Time allocation is a description of circumstances at least as much as of choices. Illness, caring, disability, poverty and precarity all show up as a differently shaped week, and a reader treating shape as merit will misread all of them. A client SHOULD NOT provide affordances that invite that reading, and section 7.8 removes the most obvious ones.

Where a summary would do. If the counterparty would accept "about forty hours", the strongest version of this mechanism buys nothing and discloses a schedule.

The mechanism is worth its cost where a specific bounded claim is contested by a specific party who can check it: an invoice, a grant report, an hours-based contract. It is a poor fit for everything shaped like general accountability.

10. Not Specified Here

Zero-knowledge aggregates. Proving "at least forty hours of work in this week" without revealing which hours is the extension that would most improve section 6.2, since it separates the useful figure from the sensitive one. The commitment structure does not preclude it. It is unspecified because it needs a proving system, a circuit and a verification cost this document is not in a position to fix.

Sub-hour granularity. Refused rather than deferred, per section 2.3.

Estate and inheritance. What becomes of commitments and outstanding grants when a holder dies is unaddressed. The commitments persist because the chain does; the salts do not, so an undisclosed record becomes permanently unreadable, which is a reasonable default and not a considered one.

Tokenomic incentives. Deliberately absent. Paying people to keep accurate records pays them to keep records that look accurate, and section 7.8's argument applies with money attached.

Portability to other chains. Out of scope.

11. Relationship to Other Documents

Handles, resolution, messagebox delivery, attestation and delegation are BRC-169; this document defines no addressing and no new certificate type beyond the countersignature of section 5.3, which is an ordinary BRC-52 certificate. The standing-authority list of section 6.4 is BRC-218 section 5.19, and a conversational surface for allocating or granting is a matter for that document, as a custom verb under its section 8; no verb is defined or reserved here. A room may gate on contributed time under BRC-146 by treating a disclosure as the fact a vouch gate reads, and this document neither requires nor endorses that.

Security Considerations

Unsalted commitments publish everything. The category vocabulary is six members; a label vocabulary is small and personal. Salting per field per hour, as section 3.2 requires, is what keeps a published root from being a puzzle solvable in seconds, and it is the single implementation error most likely to be made.

Position is the disclosure. Sharing "category only" for a month of hours shares a schedule, and a schedule is among the most identifying and most sensitive things a person has. Section 6.2 requires clients to say so at the point of granting; an implementation that describes a category-level grant as minimal has misled its user about the main risk.

Existence leaks participation. A commitment on chain says that this handle keeps time records, every week it does so, and at roughly what time it commits them. For most users this is uninteresting; for somebody whose employment or immigration status turns on it, it may not be.

Disclosure is irreversible and revocation is not a remedy. Section 6.5 is a statement about reality, not a feature, and a client that implies otherwise has caused the harm it appears to prevent.

Multiple handles multiply the budget. The 168-hour bound holds per handle and the cost of a second handle is whatever an ecosystem charges for one, which is usually nothing. An aggregate assembled across handles is unbounded, so a relying party summing disclosures from several handles believed to be one person is relying on that belief and not on this document. Section 8 states the limit; there is no mitigation in the protocol.

Coercion defeats every control here. The threat model of a person who can be fired, evicted or deported for withholding a disclosure is not addressed by consent-based access control, because their consent is available on demand. This document limits the blast radius — partial records are valid, untracked is the default, grants are per-slice — and does not solve it.

Countersignature is a public claim by the signer. Somebody who countersigns an hour has attested to another person's account of their own week, attributably. Signing them casually is how a signature stops meaning anything.

A delegate writes the principal's record. Under section 5.4 a compromised or careless delegate can allocate anything within scope, and the record will attribute it to the holder as well as to the delegate. Scope and expiry are the only limits and should be narrow.

Aggregation across grantees. Two recipients holding different slices can combine them, and neither needs the holder's consent to do so. A holder who discloses work positions to an employer and care positions to a benefits assessor should assume a party seeing both learns more than either was granted.

Superseding chains can be broken deliberately. A holder who wishes to obscure an amendment can publish a correction whose replaces points at a commitment they never publish. Section 3.3 requires verifiers to reject a chain they cannot resolve, which converts the attack into a visible refusal rather than a silent substitution.

Implementations

None. This document is a specification ahead of its implementation, and says so rather than describing a reference client that does not exist. Section 7 is therefore its least evidenced part — nine subsections of interface guidance with no client behind them, which is why almost all of it is a SHOULD rather than a requirement.

What is verified is the construction. example.py computes every value in the Test Vectors from the rules in sections 3.1 and 3.2, and verify_vectors.py parses them back out of this document and checks them: thirty checks, including that a single-field disclosure walks to the published root, that substituting the disclosed value does not, and that the commitment signature verifies against the canonical form and fails against a modified one.

A minimal useful implementation is smaller than the document suggests: sections 2, 3 and 4 produce a committed, conserved, timed record, and section 6 with the cat field alone produces a disclosure a counterparty can verify. Sections 5.3, 6.4 and 7.2 are what make it pleasant to live with. Section 7.5's recipient preview is the one interface requirement that should not be deferred, because the harm it prevents is the harm that cannot be undone.

Test Vectors

Every value below is computed from the rules in sections 3.1 and 3.2 by example.py, and verify_vectors.py parses them back out of this document and checks them. An implementation producing a different root from the same week and weekSecret has a construction bug, and its disclosures will not verify against anybody else's commitment.

The example week

@crumbs@nexus.app records 2026-W31. Four hours are allocated and the remaining 164 are untracked:

The identity private key is SHA-256("BRC-168 EXAMPLE / crumbs identity") reduced mod n, so an implementer can regenerate it:

Section 3.2 derives weekSecret under BRC-42 from the identity key. This vector fixes it to the value above, so that what is being checked is the commitment construction rather than the key derivation — a reader wanting the derivation checked has BRC-169's Appendix A for that.

Field commitments and a leaf

For hour 34, with salt(i, f) = HMAC-SHA-256(weekSecret, uint8(i) ‖ f) and c(i, f) = SHA-256(salt(i, f) ‖ value):

The leaf is SHA-256 over the four commitments in the fixed order cat, sub, lab, note:

leaf(34) = a3373138d80ef7373447a0baa9c85d3efda7b0c44542debc75074b9c213b6ff6

An untracked hour commits to four empty values and is the same shape, which is what keeps the week's shape hidden — nothing about leaf(0) says it is empty:

leaf(0)   = f6b6638b2364470863039dc26bf8a09f548274d186b23ed88deff0b98b29d62a
leaf(168) = bbfa6d97bf45341cf4c534734c94e1ec296e0b1a8e6e5b1f3f38bdd993a1fec5      (filler, per 3.2)

The root

256 leaves, combined pairwise as SHA-256(left ‖ right) and halved until one node remains, giving a tree of depth 8:

root = 61c9aa87b889634c06c691db9565a6231f98426fc2b9eef5bf62ca2d6444f6e3

A disclosure, verified

A grant covering hour 34 with fields: ["cat"] conveys the revealed value and its salt, the three withheld commitments, and eight sibling hashes:

value             work
salt(34,"cat")    fc9c49f3ddc03b620a83c925ad87a31f83bfb7aaf675a6b55f1af55b89b1c952
c(34,"sub")       24e06626f60ab74db6670d62c8343c91892059acc1968bce2af535f59b025029
c(34,"lab")       e0b2b709e0ac8131e3bc3d433a846c42a040b11f11882e9db33d7b992bd45c1b
c(34,"note")      986a51909d6c007b1ac819e314fef6cb4ae8e8b60a0f472e18b7ec04e709af32
sibling 0         345709bbfea57c9f7257c350b03d190f2c443c9780c50a7785ede177476e367f
sibling 1         fc5f89882419f20d9f0f3d7687a44830da69256c8c829dd1146b6d3e172ae9ba
sibling 2         c651578f7bf01137d344ec8c69260c065ebabf55eb0aef771e1743b4d926351f
sibling 3         37ca04fd62686e120c1f188c1fafab4e3977b2d6e6870adec4ec9c639a472cc8
sibling 4         ed35f08d7f13ea5b21d894532a4c1c0d7141dcc0801fcca23821e4083bb3dda2
sibling 5         651c043ac1466eb5e4a0366614c4749d9f2a2b200507f99cb241ab21948e43b0
sibling 6         b1e28243a20336cd326651036b331d2dfd60ab1189aa10954ca1579b735f9722
sibling 7         709f4d320a6d42fb1b75801462117ee4c0f3993b221a58f39542b1a801cec6ed

The grantee recomputes c(34,"cat") from the value and salt, rebuilds leaf(34) from the four commitments, then walks the siblings — combining as SHA-256(node ‖ sibling) where the running index is even and SHA-256(sibling ‖ node) where it is odd, halving the index at each level — and arrives at the root above. Nothing in that path trusts the grantor.

Note what the grantee learns without being told: index 34 is Tuesday 10:00 UTC. That is section 6.2's warning in its concrete form, and no choice of fields avoids it.

The commitment object

{
  "protocol": "metanet-time",
  "version": 1,
  "handle": "@crumbs@nexus.app",
  "week": "2026-W31",
  "counter": 1,
  "root": "61c9aa87b889634c06c691db9565a6231f98426fc2b9eef5bf62ca2d6444f6e3",
  "replaces": null
}

RFC 8785 canonical form, 188 bytes:

{"counter":1,"handle":"@crumbs@nexus.app","protocol":"metanet-time","replaces":null,"root":"61c9aa87b889634c06c691db9565a6231f98426fc2b9eef5bf62ca2d6444f6e3","version":1,"week":"2026-W31"}

Its digest, which is what a superseding commitment carries in replaces per section 3.3:

711b44f9167df07893cf4527c915e702e4ede695c5fcf83c0359f35124cc026f

And the signature over the canonical form by the identity key above:

3044022052b42b2196bafef93f46c0e760dbc2a705767bab362ff855963c2c6c3442ddfe022030335ee9937e71c4e64a923c7e94f537482aefbb9ef8ccc86f37451280a2c823

Conservation is structural, so there is nothing to reject

Section 2.2's bounds cannot be violated by a well-formed commitment, and the vector for them is the absence of one. There are exactly 168 hour-leaves; a 200-hour week has nowhere to put the extra 32. Hour 34 has one leaf, so it cannot carry two allocations. A calendar day is 24 leaves. An implementation looking for a rejection path here has misread the construction — the bound is a property of the tree's shape, not a check performed on it.

What a verifier does check is that the tree has 256 leaves and the claimed index is below 168. A commitment whose root was computed over a larger tree would admit a 169th hour, and that is the only way the bound could be evaded.

Conclusion

The useful thing here is not the record. It is the bound.

A week has 168 hours whether or not anybody is counting, and a claim about how those hours were spent is the rare kind of claim whose upper limit two strangers already agree on. Everything in this document is an attempt to make that agreement usable: to fix the claim at a moment a chain can attest to, to keep it unreadable until its author chooses otherwise, to let the choosing be per-recipient and per-field, and to leave a second party a way to say they agree.

What it deliberately does not do is more important than usual. It does not make time transferable, because a purchasable hour measures a wallet rather than a life. It does not enforce a shape on anybody's week, because a specification has no standing to have an opinion about sleep. It does not score, rank or congratulate, because a record its subject writes will bend toward whatever it is scored on. And it does not claim to prove that work was done, because it cannot, and a mechanism that overstates its evidence is worse than the honour system it replaces — the honour system, at least, is understood by everyone using it to be exactly as good as the person on the other side.

What remains is modest and, for a small number of real disputes, sufficient: a bounded, timed, tamper-evident, selectively disclosed account of where somebody says their hours went.

References

• BRC-2: Encryption and Decryption
• BRC-3: Digital Signature Creation and Verification
• BRC-42: BSV Key Derivation Scheme
• BRC-48: Pay to Push Drop
• BRC-52: Identity Certificates
• BRC-87: Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
• BRC-169: Universal Handle Addressing and Resolution for the Metanet
• BRC-146: Access Gates for Metanet Rooms
• BRC-218: Chat-Native Command Grammar for the Metanet
• RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
• RFC 8785: JSON Canonicalization Scheme (JCS)
• W3C Verifiable Credentials Data Model
• E. Cahn, Time Dollars (1992); Ithaca HOURS (1991) — time as a transferable unit
• E. Weyl, P. Ohlhaver and V. Buterin, "Decentralized Society: Finding Web3's Soul" (2022)
• E. P. Thompson, "Time, Work-Discipline, and Industrial Capitalism", Past & Present 38 (1967)
• S. Zuboff, The Age of Surveillance Capitalism (2019)
• C. Goodhart (1975), as commonly stated by M. Strathern (1997): "When a measure becomes a target, it ceases to be a good measure"