A client account calls (requestStream) on the Manager smart contract with a stream id and with the requested profiles as parameters.
The manager account gets notified of the stream request (StreamRequested event) and approves the stream (approveStream).
The client account get notified of the approval (StreamApproved event) and calls createStream which creates a new Stream smart contract and also deposits funds for mining/transcoding rewards.
After the stream has ended, the manager will call (endStream) to signal it.
The manager gets the video stream, starts the ingestion process to create input chunks, registers chunk ids and their estimated wattages (addInputChunkId).
Miners and validators listen for stream contract creation events (StreamCreated).
Miner accounts listen for events signaling that new work is available for the stream via the (InputChunkAdded) event. Alternatively, miners can query input chunk ids from the new stream contract (getInChunks) and proceed to work on transcoding those chunks.
Miners submit proofs for work via (submitProof) providing the input chunk id, profile, proof and output chunk id as parameters.
Validators listen for events signaling that new work has been registered via the (ChunkProofSubmited) event and query the proofs (getCandidateProof) and verify them. Upon successful verification the validators call (validateProof) which also funds the miner account whose proof has been verified with the mining fees.
The stream contract escrow is funded by the client upon creation but funds can run out or the stream can end with funds remaining.
Validating/rewarding miners will fail if the stream escrow is low on funds. An (OutOfFunds) is emitted if validation was requested on a stream low on funds.
Clients can provide additional funds to the stream escrow by calling (deposit).
Clients can withdraw remaining funds (only after stream ended) by calling (refund).