### Run Symbiotic Super Sum Network with Docker

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

These commands are used to generate the network configuration, start the Dockerized network, and check the status of the running services. It's a quick way to get the environment up and running.

```bash
./generate_network.sh
docker compose --project-directory temp-network up -d
docker compose --project-directory temp-network ps
```

--------------------------------

### Start Sum-Node with Multiple Chain Support

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This command starts the sum-node service, enabling it to connect to multiple EVM chains. It requires the relay API URL, a list of EVM RPC URLs, contract addresses for settlement and task management, a private key for signing, and a log level.

```bash
./sum-node \
  --relay-api-url="relay-sidecar-1:8081" \
  --evm-rpc-urls="http://anvil:8545,http://anvil-settlement:8546" \
  --contract-addresses="0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF,0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF" \
  --private-key="0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80" \
  --log-level="info"
```

--------------------------------

### Solidity: Interface Naming Convention with 'I' Prefix

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Shows the convention of prefixing interface names with a capital 'I' for clarity and adherence to the project's style guide.

```solidity
interface IERC777 {
```

--------------------------------

### Clone and Initialize Repository

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

This snippet demonstrates how to clone the Symbiotic Super Sum repository and update its submodules. It ensures all necessary components are downloaded.

```bash
git clone https://github.com/symbioticfi/symbiotic-super-sum.git
git submodule update --init --recursive
npm install
```

--------------------------------

### Solidity: Event Emission Immediately After State Change

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Provides an example of emitting an event immediately after a state change, with the event name matching the function name, adhering to the project's conventions.

```solidity
function _burn(address who, uint256 value) internal {
    super._burn(who, value);
    emit Burn(who, value);
}
```

--------------------------------

### View Symbiotic Super Sum Network Logs

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

These commands allow you to view logs from the Symbiotic Super Sum Docker network. You can view all logs or filter logs for specific services to aid in debugging.

```bash
# View all logs
docker compose --project-directory temp-network logs -f

# View specific service logs
docker compose --project-directory temp-network logs -f anvil
docker compose --project-directory temp-network logs -f relay-sidecar-1
docker compose --project-directory temp-network logs -f sum-node-1
```

--------------------------------

### Manage Symbiotic Super Sum Network Lifecycle

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

This section covers commands for stopping, cleaning up, and rebuilding the Symbiotic Super Sum Docker network. It includes options for removing volumes to ensure a clean state.

```bash
docker compose --project-directory temp-network down
docker compose --project-directory temp-network down -v
rm -rf temp-network
docker compose --project-directory temp-network build
```

--------------------------------

### Docker Network Deployment and Management

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This section details how to generate and deploy a multi-node Docker network for Symbiotic. It includes generating configurations, starting the network, checking service status, viewing logs, and cleaning up resources.

```bash
# Generate network configuration (default 4 operators)
./generate_network.sh

# Or specify custom operator count
OPERATOR_COUNT=10 ./generate_network.sh

# Start the entire network
docker compose --project-directory temp-network up -d

# Check all services are running
docker compose --project-directory temp-network ps

# View logs from specific services
docker compose --project-directory temp-network logs -f sum-node-1
docker compose --project-directory temp-network logs -f relay-sidecar-1

# Stop and clean up
docker compose --project-directory down -v
rm -rf temp-network
```

--------------------------------

### Monitor Resource Usage in Symbiotic Super Sum Network

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

These commands are used to monitor the resource usage (CPU, memory) of Docker containers, specifically those running the Symbiotic Super Sum network services. This helps in identifying performance bottlenecks.

```bash
# Check resource usage for all containers
docker stats

# Monitor specific containers
docker stats symbiotic-anvil symbiotic-relay-1 symbiotic-sum-node-1
```

--------------------------------

### Access Symbiotic Super Sum Network Containers

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

This snippet provides commands to access the shell of specific containers within the Symbiotic Super Sum Docker network. This is useful for debugging and inspecting the running services.

```bash
docker compose --project-directory temp-network exec anvil sh
docker compose --project-directory temp-network exec relay-sidecar-1 sh
docker compose --project-directory temp-network exec sum-node-1 sh
```

--------------------------------

### Create a Task in Symbiotic Super Sum Network

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

This command demonstrates how to create a task in the Symbiotic Super Sum network using the `cast` CLI tool. It sends a transaction to the `createTask` function and extracts the task ID from the logs.

