OSS-Singularity/website
OSS-Singularity/website
Watch
5
0
Fork
You've already forked website
 0
Code Issues 2 Pull requests 6 Projects Releases Packages Wiki Activity Actions
website/design/solidity-lab/generated/DeliveryAcceptance.explained.md

2.2 KiB
Raw Permalink Blame History

DeliveryAcceptance — plain-language explanation

Generated by the OSS Singularity contract lab for: Synthetic delivery-and-acceptance example. Synthetic example: placeholder addresses, a digest over the public synthetic artifact, a future deadline. The lab explains signatures; it never requests one from a wallet, deploys anything, or holds funds.

What this contract models

The same shape as the coordination protocol you already use off-chain: a contributor delivers immutable revisions, the coordinator reviews, a revision request records what is missing, and acceptance binds exactly the newest revision before a deadline. On-chain deployment is NOT part of this slice.

Every function and its requested signature

Function Signature you would be asked to sign What it establishes Who may call
recordDelivery(uint16 revision) a call naming the next revision number that the contributor recorded revision N referencing the declared digest contributor only
requestRevision(uint16 revision, string calldata note) a call naming a revision and a note that the coordinator asked for changes on exactly that revision — no state is destroyed coordinator only
accept(uint16 revision) a call naming the newest revision final acceptance of exactly that revision, before the deadline coordinator only

What can fail, and how each failure is named

  • NotContributor / NotCoordinator — role checks at the decision point: nobody reviews or delivers for someone else.
  • DuplicateRevision — revisions only move forward, one at a time.
  • NothingDelivered — reviews need a delivery first.
  • NotNewestRevision — stale revisions are refused, not silently superseded (matched history is not a current delivery).
  • DeadlinePassed — acceptance after the deadline is refused.
  • AlreadyAccepted — acceptance is final; replay adds nothing.

Honest boundaries

This contract holds no funds and defines no payment. A digest proves which bytes were declared, not quality, authorship or availability. Deployment, testnet exercise, or any wallet interaction requires separate, explicit authorization — nothing here signs or deploys merely because it was generated.