# Streembit IoT Service Protocol Version 1.0 — Working Draft 1 — 10 November 2026 Editors: to be added Requires: Streembit Protocol Conventions (forthcoming); Streembit Blockchain Protocol Specification v1.0 ## Abstract The Streembit IoT Service Protocol defines how a provider and a consumer agree a paid Internet-of-Things service and how that service is recorded on the Streembit blockchain. A provider registers devices and publishes offers. A consumer accepts an offer by signing it with a key held on the consumer's own device. The provider submits the signed agreement and every later record to the blockchain and pays the transaction fee; the consumer holds no coins and no account. The record establishes the consumer's entitlement to use a device during an agreed period, carries signed usage reports for metered services, and fixes the amount owed under published rules. Two payment models are supported: a fixed price for a fixed term, and a price per unit of use up to an agreed maximum. In this version payment is made outside the blockchain, in ordinary money or by any other means, and the protocol records it. The result is a record of what was agreed, what was used and what is owed that neither party can alter and that a property owner, a platform, an auditor or the consumer can verify without relying on the provider. ## Status of This Document This is a Working Draft. It contains the front matter and Sections 1 to 4. Sections 5 to 16 and the appendices are not yet written; their headings are listed in the Table of Contents so that cross-references resolve. Everything in this draft is open to change. Comments are sought on the scope, the roles and the duties assigned to each role. The Streembit Protocol Conventions, on which this specification depends for encoding, hashing, keys, signatures and the form of signed messages, do not exist yet. Section 15.2 will state what this protocol requires from them and from the blockchain. This specification states what the blockchain must provide. It is not limited to what any current implementation provides. ## Table of Contents 1. Introduction 2. Conformance 3. Terminology 4. Participants 5. Data Model 6. Messages 7. Operations 8. Lifecycle 9. Access and Payment Rules 10. Properties and Invariants 11. Fund Flows and Accounting 12. Rationale 13. Security Considerations 14. Privacy Considerations 15. Versioning and Extensibility 16. References Appendices: A. Examples; B. Test vectors; C. Revision history; D. Acknowledgements ## 1. Introduction This section is non-normative. ### 1.1 Motivation Connected devices are routinely offered as paid services: a door lock that admits a hotel guest or a tenant, a charger that delivers energy to a vehicle, a machine rented by the hour. Today the record of such a service lives in the provider's own systems. The consumer, and anyone else with an interest in the service, has to take that record on trust. Earlier attempts to put these services on a blockchain required the consumer to hold and spend a crypto-asset. That requirement, more than any technical limit, kept them from use. This protocol does not make it. The consumer pays the provider as they would for any other service, and the provider carries the cost and the mechanics of the blockchain. What the blockchain contributes is the record. The agreement is signed by the consumer with a key the provider does not hold. Usage can be signed by the device itself. The amount owed is computed from those signed inputs by published rules. Once recorded, none of it can be changed. This is of use wherever someone who does not control the record has to rely on it: the owner of a property managed by another company, a platform that lists many providers, an auditor, or a consumer in a dispute. ### 1.2 Scope This specification covers: - the registration of devices and the publication of offers by a provider; - the service agreement between a provider and a consumer; - the consumer's entitlement to use a device, and how it is established from the record; - usage reports for metered services; - the calculation of the amount owed, including after cancellation or interruption; - the record of payment and refund. Out of scope: - The communication between a gateway and a device, such as Zigbee, and the internal design of a gateway. - The payment itself. In this version payment takes place outside the blockchain; Section 15.3 describes the planned extension. - Operation without access to the blockchain. Internet connectivity is assumed. - Adjudication of disputes and enforcement of what is owed. - Verification of the identity of a provider or a consumer, and of the existence or condition of a device. - Consensus, transaction processing and the duties of Accountable Nodes and validators. ### 1.3 Overview A **provider** offers services on **devices** it operates through a **gateway**. A **consumer** uses an **application** on their own device. Every service follows the same course: ```text register device ─▶ publish offer ─▶ consumer signs acceptance ─▶ agreement recorded ─▶ service window: entitlement in force, usage reported ─▶ agreement closed: amount owed fixed ─▶ payment and refund recorded ``` *A hotel door lock.* A hotel registers the lock of room 12 and publishes an offer: 100 euros a night, half refunded if cancelled less than 24 hours before arrival. A guest chooses three nights. The guest's application shows the terms and signs the acceptance with the guest's key. The hotel submits it, and the agreement is recorded. The guest pays the hotel by card, and the hotel records that it was paid. On arrival the guest's phone asks the gateway to open the door. The gateway checks that the phone holds the guest's key, looks up the entitlement in the record, and opens the lock. After the third night the entitlement ends, the agreement is closed, and the record shows 300 euros owed and paid. *A charger.* A provider registers a charger with the charger's own public key and publishes an offer: 0.40 euros per kilowatt-hour, at most 30 euros. A driver accepts. The charger signs its meter reading at the start, 1,000 kWh, and again as the session proceeds; the last reading is 1,012 kWh. The agreement is closed with 4.80 euros owed. Anyone can check the charger's signature on the readings and recompute the amount. ### 1.4 Relationship to other specifications The Streembit Protocol Conventions define the encoding, hashing, keys, signatures, signed-message form and contract-call behavior that this specification uses and does not repeat. The Streembit Blockchain Protocol Specification defines the blockchain, its transactions and fees, and the Accountable Nodes and validators that operate it. ## 2. Conformance ### 2.1 Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ### 2.2 Normative and non-normative content As well as sections marked as non-normative, all diagrams, examples and notes in this specification are non-normative. Everything else in this specification is normative. ### 2.3 Conformance targets This specification defines two conformance classes. A **conforming contract** is the on-chain contract that implements the operations of Section 7 and maintains the state of Section 5. A **conforming application** is software that constructs, signs, submits or reads protocol messages on behalf of any participant. The consumer's application, the provider's gateway and software that verifies the record are conforming applications. Participant roles are not conformance classes. Their duties are stated as requirements on the role in Section 4. ## 3. Terminology **Agreed maximum.** The largest amount a consumer can owe under a metered service agreement. **Amount owed.** The amount the consumer owes the provider under a service agreement, computed under Section 9. **Application.** The conforming application a consumer uses to review terms, hold the consumer key and sign. **Consumer.** The party that accepts an offer and uses the service. **Consumer key.** The key pair with which a consumer signs, and whose public key the entitlement names. **Currency.** The unit in which the amounts of an offer are stated. **Deposit.** An amount stated in an offer that the consumer pays in addition to the price and that is returned under the offer's terms. **Device.** A thing registered by a provider through which a service is delivered. **Device key.** A key pair held by a device, with which the device signs usage reports. **Device record.** The public record of a device, created when the provider registers it. **Entitlement.** The recorded right of a consumer key to use a device during a service window. **Gateway.** The conforming application, operated by a provider, that reads the record and operates devices. **Offer.** The terms, published by a provider, on which it will provide a service on a device. **Payment model.** The way the amount owed is determined: a fixed price for a fixed term, or a unit price applied to measured use. **Price.** The amount stated in a fixed-term offer for the service window. **Provider.** The party that registers devices, publishes offers and provides the service. **Provider key.** The key pair with which a provider signs. **Reading.** The cumulative value of a device's meter at a stated time. **Relying party.** Anyone who verifies the record of a service without controlling it. **Report signer.** The party, provider or device, whose signature a service agreement requires on usage reports. **Service agreement.** The record created when a consumer's signed acceptance of an offer is recorded. **Service window.** The period, fixed in a service agreement, during which the entitlement is in force. **Settlement mode.** The way payment is made under an offer. This version defines one mode, in which payment is made outside the blockchain. **Settlement record.** A provider's recorded statement that a payment or a refund under a service agreement was made. **Unit.** The quantity in which use is measured under a metered offer. **Unit price.** The amount owed per unit under a metered offer. **Usage report.** A signed message stating a reading for a service agreement. The following terms are used as defined elsewhere: Accountable Node, validator (SBRIT specification); `blockTimestamp`, canonical form, signed message, submitter (Conventions). ## 4. Participants ### 4.1 Provider A provider is identified by its provider key. A provider registers devices, publishes and withdraws offers, and signs the records that this specification reserves to the provider. A provider is accountable for delivering the service on the terms of the service agreement and for the truth of what it records. A provider MUST submit to the blockchain, without delay, every validly signed consumer message it receives, and MUST pay the transaction fee. A provider MUST NOT make submission conditional on the content of the message. A provider MUST record a settlement record when, and only when, the payment or refund it states was made. A provider MUST keep each device record accurate while the device is offered. This protocol does not verify the identity of a provider, the existence or condition of a device, the delivery of the service, or that a payment or refund stated in a settlement record took place. ### 4.2 Device A device is identified by its device record. A device that signs usage reports holds a device key, whose public key is part of the device record. A device that does not sign is represented by the provider. A provider MUST NOT register as a device key a key whose private part is held outside the device. A device that signs MUST sign only readings taken from its own meter. This protocol verifies a device's signature. It does not verify that a reading is correct. ### 4.3 Gateway A gateway is operated by a provider and acts with the provider's authority. It holds no role separate from the provider. A gateway MUST NOT operate a device for a consumer unless it has established, under Section 9.1, that an entitlement is in force for that device and that the requester controls the consumer key the entitlement names. A gateway MUST establish an entitlement by reading recorded state. This protocol does not verify what a gateway does. A relying party sees the record, not the operation of the device. ### 4.4 Consumer A consumer is identified, for a service agreement, by a consumer key. A consumer accepts an offer and signs the other actions that this specification reserves to the consumer. A consumer needs no account on the blockchain and holds no asset on it. A consumer is accountable for payment of the amount owed. This protocol records that obligation and does not enforce it. This protocol does not verify the identity of a consumer. ### 4.5 Application An application acts for one consumer. An application MUST generate the consumer key on the consumer's own device and MUST NOT disclose its private part to the provider or to any other party. An application MUST present to the consumer the complete terms to be signed before it signs an acceptance. An application MUST make available to the consumer the identifier of each service agreement it has signed, so that the consumer can verify the record independently of the provider. ### 4.6 Relying party A relying party holds no key and has no authority under this protocol. It verifies a service from the record, using the read interface of Section 5.5. ### 4.7 Submitter A submitter carries signed messages to the blockchain and pays the transaction fee. Under this protocol the submitter is ordinarily the provider or its gateway. Submitting a message confers no authority. ### 4.8 Accountable Nodes and validators Accountable Nodes and validators perform their duties under the SBRIT specification. This protocol assigns them no further role.