Technical Documentation: Step Bonding Curve Testing

How we tested for our AI Coins

Introduction

This document details the testing methodology, procedures, and outcomes for verifying the robustness of a smart contract implementing a step bonding curve. A step bonding curve governs the pricing of a tokenized asset by adjusting token prices incrementally with each buy or sell order, ensuring predictable and transparent valuation.

We have identified several key objectives for this testing phase:

1. Ensuring Robustness of the Smart Contract We aim to validate that the smart contract correctly handles state changes, processes valid transactions, rejects invalid transactions, and remains free from known vulnerabilities.

2. Verifying Reserve Balance Sufficiency The step bonding curve design requires a reserve of underlying assets (e.g., a stable coin or base cryptocurrency) to honor all sell orders. One goal is to confirm that the reserve balance remains sufficient in various market conditions.

3. Providing Transparency in Platform Fee Deductions The smart contract deducts fees for the platform whenever a buy or sell transaction occurs. Testing confirms that these fees are applied as expected and can be transparently tracked on-chain.

4. Proving Payments for the AI Persona A portion of each transaction’s fees is allocated to fund the AI Persona’s operational costs, ensuring its “immortality” by covering server, API, or licensing fees. This test verifies that each transaction correctly routes the AI Persona’s share of payments.

5. Proving the Revenue Stream for Persona Owners In addition to operational costs, the AI Persona owners receive revenue. Testing demonstrates that the ownership revenue is correctly distributed whenever a transaction occurs.

A link to a spreadsheet containing all test run data will be provided as part of the final documentation. Additionally, three diagrams are referenced to illustrate price movements during buys, price movements during sells, and randomized buy/sell “walks” to confirm that the reserve never depletes. Finally, edge cases are considered to ensure the token balances and contract states remain consistent even under extreme conditions.

Objectives and Scope

• Objective A: Confirm that all state-altering functions (buy, sell, fee distribution) operate as designed.

• Objective B: Validate that the reserve always covers user sell orders, regardless of market activity.

• Objective C: Confirm that platform, AI Persona, and Persona owner fees are deducted accurately, verifiable on-chain, and accounted for in internal bookkeeping.

• Objective D: Document how the smart contract supports the AI Persona’s continual operation by verifying payment flows.

• Objective E: Demonstrate correct revenue disbursement to Persona owners.

Scope

This test plan addresses only the smart contract’s token and fee logic within the step bonding curve ecosystem. It does not cover:

• Off-chain user interface testing (e.g., front-end integration).

• Underlying blockchain infrastructure (aside from its role in transaction validation).

• Non-functional aspects such as performance beyond required throughput to demonstrate stress test scenarios. Testing Approach

  Our testing approach integrates unit tests, integration tests, and scenario-based tests:

  1. Unit Tests

     • Validate individual functions such as mint(), burn(), and withdraw().

     • Confirm that each function handles boundary conditions (e.g., zero tokens purchased, extremely large token amounts, insufficient user balances).

  2. Integration Tests

     • Combine multiple actions in a single flow to replicate real-world behavior. For instance, test a buy immediately followed by a sell to confirm correct net balances.

  3. Scenario-Based Tests

     • Follow multi-step user journeys with random buy/sell orders.

     • Introduce stress testing to check for contract stability under heavy volumes.

  By combining these approaches, we capture the most critical contract behaviors and ensure comprehensive coverage.

  Test Environment

  1. Blockchain Test Network All tests are executed on a test blockchain or private local instance (e.g., Ganache or a dedicated testnet environment such as Ethereum’s Goerli). This environment offers the same functionality as mainnet but ensures that we can freely interact with the contract without incurring significant fees or exposing the real deployment to potential risks.

  2. Development Framework

     • Smart Contract Language: Solidity (assumed for demonstration, though testing principles apply to any EVM-compatible language).

     • Testing Tools: Truffle, Hardhat, or Foundry (depending on the development toolchain of choice).

     • Continuous Integration: GitHub Actions or similar pipelines to run tests on each new pull request or code commit.

  3. Test Data Storage

     • A dedicated spreadsheet logs input parameters, transaction details, gas usage, final balances, and notes on pass/fail outcomes.

Detailed Test Scenarios

