Why BitSave Protocol Uses Parent–Child Smart Contracts

Every developer writes code. But what if that code could deploy itself, manage its own memory, and still execute the programmer's instructions?

That's exactly what smart contracts can do on blockchain networks. And in this article, we'll walk through how BitSave Protocol leverages this powerful design pattern to revolutionise on-chain savings.

Before You Begin

To get the most out of this article, you should have:

• Basic understanding of blockchain technology and how transactions work on-chain

• Basic familiarity with smart contracts and their role in decentralised applications

• General knowledge of Solidity or other smart contract programming languages

What Are Smart Contracts?

Before we dive into parent-child architectures, let's establish a foundation.

Smart contracts are self-executing, immutable computer programs that run on a blockchain network. They automatically enforce actions like asset transfers when predefined conditions are met. This means that once these computer programs are deployed to the blockchain, they cannot be altered or deleted.

What Is Inheritance in Smart Contracts?

In blockchain development, inheritance refers to the ability of one smart contract to derive properties, functions, and state variables from another contract. This concept, borrowed from object-oriented programming, allows developers to reuse code and design flexible systems.

When we talk about inheritance in Solidity, we're typically referring to contract inheritance, where a child contract uses the is keyword to inherit from a parent contract. Here’s an example of what that looks like:

contract Parent {
    function greet() public pure returns (string memory) {
        return "Hello from Parent";
    }
}

contract Child is Parent {
    // The Child contract inherits the Parent's greet() function
}

