Local MOVE
Ordinary transfer is device-to-device. No transaction registry, global consensus, or hosted bearer custody is required in the MOVE path.
OBJECTS MOVE. AUTHORITY STAYS SINGULAR.
BEARER OBJECT PROTOCOL · PRE-MVP v0.6
Bearer Object
Protocol
Singular digital authority without a global transaction ledger.
A protocol for transferable, application-defined cryptographic authority. The payload can be copied. The live authority cannot legitimately fork into two conflicting irreversible outcomes.
See the MOVE state machine →Singular Authority
One live predecessor should not be able to produce two conflicting valid successor or terminal certificates.
Optional Recovery
Recovery is not hidden inside the bearer core. Each recovery profile makes its extra trust, state, privacy, and liveness costs explicit.
THE CORE DISTINCTION
Unique(Authority)
≠
Unique(Data)
Encrypted payload
freely copyable
Authority state
one live UAP instance per predecessor state
Proof material
portable and independently verifiable
ARCHITECTURE
Small bearer core.
Explicit control planes.
BOP separates the local authority state machine from recovery and global security policy. Those auxiliary systems matter, but they are not transaction consensus.
APPLICATIONticket / licence / access
credential / capability
credential / capability
BOP COREUAP + typed transitions
MOVE / USE / PRESENT
DELEGATE / CONSUME
MOVE / USE / PRESENT
DELEGATE / CONSUME
HOSTILE STORAGEencrypted payload
cloud / disk / USB / NAS
cloud / disk / USB / NAS
OPTIONAL RECOVERYBearer / Issuer / Challenge
Closure / Registered / Managed
Closure / Registered / Managed
GLOBAL SECURITY POLICYhardware eligibility
revocation / policy epochs
crypto-suite policy
revocation / policy epochs
crypto-suite policy
TYPED OPERATIONS
Authority is not a generic signing key.
The UAP exposes protocol operations, not an unrestricted sign(hash) oracle. Each operation has a different authority consequence.
Create exactly one successor authority and retire the predecessor.
Exercise a repeatable application capability without moving root authority.
Prove a permitted claim or entitlement bound to the current root state.
Create constrained subordinate capabilities tied to the root state and explicit limits.
Irreversibly convert authority into a terminal certificate for one-time rights.
CRASH-SAFE MOVE
Commit only after the successor is durable.
MOVE uses a recipient-persisted pending successor. The sender is not consumed until the intended recipient has durably stored the exact pending state.
TBᵢ = { TCᵢ, RETIREᵢ }
01
PREPARE
The sender fixes the exact successor key, state commitment, policy epoch, and recipient eligibility evidence.
RECOVERY
A profile choice.
Not a free property.
Pure bearer authority and recoverability pull in opposite directions. BOP keeps recovery outside the core and makes the trade-offs explicit.
PREFERRED PEER-RESALE PROFILE
Closure-Recoverable
Ordinary MOVE stays device-to-device. Each retired predecessor can be lazily closed with one opaque record, preventing that historical state from becoming a recovery origin.
- MOVE
- Device-to-device + lazy closure
- RECOVERY
- Current unclosed state recoverable
- PRIMARY COST
- One opaque write per transfer
CLOSURE-RECOVERABLE
WHY CLOSURE MATTERS
One opaque write.
Three jobs.
- Recovery nullifier. A closed predecessor can never be used as the basis of recovery again.
- Blinded successor commitment. The closure service need not learn the successor key or current owner.
- Temporal anchor. A quorum-signed receipt can prove the transition commitment existed before a later catastrophic compromise.
RECOVERY FRESHNESS
Fresh verifiers get the stronger guarantee.
Recovery creates a verifier-relative property: a stale verifier may still accept a branch that a current recovery view would reject.
Bearer-only
No recovery freshness.
Bounded staleness
Cached signed recovery-finalization snapshot.
Fresh recovery
Current set or privacy-preserving lookup.
Profile-specific
Application online issuer / registered check.
APPLICATION SPACE
When exclusive control matters, but unrelated events do not need total ordering.
Licences
Tickets
Access capabilities
Credentials
Device permissions
API rights
EXPLICIT LIMITS
No magic.
The specification names the boundaries instead of burying them in assumptions.
01No global ordering of unrelated transitions.
02No globally shared smart-contract state or execution VM.
03No native currency, protocol balance system, price mechanism, or exchange.
04No guarantee that plaintext already revealed can later be made uncopyable.
05No claim that current secure hardware provides physics-level unclonability.
06No guarantee that a verifier with stale recovery information rejects a superseded branch.
FAQ
Frequently
Asked
Questions
Short answers drawn from the frozen pre-MVP specification.
01Does BOP use a blockchain?
No. BOP is not a cryptocurrency protocol, a global ownership database, or “a blockchain with consensus removed.” Its core property is local output exclusivity.
02What is actually singular?
The authority state. Encrypted payload and metadata may be copied; the unique element is the authority state capable of producing valid protocol operations.
03What happens after MOVE?
MOVE atomically retires the predecessor's transfer and operational authority. After COMMIT, the predecessor must not answer fresh USE, PRESENT, or DELEGATE challenges.
04Is recovery part of BOP Core?
No. Pure Bearer has no recovery. Recoverable deployments select an explicit profile and accept the additional external state, trust, privacy, and liveness costs.
05What does Closure-Recoverable add?
A lazy opaque closure record for each retired predecessor. It blocks stale recovery and can also provide blinded successor commitment, equivocation evidence, and a temporal anchor.
06What are the hard limits?
Stale verifiers can accept superseded branches; catastrophic hardware compromise can invalidate unanchored history; and recoverable terminal consumption requires terminal evidence to reach the recovery decision.
FROZEN PRE-MVP SPECIFICATION · SEPTEMBER 2026