Below are the principal scenarios tested. Each scenario’s results are compiled in the spreadsheet referenced in the final documentation.

Scenario 1: Baseline Buy Operation

Objective: Verify that purchasing tokens increases the user’s token balance, updates the contract’s reserve, and deducts the correct fees.

1. Preconditions

   • User has sufficient funds in their wallet (e.g., ETH or the stablecoin accepted by the contract).

   • Contract is deployed with an initial reserve and an initial step price.

2. Test Steps

   1. Call mint() with a specified amount.

   2. Confirm the user’s token balance increases accordingly.

   3. Verify that the contract’s reserve balance also increases.

   4. Check that platform fees, AI Persona fees, and Persona owner fees are correctly deducted from the total purchase.

   5. Inspect on-chain logs for fee distribution events, verifying that the amounts match the expected percentage splits.

3. Expected Results

   • The user’s balance of the bonding curve token equals the purchased amount.

   • The contract’s reserve is incremented by the net payment (minus fees).

   • Events and logs show the correct fee distribution.

Scenario 2: Baseline Sell Operation

Objective: Validate that selling tokens reduces a user’s token balance, provides the correct stablecoin (or base cryptocurrency) return, and deducts the appropriate fees.

1. Preconditions

   • User holds the bonding curve token from previous transactions.

   • The reserve has enough funds to cover the sell order.

2. Test Steps

   1. Call burn() specifying the number of tokens to sell.

   2. Confirm the user’s token balance decreases by the sold amount.

   3. Verify that the user receives the correct stablecoin amount (minus fees).

   4. Inspect logs for fee distribution events (platform, AI Persona, and Persona owners).

3. Expected Results

   • The user’s token balance is reduced precisely by the sell amount.

   • The user’s stablecoin balance is incremented, factoring in the correct price per token at the time of the transaction.

   • Fee events indicate correct deductions and distribution to platform, AI Persona, and Persona owners.

Scenario 3: Price Increase During Consecutive Buys

Objective: Demonstrate how the step bonding curve raises the token price as more tokens are bought.

1. Preconditions

   • Several consecutive buy orders will be placed from multiple user accounts.

   • Initial price step is well-defined in the contract.

2. Test Steps

   1. Users A, B, and C each call mint() sequentially.

   2. Track how the token price evolves (view via a getter function or contract event logs).

   3. Compare the final token price after each buy with the expected step increments.

3. Expected Results

   • Each buy order leads to an incremental increase in the token price.

   • The final token price matches the theoretical outcome of consecutive buys as per the step function.

   • The chart (Diagram 1 in the final documentation) will visualize these increments, confirming the correctness of the logic.

Scenario 4: Price Decrease During Consecutive Sells

Objective: Confirm that token prices adjust downward in discrete steps when sell orders occur.

1. Preconditions

   • Multiple users already hold tokens from previous purchases.

   • The current token price is at a level higher than the initial price.

2. Test Steps

   1. Users A, B, and C each call burn() in sequence.

   2. Observe the price dropping in step increments.

   3. Verify that each user receives the correct sale proceeds, minus fees.

3. Expected Results

   • Each sell order causes a step-based decrease in the token price.

   • Diagrams and logs confirm that the token price transitions to the expected lower step after each sell.

   • Diagram 2 in the final documentation will illustrate the decrement path.

Scenario 5: Randomized Buy/Sell Walk with Reserve Validation

Objective: Prove that in a series of random buy and sell actions, the contract’s reserve never drops below zero and continues to honor all sells.

1. Preconditions

   • The contract starts with a calculated reserve, consistent with the maximum expected sell liability.

   • Multiple user accounts with different token holdings and stablecoin balances.

2. Test Steps

   1. Generate a random sequence of buy/sell instructions.

   2. Execute each instruction, capturing the contract’s reserve after each transaction.

   3. Log all final balances (users’ tokens, users’ stablecoins, contract reserve).

3. Expected Results

   • At no point in the sequence does the contract’s reserve become insufficient to execute a sell.

   • Even with highly volatile random sequences, the bonding curve ensures the reserve remains intact.

   • Diagram 3 in the final documentation visualizes these random buy/sell fluctuations while tracking the reserve to confirm it remains above zero.