```bash
taskID=$(cast send --rpc-url http://127.0.0.1:8545 --json \
 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
 0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
 "createTask(uint256,uint256)" 33 9 | jq -r '.logs[0].topics[1]')

taskID=$(cast send --rpc-url http://127.0.0.1:8546 --json \
 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
 0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
 "createTask(uint256,uint256)" 33 9 | jq -r '.logs[0].topics[1]')
```

--------------------------------

### Check Task Result in Symbiotic Super Sum Network

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/README.md

This command shows how to retrieve and decode the result of a task from the Symbiotic Super Sum network. It uses `cast` to call the `responses` function and then decodes the ABI-encoded output.

```bash
result=$(cast call --rpc-url http://127.0.0.1:8545 \
 0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
 "responses(bytes32)" $taskID)
cast decode-abi --json "data()(uint48,uint256)" $result

result=$(cast call --rpc-url http://127.0.0.1:8546 \
 0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
 "responses(bytes32)" $taskID)
cast decode-abi --json "data()(uint48,uint256)" $result
```

--------------------------------

### Solidity: Import Grouping and Ordering

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Illustrates the structured way imports should be organized into groups (contracts, libraries, interfaces, external files) and sorted alphabetically within each group.

```solidity
import {NetworkManager} from "../base/NetworkManager.sol";
import {OzEIP712} from "../base/OzEIP712.sol";
import {PermissionManager} from "../base/PermissionManager.sol";

import {Checkpoints} from "../../libraries/structs/Checkpoints.sol";
import {KeyTags} from "../../libraries/utils/KeyTags.sol";

import {ISettlement} from "../interfaces/modules/settlement/ISettlement.sol";
import {ISigVerifier} from "../interfaces/modules/settlement/sig-verifiers/ISigVerifier.sol";

import {StaticDelegateCallable} from "@symbioticfi/core/src/contracts/common/StaticDelegateCallable.sol";
import {Subnetwork} from "@symbioticfi/core/src/contracts/libraries/Subnetwork.sol";

import {Initializable} from "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
```

--------------------------------

### Solidity: Abstract Contract Declaration

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Demonstrates how to declare abstract contracts that are intended to be inherited by other contracts, ensuring they are not used standalone.

```solidity
abstract contract AccessControl is ..., {
    // ... contract body
}
```

--------------------------------

### Solidity Versioning for Abstract Contracts, Libraries, and Interfaces

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Outlines the use of the caret (^) range operator for specifying the Solidity version range in abstract contracts, libraries, and interfaces to ensure broader compatibility.

```solidity
pragma solidity ^0.X.0;
```

--------------------------------

### Solidity: Private and Internal Variable/Function Naming Convention

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Demonstrates the convention of prefixing internal or private state variables and functions with an underscore, as per the project's code style guidelines.

```solidity
contract TestContract {
    uint256 private _privateVar;
    uint256 internal _internalVar;
    function _testInternal() internal { ... }
    function _testPrivate() private { ... }
}
```

--------------------------------

### Solidity: Avoiding Naming Collisions with Trailing Underscore

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Illustrates the practice of using a single trailing underscore to avoid naming collisions between public variables and constructor arguments.

```solidity
contract TestContract {
    uint256 public foo;

    constructor(uint256 foo_) {
      foo = foo_;
    }
}
```

--------------------------------

### Relay Infrastructure Deployment with Forge

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This outlines the process of deploying the complete relay infrastructure using Forge scripts. It covers sequential deployment steps for various components like the Key Registry, Voting Power Provider, Settlement, and ValSet Driver.

