The Miloryn paper

A measure you choose.
A report—not a proof.

The goal state, corrections, public history and the difference between a recorded number and a real-world result.

The goal state

A title, a target,
and your current number.

MilorynProgress stores one current Goal per wallet: a plain-text title, a uint32 target, a uint32 current value and an incrementing uint64 revision. goalOf(account) is public even though the storage mapping is private in Solidity; private storage is not confidentiality.

State transitions · illustration, not live progress

Set a goal

Public title + positive target

Current becomes zeroRevision increases by one

Record a changed value

Zero through your target · up or down

Current becomes your reportRevision increases by one
A new goal replaces current state and resets the number. Historical public events remain. No real-world completion is verified.

Making updates

The sender changes
only their own record.

setGoal(title,target) accepts a title of one to sixty-four UTF-8 bytes and a target from one to one million. It replaces the sender’s current title and target, resets current to zero and increments revision. The interface trims outer whitespace and rejects control characters for readability; the contract itself enforces byte length and target bounds.

recordProgress(current) requires an existing goal, a value no higher than the target, and a change from the current value. Zero is valid, and a lower correction is valid. It increments revision and does not infer why the value changed.

There is no author parameter, administrator, token, reward, custody or payment logic. A different wallet has its own record. Reaching a target grants no verified status or entitlement.

Revision boundaries

A revision is a record.
Not an atomic review lock.

Neither write method accepts an expected revision. The frontend compares the exact reviewed title, target, current value and revision again before submitting, but another pending transaction from the same wallet can still be mined in between.

GoalSet records exact account, title, target and next revision; ProgressRecorded records account, current value and next revision. Confirmation checks the corresponding event and every parameter, receipt hash/status/from/to and log address. A mismatch is reported as a submitted transaction requiring inspection—not falsely as if nothing happened.

Public data & limits

Be deliberate
about a public title.

Titles, targets, progress, wallets and historical events would be public on a deployed network. Replacing the current goal does not erase events. Do not enter confidential work, personal routines or sensitive context. A wallet is not a verified person.

The contract does not observe work, validate evidence, count documents or prove completion, quality, attendance, identity or eligibility. Both entry points are nonpayable; a future write consumes native network gas, with no application fee, tokens or payouts.

Current readiness

Prepared locally.
Not deployed.

This same worktree contains the long website, independent progress room, project paper, original dedicated contract, local temporary-chain tests and unsigned deployment preview. Local practice is memory-only, clearly labelled and never a fake transaction receipt.

Default network, address and runtime hash are unset; public reads and writes are disabled. Future reviews verify account/chain and runtime code, current goal, buffered gas, fee caps and balance, expire after sixty seconds, and recheck expiry after all slow RPCs. Sending explicitly binds the reviewed chainId, account, zero value, gas limit and fee caps.

Input, mode, reconnect and wallet events invalidate stale asynchronous reviews. No deployment or signature was approved here. The immutable contract has no proxy/upgrade key; new rules require a new reviewed address and explicit migration. Local testing is not an independent security audit.

Try local progress