Scenario 6: Fee Transparency and Distribution

Objective: Validate that all fees are handled consistently and in a transparent manner.

1. Preconditions

   • Known fee percentages for the platform, AI Persona, and Persona owners.

   • Logging events set up to track and identify fee distribution.

2. Test Steps

   1. Execute a series of buys and sells.

   2. Retrieve the logs or use a read function to see how fees were split.

   3. Check if the platform’s fee address, the AI Persona’s fee address, and the Persona owners’ addresses received the exact amounts.

3. Expected Results

   • Each transaction triggers a fee distribution matching the configured percentages.

   • The distribution is visible on-chain, ensuring full transparency.

   • The sum of individual fees matches the total fee percentage from the transaction.

Scenario 7: Proof of AI Persona Payments

Objective: Show that part of the fees are automatically allocated to the AI Persona’s operational account, ensuring funding continuity.

1. Preconditions

   • The AI Persona has a dedicated wallet address for receiving funds.

   • Contract logic includes a function that automatically routes a fraction of the transaction fee to this address.

2. Test Steps

   1. Execute multiple transactions in varying amounts.

   2. Verify that the AI Persona’s address balance increases by the expected fraction after each transaction.

   3. If the AI Persona’s address triggers further off-chain resource payments, log or verify that this step is initiated or recognized.

3. Expected Results

   • The AI Persona’s address consistently receives the correct portion of fees.

   • This can be traced on-chain or via the test spreadsheet to confirm continuity.

Scenario 8: Proof of Persona Owners’ Revenue Stream

Objective: Demonstrate that the remaining portion of fees earmarked for the Persona owners is correctly distributed.

1. Preconditions

   • A set of owner addresses is defined in the contract.

   • Ownership percentages or allocations are established.

2. Test Steps

   1. Trigger multiple buy and sell transactions.

   2. Inspect the distribution logs or on-chain events for ownership revenue splits.

   3. Confirm that each owner address receives the correct proportional share.

3. Expected Results

   • The owners’ revenue matches the total transaction fee minus platform and AI Persona fees.

   • Each owner address obtains funds according to the ownership distribution.

Scenario 9: Edge Case Testing

Objective: Validate contract behavior under extremes or atypical inputs to ensure no disruptions or logical failures.

1. Preconditions

   • A range of edge conditions, such as zero tokens in supply, maximum token supply near integer overflow boundaries, or minimal reserves.

2. Test Steps

   • Edge Case A: Buying tokens when the current supply is near an upper cap (if any).

   • Edge Case B: Selling all tokens held by a user, leaving them with zero balance.

   • Edge Case C: Attempting to sell more tokens than the user holds, expecting rejection by the contract.

   • Edge Case D: Attempting to buy tokens with insufficient funds in the user’s wallet.

   • Edge Case E: Confirm that all fees are zero if the transaction is free of charge (hypothetical scenario if fees are toggled off).

3. Expected Results

   • The smart contract correctly rejects or reverts invalid transactions.

   • Price does not behave erratically or break the logic of the step function.

   • No integer overflows or rounding errors cause unexpected results.

Additionally, three diagrams (plus edge-case illustrations) will be provided:

1. Diagram 1: Price Increases with Buys Shows how consecutive buys push the price higher in step increments.

2. Diagram 2: Price Decreases with Sells Depicts the stepwise downward price movement triggered by a series of sells.

3. Diagram 3: Random Buy/Sell Walk Visualizes a random sequence of buys and sells across multiple addresses. It tracks both the spot price and the reserve, evidencing that the reserve remains sufficiently funded in all scenarios.

References

• Spreadsheet Link: Tobeprovidedinfinaldocumentationpackage.To be provided in final documentation package.Tobeprovidedinfinaldocumentationpackage. This spreadsheet logs all test runs, input parameters, transaction results, and pass/fail outcomes.

• Diagrams:

  1. Diagram 1: Price Increase with Sequential Buys

  2. Diagram 2: Price Decrease with Sequential Sells

  3. Diagram 3: Random Buy/Sell Walk & Reserve Tracking

  4. Edge Cases: Graphical Representation of Token Balances under Extreme Conditions

Each diagram visually supports the scenarios and confirms the underlying mathematics of the step bonding curve in practice.