Bitcredit Documentation
E-Bill
Wildcat Mint
Glossary
E-Bill
Wildcat Mint
Glossary
  • E-Bill

    • E-Bill
    • Concepts

      • Roles
      • Bill states
      • General conditions
      • Validation
    • Identity Record

      • Identity record
      • Field description
      • Identity restore and transfer
      • Backing up user material
    • Cryptographic primitives
    • Adding a contact and exchanging data
    • Content of Bill

      • Content of a bill
      • Field description
      • Bill id and keys
      • The bill blockchain
      • Bill example
    • Operations

      • Operations
      • Issue
      • Request to accept
      • Accept
      • Request to pay
      • Pay
      • Sale
      • Endorse
      • Mint
      • Recourse
    • Transport

      • Transport
      • Sharing bills
      • Migration from the DHT
    • Local Build

      • Local build
      • Software installation
      • Configuration
      • Startup parameters
    • User documentation
    • FAQ
    • Glossary

Operations

Fourteen actions can be taken on a bill. Which are available to you depends on two things: the roles you hold in that bill, and the state the bill is in.

These pages describe action validation only, meaning whether an action is possible for a given participant. Whether the data is well-formed is a separate question, covered in Validation.

Every action, by role

ActionWho may take itWrites a block?
Issuethe issueryes
RequestToAcceptthe holderyes
Acceptthe payeryes
RejectToAcceptthe payeryes
RequestToPaythe holderyes
RejectToPaythe payeryes
Payingthe payerno, see Pay
Endorsethe holderyes
OfferToSellthe holderyes
Sellthe holderyes
RejectToBuythe buyeryes
Mintthe holderyes
RequestRecoursethe holderyes
Recoursethe holderyes
RejectToPayRecoursethe recourseeyes

Roles are positions, not accounts. See Roles. One identity holding two roles simply gets both sets of actions.

The conditions behind every row

Almost every precondition in the specification reduces to four states: paid, recoursed to the end, only recoursable and blocked. Rather than restate them on every page, they are defined once:

→ General conditions

Read that page first. Without it the per-action conditions below look suspiciously short, and the reason they are short is that the four conditions do most of the work in combination.

The default rule

Six actions share exactly one precondition, the same one:

The bill can't be blocked, recoursed to the end, only recoursable, or paid.

Those are RequestToPay, Endorse, OfferToSell, and, with one extra condition each, RequestToAccept, Mint, Accept and RejectToAccept. Where a page says "the default rule", it means this sentence.

The three shapes an action has

Reading the operation pages is easier once you notice that all fourteen fall into three shapes:

Requests open a waiting state and set a deadline. RequestToAccept, RequestToPay, OfferToSell, RequestRecourse. Each blocks the bill until it resolves.

Resolutions close a waiting state. Accept, Sell, Recourse, the payment arriving, and every Reject*. Each requires its corresponding request to be the last block and still open.

Transfers hand the bill to someone else without any waiting state at all. Endorse is the pure case; Sell, Mint and Recourse are transfers that happen to resolve a request first.

Terminal outcomes

Three states end a bill's life, and two of them end it for everyone:

  • paid: nothing further, by anyone.
  • recoursed to the end: nothing further, by anyone; only a court can resolve it.
  • only recoursable: ordinary circulation is over; only the recourse actions remain.
Next
Issue