# Feature Request: Child Transaction Support for Native Hedera Services

# Feature Request: Child Transaction Support for Native Hedera Services

## Summary
Currently, Hedera supports child transactions within smart contracts, allowing contract execution to trigger additional transactions. However, this capability is not available for native Hedera services (HTS, HFS, etc.). This feature request proposes extending child transaction support to native transactions, enabling more complex transaction patterns without requiring smart contracts.

## Background
Hedera's architecture separates concerns between native services (Token Service, File Service, Consensus Service, etc.) and the Smart Contract Service. Smart contracts on Hedera can initiate child transactions as part of their execution, creating powerful composable patterns. However, developers working with native services cannot currently implement similar patterns without resorting to client-side orchestration.

## Proposed Feature
We propose adding support for child transactions within native Hedera transactions, allowing a parent transaction to specify dependent child transactions that should execute atomically if the parent succeeds.

## Use Cases

### 1. Token Service Composability
```
Parent Transaction: TokenCreateTransaction
Child Transactions:
- TokenAssociateTransaction (to creator)
- TokenFreezeTransaction (for compliance)
- TokenTransferTransaction (initial distribution)
```

This would create a token and perform initial setup actions atomically.

### 2. Multi-step Operations with Atomic Guarantees
```
Parent Transaction: TokenMintTransaction
Child Transactions:
- TokenTransferTransaction (distribute to multiple accounts)
- TopicSubmitMessageTransaction (announce distribution)
```

### 3. Complex Financial Operations
```
Parent Transaction: AccountCreateTransaction
Child Transactions:
- TokenAssociateTransaction (multiple tokens)
- TokenTransferTransaction (initial funding)
- ScheduleCreateTransaction (future funding event)
```

### 4. Automated Compliance Workflows
```
Parent Transaction: TokenTransferTransaction (large amount)
Child Transactions:
- TopicSubmitMessageTransaction (compliance notification)
- FileAppendTransaction (transaction documentation)
```

## Benefits

1. **Atomic Execution**: All operations succeed or fail together, eliminating partial state changes
2. **Reduced Complexity**: Eliminates need for client-side transaction choreography
3. **Lower Latency**: Reduces round-trips between client and network
4. **Consistency**: Provides similar capabilities across both smart contract and native services
5. **Cost Efficiency**: Potentially lower fees compared to equivalent smart contract implementation
6. **Simplified Error Handling**: Single transaction status rather than handling multiple failure modes

## Technical Considerations

### Proposed Implementation Approach
1. **Transaction Structure**: Extend transaction records to include parent/child relationships
2. **Execution Semantics**: Define clear rules for execution order and failure handling
3. **Fee Structure**: Establish predictable fee calculation for transaction groups
4. **Record Structure**: Update record structure to show relationships between transactions
5. **SDK Support**: Add methods to link transactions as parent/child

### Security Considerations
1. **Authorization**: Clear rules on signature requirements for child transactions
2. **Resource Limits**: Appropriate limits on child transaction depth and breadth
3. **Atomicity Guarantees**: Well-defined behavior for partial failures

## Example SDK Usage (Conceptual)

```typescript
// Create parent transaction
const parentTx = new TokenCreateTransaction()
.setTokenName("Example Token")
.setTokenSymbol("EX")
.setDecimals(0)
.setInitialSupply(100)
.setTreasuryAccountId(treasuryId);

// Create child transactions
const associateTx = new TokenAssociateTransaction()
.setAccountId(recipientId)
.setTokenIds([tokenId]);

const transferTx = new TokenTransferTransaction()
.setTokenId(tokenId)
.setAccountId(treasuryId, -10)
.setAccountId(recipientId, 10);

// Link transactions
parentTx.addChildTransaction(associateTx);
parentTx.addChildTransaction(transferTx);

// Execute transaction group
const txResponse = await parentTx.execute(client);
```

## Impact on Existing Systems
1. **Consensus Algorithm**: May require adjustments to handle transaction groups
2. **Node Software**: Updates to transaction processing and validation
3. **Record Streaming**: Enhanced record format to indicate relationships
4. **SDK Changes**: New methods to support child transactions
5. **Mirror Nodes**: Updated APIs to show transaction relationships

## Conclusion
Adding child transaction support to native Hedera services would significantly enhance the platform's capabilities, providing developers with powerful tools to build more sophisticated applications without requiring smart contracts. This feature would maintain Hedera's strengths in high throughput and low fees while adding compositional power currently only available through smart contracts.

We believe this enhancement would provide substantial value to the Hedera ecosystem and help position the network as a leader in flexible, composable DLT architecture.

The issue names no repository files, tests, or implementation entry points; begin by mapping transaction processing, record streaming, mirror-node APIs, and SDK transaction classes. Define the execution, authorization, fee, record, and failure semantics for native-service child transactions before determining the affected components and tests.

Written by the indexing model from the issue text.