```solidity
// Run deployment steps sequentially
// 1. Deploy Key Registry
forge script script/MyRelayDeploy.sol:MyRelayDeploy \
  --sig "runDeployKeyRegistry()" \
  --rpc-url http://localhost:8545 \
  --broadcast

// 2. Deploy Voting Power Provider
forge script script/MyRelayDeploy.sol:MyRelayDeploy \
  --sig "runDeployVotingPowerProvider()" \
  --rpc-url http://localhost:8545 \
  --broadcast

// 3. Deploy Settlement and SumTask
forge script script/MyRelayDeploy.sol:MyRelayDeploy \
  --sig "runDeploySettlement()" \
  --rpc-url http://localhost:8545 \
  --broadcast

// 4. Deploy ValSet Driver
forge script script/MyRelayDeploy.sol:MyRelayDeploy \
  --sig "runDeployValSetDriver()" \
  --rpc-url http://localhost:8545 \
  --broadcast

// Deployed contract addresses (localhost):
// ValSetDriver: 0x43C27243F96591892976FFf886511807B65a33d5
// SumTask: 0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF
// VotingPowerProvider: 0x369c72C823A4Fc8d2A3A5C3B15082fb34A342878
// KeyRegistry: 0xe1557A820E1f50dC962c3392b875Fe0449eb184F
// Settlement: 0x882B9439598239d9626164f7578F812Ef324F5Cb
// Network: 0xfdc4b2cA12dD7b1463CC01D8022a49BDcf5cFa24
```

--------------------------------

### Solidity Versioning for Deployable Contracts

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Specifies the requirement for deployable Solidity contracts to have an explicit version set in the pragma statement.

```solidity
pragma solidity 0.8.X;
```

--------------------------------

### Solidity: SumTask Contract Unit Tests

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

Contains unit tests for the SumTask smart contract using Solidity and the Forge testing framework. It demonstrates mocking the settlement layer to isolate and validate task creation and response logic. Tests cover task creation, nonce verification, and responding to tasks with mock proofs.

```solidity
// test/SumTask.t.sol
contract SumTaskTest is Test {
    SumTask public sumTask;

    function setUp() public {
        sumTask = new SumTask(address(new SettlementMock()));
    }

    function test_CreateTask() public {
        // Create task and verify nonce increment
        sumTask.createTask(50, 50);
        assertEq(sumTask.nonce(), 1);

        // Create second task
        sumTask.createTask(25, 75);
        assertEq(sumTask.nonce(), 2);
    }

    function test_RespondToTask() public {
        // Create task
        bytes32 taskId = sumTask.createTask(50, 50);

        // Submit response with mock proof
        sumTask.respondTask(taskId, 100, 1, new bytes(0));

        // Verify response
        (uint48 answeredAt, uint256 answer) = sumTask.responses(taskId);
        assertEq(answer, 100);
        assertEq(answeredAt, uint48(block.timestamp));

        // Verify task status changed
        assertEq(uint8(sumTask.getTaskStatus(taskId)), uint8(SumTask.TaskStatus.RESPONDED));
    }
}

// Run tests
// forge test -vv
// forge test --match-test test_CreateTask -vvvv

```

--------------------------------

### Bash: Environment Configuration for Network Generation

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

Provides bash script commands for configuring network parameters via environment variables, enabling flexible deployment of the Symbiotic Super Sum network. It defines variables for operator count, aggregators, committers, epoch time, verification type, and committer slot duration.

```bash
# Environment variables for generate_network.sh
export OPERATOR_COUNT=10           # Number of operators (default: 4, max: 999)
export NUM_AGGREGATORS=2           # Number of aggregators (default: 1)
export NUM_COMMITTERS=3            # Number of committers (default: 1)
export EPOCH_TIME=120              # Epoch duration in seconds (default: 60)
export VERIFICATION_TYPE=0         # 0=ZK verification, 1=Simple BLS (default: 1)
export COMMITTER_SLOT_DURATION=15  # Slot duration in seconds (default: 10)

# Generate network with custom configuration
./generate_network.sh

# Configuration file locations:
# temp-network/docker-compose.yml
# temp-network/my-relay-deploy.toml
# temp-network/.env

```

--------------------------------

### SumTask Contract - Create Task

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

Demonstrates how to deploy the SumTask contract and create a new addition task. The task ID is generated and stored on-chain, and its initial status can be checked.

```APIDOC
## POST /contracts/SumTask/createTask

### Description
Creates a new computation task on-chain by accepting two numbers to be added. It generates a unique task ID based on chain ID, input numbers, and nonce, then emits an event that off-chain nodes listen for.

### Method
POST

### Endpoint
`0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF` (SumTask Contract Address)

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body

This function is typically called via a contract interaction, not a direct HTTP request. The parameters are passed during the contract call.

- **numberA** (uint256) - Required - The first number for the addition.
- **numberB** (uint256) - Required - The second number for the addition.

### Request Example (Solidity)
```solidity
// Deploy SumTask contract
// Settlement address: 0x882B9439598239d9626164f7578F812Ef324F5Cb
SumTask sumTask = new SumTask(0x882B9439598239d9626164f7578F812Ef324F5Cb);

