CHG

ChargeCoin – v1.1 ChangeLog

Summary of changes between the original ChargeCoin contract (v1.0) and the upgraded v1.1 implementation.

Contract v1.0: ChargeCoin
Contract v1.1: ChargeCoinV1_1
Standard: ERC-20 + EV charging logic
Table of Contents

1. Upgrade Overview

The original ChargeCoin contract (referred to as v1.0) has been upgraded to ChargeCoinV1_1 (v1.1) to improve security, clarify economic behavior and make the reward system usable.

Main goals of the upgrade:

  • Remove or reduce centralization risk around escrowed user funds.
  • Prevent edge cases where sessions could not be closed correctly.
  • Make user & station rewards claimable instead of purely accounting-only.
  • Align Solidity versioning and architecture with modern best practices.

2. Security-Relevant Changes

2.1 Restriction on rescueERC20 for CHG (Escrow Protection)
Affects Privileges Improves Safety

In v1.0, the rescueERC20 function allowed the owner to transfer any ERC-20 token from the contract, including the native CHG token that is used for user pre-payments (escrow).

In v1.1, the function is updated so that the contract’s own token cannot be rescued:

v1.0 (conceptually)

owner can drain all ERC-20 balances, including escrowed CHG.

v1.1

Additional check added:

require(token != address(this), "Cannot rescue CHG escrow");

Effect: The owner can still recover foreign tokens that were accidentally sent to the contract, but can no longer drain user pre-payments and reward pools by calling rescueERC20.
2.2 Guard Against actualCost > prepayment in stopCharging
Logic Hardening

In v1.0, if the actual cost of a session exceeded the pre-paid amount, the contract could fail to pay the station owner, causing an internal transfer to revert and blocking stopCharging.

In v1.1, a clear rule is enforced to avoid this problematic state:

require(totalCost <= s.estimatedCost, "Total cost exceeds prepayment");

Effect: Sessions where the calculated actual cost would be higher than the pre-payment are not allowed to finalize. This prevents “stuck” sessions caused by internal transfer failures. The business rule can be refined in a future version (e.g. by supporting post-payment for over-usage).
2.3 Solidity Version Pinning
Best Practice

v1.0 used a very broad pragma (>=0.4.16), while relying on modern OpenZeppelin contracts that target the 0.8.x line.

v1.1 pins Solidity to a modern, explicit version:

pragma solidity ^0.8.20;

Effect: Offers more predictable compilation, reduces the risk of accidental compilation with unsafe older Solidity versions and aligns with the OpenZeppelin libraries being used.

3. Business & Logic Changes

3.1 Charging Sessions

v1.0

  • Pre-payment taken via startCharging using an estimated cost.
  • stopCharging computed the actual cost and attempted to:
    • pay the station owner,
    • refund the difference to the user if any.
  • No explicit guard if the actual cost exceeded the pre-paid amount.

v1.1

  • Same high-level flow (pre-pay, then settle), but with:
    • a defensive check that prevents actualCost > prepayment,
    • clearer session states with events.
3.2 Station Accounting

v1.0

  • Station.totalEarnings and rewardPoints existed but were not properly updated.

v1.1

  • totalEarnings is now increased when payments are sent to the station owner.
  • rewardPoints is updated in parallel with station reward accounting.

4. New Features in v1.1

4.1 Claimable User Rewards
New

v1.0

  • User rewards were accounted in rewardBalances but there was no way to claim them.

v1.1

  • A new function claimUserRewards() is introduced.
  • Users can withdraw their pending reward balance in CHG, subject to:
    • non-zero reward balance, and
    • sufficient CHG balance held by the contract as a reward pool.
Note: The protocol (owner / DAO / treasury) is expected to supply CHG to the contract to fund the reward pool for user claims.
4.2 Claimable Station Rewards
New

v1.0

  • Station rewards were tracked in stationRewards but not withdrawable.

v1.1

  • claimStationRewards(stationId) enables the station owner to withdraw their accumulated station rewards.
  • The function is protected by onlyStationOwner, ensuring only the correct owner can claim.
Note: Similar to user rewards, station rewards depend on the contract holding enough CHG as a reward pool.
4.3 Station Management Helpers
New

v1.1 introduces explicit management functions to register stations and toggle their active status:

  • registerStation(...) – creates a station entry with an owner, location, type and hourly rate.
  • setStationActive(stationId, active) – allows the owner (protocol admin) to enable / disable a station.
Effect: Station data is now more explicit and aligned with reward and earnings tracking.

5. Non-Breaking vs Breaking Aspects

5.1 Non-Breaking / Compatible Changes
  • Token name and symbol remain "Charge Coin" / "CHG".
  • Core ERC-20 interface behavior is preserved.
  • High-level charging workflow (pre-pay → charge → stop → settle) conceptually stays the same.
  • Rewards accounting structure (user + station rewards) is extended, not removed.
5.2 Potentially Breaking Changes
  • Owner can no longer use rescueERC20 to withdraw CHG held by the contract. This is an intentional restriction for security.
  • Sessions where the calculated actual cost exceeds the pre-payment will now revert in stopCharging. Frontends and off-chain logic must handle this by ensuring reasonable pre-payments.
  • The contract is deployed under a new name (ChargeCoinV1_1), and therefore uses a different address on-chain. Any integration needs to update the token / contract address accordingly.

6. Migration Notes & Recommendations

When migrating from v1.0 to v1.1, the following plan is recommended:

  1. Define the Token Migration Strategy
    Decide whether:
    • v1.1 will be the only canonical CHG contract going forward, or
    • v1.0 and v1.1 will temporarily coexist during a migration period.
  2. Announce the Upgrade
    Communicate clearly to the community:
    • why the upgrade exists (security, rewards, clarity),
    • what privileges are reduced (no more owner-escrow draining),
    • how rewards can now be claimed by users and stations.
  3. Update Frontend & Off-Chain Integrations
    Ensure:
    • all frontends now reference the v1.1 contract address,
    • any explorer links, analytics, and dashboards are updated,
    • reward claiming UIs call the newly introduced claim functions.
  4. Seed the Reward Pool
    Send CHG to the v1.1 contract address so that:
    • claimUserRewards() and claimStationRewards() can succeed,
    • reward logic is live from day one.
  5. Plan deprecation of v1.0
    Once liquidity, integrations and balances are migrated, decide:
    • whether to pause v1.0 token transfers completely,
    • or keep it only for historical / archival purposes.
This ChangeLog is intended to be read together with the full v1.1 audit report. It does not replace a complete security assessment, but summarizes the most relevant differences between the two contract versions for integrators, users and auditors.

“ChargeCoin: Pay 0.1% Fees & Earn Tokens Every Time You Charge ⚡️”