This form of inheritance allows developers to build upon existing, audited contract code without rewriting common functionality. It promotes the DRY (Don't Repeat Yourself) principle and makes the system more secure by using proven code.

Parent-Child Smart Contracts: The Factory Pattern

Here's where things get interesting.

The parent-child pattern in smart contract architecture isn't just about code inheritance, it's about one contract deploying other contracts.

This is commonly known as the Factory Pattern in blockchain development. Here, a factory contract (the parent) has the ability to deploy multiple instances of another contract (the children). Each child contract is a separate, independent smart contract with its own address, storage, and state on the blockchain.

How the Factory Pattern Works

The factory pattern works in the following way:

1. Parent Contract Deployment: The factory (parent) contract is deployed once on the blockchain

2. Child Contract Creation: Users interact with the parent contract, triggering the deployment of new child contracts

3. Independent Instances: Each child contract exists as a standalone smart contract with its own blockchain address

4. Centralised Management: The parent contract typically maintains a registry of all deployed child contracts

5. Isolated State: Each child contract has isolated storage and state, preventing cross-contamination

Here’s a simpler way to look at it:

Let’s say we have a factory (parent) contract named Logistics. This contract is responsible for creating individual transport units (child contracts), such as a Ship or a Truck. Each transport unit is deployed as its own smart contract with a separate address, while the Logistics contract maintains a centralised control logic and a registry of all created units.

The class diagram below paints a better picture:

How BitSave Protocol Uses Parent-Child Smart Contracts

Now that we understand the parent-child or factory pattern, let's look at how BitSave Protocol uses this architecture to create an innovative on-chain savings solution.

What Is BitSave Protocol?

BitSave Protocol is an on-chain savings protocol designed to help income earners save securely using stablecoins. Unlike traditional DeFi protocols that pool user funds into shared liquidity pools, BitSave uses a unique parent-child smart contract architecture that provides security and fund isolation.

Understanding BitSave’s Parent-Child Architecture

When you create a savings plan on BitSave, here's what goes on behind the scenes:

1. Parent Contract (BitSave’s Main Contract)

The parent contract serves as the protocol's central hub. It handles:

• User authentication and onboarding (i.e. wallet connection and savings plan creation)

• Fee collection and management

• Child contract deployment logic

• Protocol-wide settings and parameters

• User-controlled emergency withdrawal logic (executed from users’ child contracts)

2. Child Contract (A User’s Savings Contract)

Here's the innovative part: When a user creates a savings plan, BitSave deploys a dedicated child contract exclusively for that user. This child contract:

• Holds only that user's funds

• Is exclusively accessible via the user's wallet address

• Stores the savings parameters (i.e. lock period, penalty fee, principal amount)

• Executes withdrawals according to the user-defined rules

• Lives independently on the blockchain

Why BitSave Uses This Smart Contract Architecture

BitSave's choice of the parent-child smart contract architecture isn’t random. It directly addresses some of the biggest risks in decentralised savings systems, especially around how user funds are stored, managed, and protected on-chain.

1. Enhanced Security Through Isolation

Traditional DeFi protocols pool all user funds into shared smart contracts. If that contract is exploited, all users lose everything. We've seen this happen repeatedly in DeFi history, from the 2016 DAO hack of $60M worth of Ether (ETH) to countless rug pulls and exploits.

With BitSave's architecture:

• Each user's funds are in a separate contract

• A vulnerability in one user's contract doesn't affect others

• To drain the protocol, an attacker would need to compromise every single child contract individually

• Even if the parent contract is exploited, user funds remain isolated in their child contracts

2. True Non-Custodial Model

BitSave never holds user funds in a central contract. Each user's child contract is controlled solely by their wallet address. This means:

• BitSave cannot access, freeze, or seize your funds

• No third-party custody risk

• You maintain complete ownership

• It aligns with core DeFi principles of self-custody

3. Customizable Savings Logic Per User

Because each user has their own contract, BitSave can support:

• Different lock periods for different users

• Customizable penalty fees (users set 1-5% penalties for early withdrawal)

• Multiple savings plans per user, each with its own child contract

• Recurring deposits and top-ups specific to each plan

4. Easier Fund Management

The architecture makes it simple for users to:

• Track their individual savings without complex accounting

• Create multiple goal-oriented savings plans (Rent, School Fees, Emergency Fund, etc.)

• Withdraw from specific plans without affecting others

• Verify their child contract on block explorers, maintaining transparency

5. Regulatory and Compliance Benefits

Having individual user contracts provides:

• Clear ownership trails for each account

• Easier compliance with potential regulations

• Simple proof of funds for users

• Transparent audit trails per user

Challenges and Trade-offs

1. Higher Deployment Costs

Deploying a new contract requires more gas than writing to an existing contract. Each user creating a savings plan triggers a full contract deployment, which costs more upfront.

2. More Contracts On-Chain

Instead of one shared contract, BitSave deploys a separate child contract per user. This increases the total number of contracts on-chain. Services that index blockchain data and the BitSave frontend must now track thousands of individual contract addresses rather than just one. The upside is that user funds are isolated; the downside is a larger on-chain footprint.

3. Complexity in Upgrades

If BitSave needs to upgrade the contract logic later — say, to add new features or fix inefficiencies — newly deployed contracts can use the updated code, but existing child contracts can't be changed. This means older users might be stuck with outdated contract versions while new users get improved ones.

4. No Yield Generation from Idle Funds

Because user funds are isolated in individual child contracts with no protocol access, BitSave cannot deploy those funds into yield-generating strategies like lending pools or liquidity provision. Traditional savings protocols often offer interest by putting user deposits to work; BitSave deliberately forgoes this to ensure users maintain complete control of their assets at all times, with no smart contract risk from yield strategies or third-party integrations.

However, this is a deliberate trade-off. BitSave’s architecture prioritises fund safety, isolation, and predictable behaviour over architectural simplicity. Rather than aiming for the fewest contracts or lowest gas costs, the protocol focuses on reducing blast radius and ensuring users maintain control over their funds.

Conclusion

The parent-child architecture (or factory pattern) offers a powerful foundation for building the next generation of trust in decentralised systems. By giving each user their own contract, BitSave removes single points of failure, reduces overall risk, and ensures true non-custodial savings.

As the blockchain ecosystem matures, we'll likely see more protocols adopting similar architectures, especially in areas where security, compliance, and long-term value storage matter most.

Whether you're building a savings protocol, a lending platform, or any application managing user assets long-term, the parent-child smart contract architecture deserves consideration. BitSave Protocol has shown us a promising approach: one where every user truly owns their financial future, one contract at a time.