// Create a task to compute 33 + 9
uint256 numberA = 33;
uint256 numberB = 9;
bytes32 taskId = sumTask.createTask(numberA, numberB);

// Task is stored in tasks mapping
(uint256 a, uint256 b, uint256 nonce, uint48 createdAt) = sumTask.tasks(taskId);
// a = 33, b = 9, createdAt = current block timestamp

// Check task status
SumTask.TaskStatus status = sumTask.getTaskStatus(taskId);
// Returns TaskStatus.CREATED (0)
```

### Request Example (CLI)
```bash
taskID=$(cast send --rpc-url http://127.0.0.1:8545 --json \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
  "createTask(uint256,uint256)" 33 9 | jq -r '.logs[0].topics[1]')

echo "Task ID: $taskID"
# Task ID: 0x7f3b4c5a2d8e9f1a6b4c8e2f5d3a9b7c4e1f6a8d2b5c9e3f7a1d4b8c2e6f5a3d
```

### Response
#### Success Response (200)

On-chain transaction receipt confirming the task creation. The `taskId` can be extracted from the event logs.

#### Response Example (CLI Event Log)
```json
{
  "taskId": "0x7f3b4c5a2d8e9f1a6b4c8e2f5d3a9b7c4e1f6a8d2b5c9e3f7a1d4b8c2e6f5a3d"
}
```
```

--------------------------------

### View Generated Configuration (Shell)

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This snippet shows how to view the generated Docker Compose configuration for a specific node. It uses `cat` to display the file content and `grep` to filter for the 'sum-node-1:' service and its subsequent lines.

```shell
cat temp-network/docker-compose.yml | grep -A 5 "sum-node-1:"
```

--------------------------------

### Solidity: Comparison with msg.sender or tx.origin

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Shows the convention of placing `msg.sender` or `tx.origin` on the right side of an inequality when performing comparisons.

```solidity
modifier onlyOwner() internal {
    if (owner != msg.sender) {
      revert NotOwner();
    }
}
```

--------------------------------

### Solidity: Custom Error Declaration

Source: https://github.com/symbioticfi/symbiotic-super-sum/blob/main/CONTRIBUTING.md

Demonstrates the declaration of custom errors, emphasizing concise and readable naming for better error handling.

```solidity
error InsufficientFunds();
error NoAccess();
error NotOwner();
```

--------------------------------

### Create Task via CLI (Bash/Cast)

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This command-line interface script uses `cast` to interact with the deployed SumTask contract and create tasks. It sends a transaction to the `createTask` function and extracts the generated task ID from the event logs using `jq`.

```bash
# Create task on main network (port 8545)
taskID=$(cast send --rpc-url http://127.0.0.1:8545 --json \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
  "createTask(uint256,uint256)" 33 9 | jq -r '.logs[0].topics[1]')

echo "Task ID: $taskID"
# Task ID: 0x7f3b4c5a2d8e9f1a6b4c8e2f5d3a9b7c4e1f6a8d2b5c9e3f7a1d4b8c2e6f5a3d

# Create task on settlement network (port 8546)
taskID=$(cast send --rpc-url http://127.0.0.1:8546 --json \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
  "createTask(uint256,uint256)" 100 250 | jq -r '.logs[0].topics[1]')

# Wait for off-chain nodes to process (typically 1-2 seconds)
```

--------------------------------

### Go: Off-Chain Task Processing Logic

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

Implements the off-chain task lifecycle for the Symbiotic Super Sum project. It handles event monitoring, computation, signature requests, proof aggregation, and on-chain submission across multiple chains concurrently. Key data structures like TaskState are defined, and functions process new task events and submit responses with aggregation proofs.

