All Products
Search
Document Center

Blockchain as a Service:Smart contract examples

Last Updated:Mar 31, 2026

Alibaba Cloud Blockchain as a Service (BaaS) provides two ready-to-use smart contract examples built on Hyperledger Fabric: the General Deposit Contract for on-chain data notarization, and the Simple Approval Contract for blockchain-backed task approval workflows. Use these contracts as-is or as a starting point for your own chaincode.

General deposit contract

The General Deposit Contract provides a general-purpose interface for reading and writing key-value data to the blockchain ledger. It supports two write modes — append-only and overwrite — along with modification history queries.

Get the chaincode from the source repository, or download a pre-packaged version:

For packaging instructions, see Package chaincode.

Initialization parameters

None.

API operations

get

Reads the current value stored under a key.

ParameterTypeDescription
keystringThe key to read

Returns:

  • Success: the current value stored under the key

  • Failure: the error cause

put

Writes a key-value pair to the blockchain. Fails if the key already exists. Use put to enforce write-once semantics — once a record is deposited, it cannot be overwritten.

ParameterTypeDescription
keystringThe key to write
valuestringThe data to store

Returns:

  • Success: the key that was written

  • Failure: the error cause

set

Writes a key-value pair to the blockchain. If the key already exists, the existing value is overwritten. Use set when you need to update a record.

ParameterTypeDescription
keystringThe key to write
valuestringThe data to store

Returns:

  • Success: the key that was written

  • Failure: the error cause

history

Returns the modification history of a key as a JSON-encoded list.

ParameterTypeDescription
keystringThe key to query

Returns:

  • Success: the modification history of the key (JSON-encoded)

  • Failure: the error cause

Simple approval contract

The Simple Approval Contract implements a blockchain-backed task approval workflow. Tasks are created with a list of required approvers; when all required approvers have approved, the task is marked complete and a completion event is emitted. All state transitions are recorded on-chain, providing a tamper-evident audit trail.

Get the chaincode from the source repository, or download a pre-packaged version:

For packaging instructions, see Package chaincode.

Initialization parameters

None.

Data structure

The contract stores each task as a Task struct with the following fields:

type Task struct {
    Name        string   `json:"name"`        // Task name
    Creator     string   `json:"creator"`     // Identity of the task creator
    Requires    []string `json:"requires"`    // Identities that must approve; format: ${MSP_ID}.${USER_NAME}
    Approved    []string `json:"approved"`    // Identities that have approved; format: ${MSP_ID}.${USER_NAME}
    Description string   `json:"description"` // Task description
}

When parsing on-chain task data or subscribing to events, use the JSON field names shown in the json:"..." tags.

API operations

create

Creates a new task and emits a creation event.

ParameterTypeDescription
namestringThe name of the task
taskstringJSON-encoded task object; must include requires and description fields

Returns:

  • Success: the name of the created task

  • Failure: the error cause

Events:

  • event-create-task — emitted on success; payload is JSON-encoded

get

Retrieves the current state of a task.

ParameterTypeDescription
namestringThe name of the task to retrieve

Returns:

  • Success: the task as a JSON-encoded Task object

  • Failure: the error cause

approve

Records the calling identity's approval for a task. The contract checks whether all required approvers have approved after each call.

ParameterTypeDescription
namestringThe name of the task to approve

Returns:

  • Success: the updated task as a JSON-encoded Task object

  • Failure: the error cause

Events:

  • event-task-finished — emitted when all required approvers have approved; payload is JSON-encoded

  • event-approve-task — emitted when the approval is recorded but the task is not yet complete; payload is JSON-encoded

What's next