```go
// Key data structures
type TaskState struct {
    ChainID      int64
    Task         contracts.SumTaskTask
    Result       *big.Int
    SigEpoch     int64
    SigRequestID string
    AggProof     []byte
    Statuses     map[int64]uint8
}

// Process new task event
func processNewTasks(ctx context.Context, chainID int64, iter *contracts.SumTaskCreateTaskIterator) error {
    for iter.Next() {
        evt := iter.Event

        // Compute result
        taskResult := new(big.Int).Add(evt.Task.NumberA, evt.Task.NumberB)

        // Prepare message for signing (keccak256(abi.encode(taskId, result)))
        bytes32T, _ := abi.NewType("bytes32", "", nil)
        uint256T, _ := abi.NewType("uint256", "", nil)
        args := abi.Arguments{{Type: bytes32T}, {Type: uint256T}}
        msg, _ := args.Pack(evt.TaskId, taskResult)

        // Request signature from relay
        epochInfos, _ := relayClient.GetLastAllCommitted(ctx, &v1.GetLastAllCommittedRequest{})
        resp, _ := relayClient.SignMessage(ctx, &v1.SignMessageRequest{
            KeyTag:        15,
            Message:       msg,
            RequiredEpoch: &epochInfos.SuggestedEpochInfo.LastCommittedEpoch,
        })

        // Store task state
        tasks[evt.TaskId] = TaskState{
            ChainID:      chainID,
            Task:         evt.Task,
            Result:       taskResult,
            SigEpoch:     int64(resp.Epoch),
            SigRequestID: resp.RequestId,
            AggProof:     nil,
            Statuses:     map[int64]uint8{},
        }
    }
    return nil
}

// Fetch aggregation proof and submit response
func processProof(ctx context.Context, taskID common.Hash) error {
    task := tasks[taskID]

    for chainID, status := range task.Statuses {
        if status == TaskResponded {
            continue
        }

        // Create transaction
        pk, _ := crypto.HexToECDSA(cfg.privateKey)
        txOpts, _ := bind.NewKeyedTransactorWithChainID(pk, big.NewInt(chainID))

        // Submit response with aggregation proof
        tx, _ := sumContracts[chainID].RespondTask(
            txOpts,
            taskID,
            task.Result,
            big.NewInt(task.SigEpoch),
            task.AggProof,
        )

        // tx.Hash() = 0x9876...
    }
    return nil
}

```

--------------------------------

### Respond to Task in SumTask Contract (Solidity)

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This function submits a verified computation result along with a BLS aggregated signature proof. It verifies the quorum signature against the settlement contract before accepting the result. The task's response and status can be queried on-chain.

```solidity
// After off-chain nodes compute result and generate proof
bytes32 taskId = 0x1234...;
uint256 result = 42; // 33 + 9
uint48 epoch = 5;
bytes memory aggregationProof = hex"abcd..."; // BLS aggregated signature proof

// Submit the verified result
sumTask.respondTask(taskId, result, epoch, aggregationProof);

// Result is now stored and task is marked as responded
(uint48 answeredAt, uint256 answer) = sumTask.responses(taskId);
// answeredAt = block.timestamp, answer = 42

// Verify task was responded to
SumTask.TaskStatus status = sumTask.getTaskStatus(taskId);
// Returns TaskStatus.RESPONDED (1)

// Task expiry is 12000 seconds (TASK_EXPIRY constant)
// If not responded within expiry period, status becomes TaskStatus.EXPIRED (2)
```

--------------------------------

### SumTask Contract - Respond to Task

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

Submits a verified computation result along with a BLS aggregated signature proof. The system verifies the quorum signature before accepting the result and updating the task status.

```APIDOC
## POST /contracts/SumTask/respondTask

### Description
Submits a verified computation result with a BLS aggregated signature proof from the validator set. It verifies the quorum signature against the settlement contract before accepting the result.

### Method
POST

### Endpoint
`0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF` (SumTask Contract Address)

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body

This function is typically called via a contract interaction. The parameters are passed during the contract call.

- **taskId** (bytes32) - Required - The ID of the task to respond to.
- **result** (uint256) - Required - The computed result of the task.
- **epoch** (uint48) - Required - The epoch number during which the computation was performed.
- **aggregationProof** (bytes) - Required - The BLS aggregated signature proof from the validators.

### Request Example (Solidity)
```solidity
// After off-chain nodes compute result and generate proof
bytes32 taskId = 0x1234...;
uint256 result = 42; // 33 + 9
uint48 epoch = 5;
bytes memory aggregationProof = hex"abcd..."; // BLS aggregated signature proof

// Submit the verified result
sumTask.respondTask(taskId, result, epoch, aggregationProof);

// Result is now stored and task is marked as responded
(uint48 answeredAt, uint256 answer) = sumTask.responses(taskId);
// answeredAt = block.timestamp, answer = 42

// Verify task was responded to
SumTask.TaskStatus status = sumTask.getTaskStatus(taskId);
// Returns TaskStatus.RESPONDED (1)

// Task expiry is 12000 seconds (TASK_EXPIRY constant)
// If not responded within expiry period, status becomes TaskStatus.EXPIRED (2)
```

### Response
#### Success Response (200)

On-chain transaction receipt confirming the task response submission. The task status should be updated to `RESPONDED`.

#### Response Example (Contract State)
```
// After calling respondTask:
(uint48 answeredAt, uint256 answer) = sumTask.responses(taskId);
// answeredAt = current block timestamp
// answer = 42

SumTask.TaskStatus status = sumTask.getTaskStatus(taskId);
// status = TaskStatus.RESPONDED (1)
```
```

--------------------------------

### Query Task Results via CLI (Bash/Cast)

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This command-line script uses `cast` to query the results of a previously created task from the SumTask contract. It calls the `responses` function with the task ID and then decodes the ABI-encoded result to display the timestamp and computed answer.

```bash
# Query result on main network
result=$(cast call --rpc-url http://127.0.0.1:8545 \
  0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
  "responses(bytes32)" $taskID)

# Decode the ABI-encoded result
cast decode-abi --json "data()(uint48,uint256)" $result
# Output: {"answeredAt": 1704067200, "answer": 42}

# Query on settlement network
result=$(cast call --rpc-url http://127.0.0.1:8546 \
  0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
  "responses(bytes32)" $taskID)

cast decode-abi --json "data()(uint48,uint256)" $result
# Output: {"answeredAt": 1704067205, "answer": 350}
```

--------------------------------

### Create Task in SumTask Contract (Solidity)

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

This function creates a new computation task on the SumTask contract by accepting two numbers for addition. It generates a unique task ID and emits an event for off-chain nodes. The task details and status can be queried on-chain.

```solidity
// Deploy SumTask contract
// Settlement address: 0x882B9439598239d9626164f7578F812Ef324F5Cb
SumTask sumTask = new SumTask(0x882B9439598239d9626164f7578F812Ef324F5Cb);

// Create a task to compute 33 + 9
uint256 numberA = 33;
uint256 numberB = 9;
bytes32 taskId = sumTask.createTask(numberA, numberB);

// Task is stored in tasks mapping
(uint256 a, uint256 b, uint256 nonce, uint48 createdAt) = sumTask.tasks(taskId);
// a = 33, b = 9, createdAt = current block timestamp

// Check task status
SumTask.TaskStatus status = sumTask.getTaskStatus(taskId);
// Returns TaskStatus.CREATED (0)
```

--------------------------------

### Query Task Results

Source: https://context7.com/symbioticfi/symbiotic-super-sum/llms.txt

Allows querying the result of a completed task using its task ID. The response includes the timestamp of the answer and the computed value.

```APIDOC
## GET /contracts/SumTask/responses/{taskId}

### Description
Query the task response using the task ID. Results are returned as a tuple containing the timestamp and computed answer.

### Method
GET

### Endpoint
`0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF` (SumTask Contract Address)

### Parameters
#### Path Parameters
- **taskId** (bytes32) - Required - The ID of the task to query.

#### Query Parameters
None

### Request Example (CLI)
```bash
# Assuming taskID is already set from createTask function
# Query result on main network
result=$(cast call --rpc-url http://127.0.0.1:8545 \
  0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
  "responses(bytes32)" $taskID)

# Decode the ABI-encoded result
cast decode-abi --json "data()(uint48,uint256)" $result
# Output: {"answeredAt": 1704067200, "answer": 42}

# Query on settlement network
result=$(cast call --rpc-url http://127.0.0.1:8546 \
  0xDf12251aD82BF1eb0E0951AD15d37AE5ED3Ac1dF \
  "responses(bytes32)" $taskID)

cast decode-abi --json "data()(uint48,uint256)" $result
# Output: {"answeredAt": 1704067205, "answer": 350}
```

### Response
#### Success Response (200)

A JSON object containing the `answeredAt` timestamp and the computed `answer` for the specified task ID.

#### Response Example
```json
{
  "answeredAt": 1704067200,
  "answer": 42
}
```
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.