Sebastien Rousseau
Get in touch ›

The making of the Express Transaction Credits Platform

Designing the Express Transaction Credits platform with ERC-223 smart contracts.

8 min read
Banner for: The making of the Express Transaction Credits Platform

Giant white pillars

Executive Summary / Key Takeaways

  • The root problem. ERC-20, the dominant Ethereum token standard in 2018, had a structural flaw: tokens transferred directly to a smart contract address were silently destroyed if the contract lacked a handler. Any payment platform built on ERC-20 inherited that risk (Ethereum EIPs).
  • ERC-223 as the fix. ERC-223 required recipient contracts to implement a tokenFallback(address, uint, bytes) function. If absent, the transfer reverted atomically. No tokens could be silently lost (Ethereum EIPs GitHub).
  • EXTC's five contract primitives. Token identity (name, symbol, 18-decimal precision), fixed supply, ERC-223-compliant transfer, multi-signature corporate disbursement, and block-height time-locked standing orders.
  • The collateral loan mechanism. Borrowers locked EXTC tokens in a contract escrow; the contract released loan proceeds atomically upon receipt of collateral, without underwriting delay or credit-committee approval.
  • What the experiment revealed about Ethereum limits. At mainnet throughput of ~15 TPS and gas costs of $0.10–$1.00 per transaction at the January 2018 peak, a payment network processing even remittance-scale volume was economically and technically infeasible on public Ethereum without Layer-2 infrastructure.

The Design Problem: Why ERC-20 Was Insufficient #

The ERC-20 standard, proposed in 2015 and formalised in Ethereum Improvement Proposal 20, defined the canonical fungible token interface that powered the ICO boom of 2017–2018. Its six core functions — totalSupply, balanceOf, transfer, transferFrom, approve, and allowance — were sufficient for simple token issuance and exchange.

For a payment platform, however, ERC-20 had a production-critical flaw. The transfer(address _to, uint256 _value) function moved tokens to any address, including contract addresses, without triggering any code in the receiving contract. A contract that was not specifically programmed to track incoming ERC-20 transfers had no way to detect them. Tokens sent this way were trapped permanently, with no mechanism for recovery.

The Ethereum community estimated that tens of millions of dollars in ERC-20 tokens had been permanently lost by mid-2018 through this mechanism. Building a payment platform where transfers could silently fail and destroy user funds was not acceptable.

The ERC-223 Solution: Atomic Transfer with Notification #

ERC-223, proposed on the Ethereum EIPs GitHub issue tracker, addressed the silent-loss problem by changing what a token transfer was required to do. Under ERC-223, transfer(address _to, uint256 _value, bytes _data) checked whether the recipient address contained contract code. If it did, the transfer called _to.tokenFallback(address _from, uint256 _value, bytes _data).

The critical property: if the recipient contract did not implement tokenFallback, the entire transfer transaction reverted. No tokens left the sender's balance. No tokens were trapped. The transfer was atomic — it either completed with the recipient's code executing, or it failed entirely with the state unchanged.

For EXTC, this meant:

The EXTC Contract Architecture #

The EXTC token contract was a Solidity implementation structured around five modules:

1. Token Identity #

string public name = "Express Transaction Credits";
string public symbol = "EXTC";
uint8 public decimals = 18;

Eighteen decimal places gave EXTC sub-cent precision, matching the granularity required for micro-payment and micro-loan use cases. The symbol EXTC was the on-chain identifier registered in the token contract.

2. Fixed Total Supply #

Total supply was set at contract deployment and could not be inflated by subsequent mints. This design choice made EXTC deflationary: any tokens permanently removed from circulation — through irreversible burn operations — reduced supply without replacement. The fixed-supply model was standard in 2018 payment token designs, reflecting the Bitcoin-influenced assumption that deflationary pressure was a feature for a medium of exchange.

3. ERC-223 Compliant Balance and Transfer #

The core transfer function implemented the full ERC-223 interface. Internal balance mappings tracked each address's holdings. The isContract(address) helper distinguished EOA (externally owned account) addresses from contract addresses to determine whether tokenFallback needed to be called.

4. Multi-Signature Corporate Disbursements #

Corporate payment workflows required co-authorisation: no single signer could unilaterally initiate a disbursement above a defined threshold. The EXTC contract implemented a two-of-N multi-signature scheme:

  1. A designated initiator proposed a transfer, specifying recipient, amount, and a nonce.
  2. A co-signer confirmed the nonce.
  3. Only after both signatures were recorded on-chain did the transfer execute.

This eliminated single-point-of-failure risk for corporate accounts while keeping the entire authorisation flow on-chain and auditable without a clearing house intermediary.

5. Block-Height Time-Locked Standing Orders #

Recurring payments — salaries, subscriptions, scheduled loan repayments — required a standing-order primitive. EXTC implemented this as a time-lock: a transfer record was stored in the contract with a releaseBlock parameter. The transfer could not execute until the Ethereum block height reached releaseBlock.

Block height as a time proxy was a pragmatic choice in 2018. Ethereum targeted a 15-second block interval, making block height a reasonably reliable proxy for wall-clock time within a range of minutes. Absolute timestamps (block.timestamp) were available but susceptible to miner manipulation within a ±900-second window, making block height the safer reference for financial contracts.

The Collateral-Backed Instant Loan Mechanism #

The EXTC lending primitive was the most complex component. The design:

  1. Borrower locks collateral. The borrower called lockCollateral(uint256 _collateralAmount), transferring EXTC tokens to the lending contract escrow via an ERC-223 tokenFallback.
  2. Loan-to-value ratio check. The contract read a pre-configured LTV ratio (e.g. 50%) and calculated the maximum loan amount against the locked collateral.
  3. Atomic loan disbursement. If the collateral met the minimum threshold, the contract immediately transferred the loan amount to the borrower's address. No underwriting queue, no credit committee, no settlement delay.
  4. Repayment and release. On repayment — principal plus a fixed interest rate — the contract released the collateral back to the borrower. Failure to repay by releaseBlock triggered automatic liquidation: the contract transferred the collateral to the lender's designated address.

The entire flow was enforced by contract code. Neither party needed to trust the other or rely on an intermediary to enforce terms.

What the Experiment Revealed #

The EXTC contract architecture was technically coherent. ERC-223 resolved ERC-20's most serious safety flaw. The multi-signature and time-lock primitives mapped directly to real corporate payment workflows. The collateral loan mechanism demonstrated that secured lending could be fully automated and self-enforcing on-chain.

Two constraints revealed themselves in practice:

Gas costs. At the January 2018 peak, Ethereum gas prices reached 50–100 gwei, making a single ERC-223 token transfer cost $0.50–$2.00. For micro-payments or remittances of $10–$50, those fees were prohibitive.

Throughput. The Ethereum mainnet block gas limit in early 2018 was approximately 8 million gas. An ERC-223 transfer consumed roughly 50,000–80,000 gas. The network could therefore process approximately 100–160 EXTC token transfers per block, or roughly 7–11 per second at the 15-second block interval. Payment network scale — hundreds or thousands of transactions per second — was not achievable on public Ethereum without Layer-2 infrastructure that did not yet exist in production form.

These were infrastructure constraints, not design flaws in EXTC. The contract logic was correct. The underlying blockchain could not yet support payment volume at financial-industry scale.

The Ideas That Reached Production #

Several design patterns from EXTC were validated by subsequent development:

Atomic token transfer with receiver notification — the core ERC-223 property — became the basis for ERC-777 (2019), which extended the notification model and was later incorporated into DeFi lending protocols. The tokenFallback pattern appears throughout modern DeFi architecture.

Multi-signature authorisation for corporate disbursements — the pattern of requiring multiple on-chain signatures before execution — became the standard model for DAO treasury management and institutional custody solutions. Gnosis Safe, launched in 2018, popularised this pattern at scale.

Collateral-backed instant loans without intermediaries — the mechanism of locking collateral in escrow and releasing loan proceeds atomically — is the fundamental design of DeFi lending protocols such as Compound (2018) and Aave (2020).

Block-height time locks for scheduled payments — the pattern of encoding future execution timing in the contract — appears in token vesting contracts, delayed governance proposals, and time-weighted average price (TWAP) oracle designs across the DeFi ecosystem.

The EXTC experiment did not reach production scale. The infrastructure required to make the design viable took three to five more years to mature. The design questions it asked were the right ones for 2018.

Questions? Answers.

Why was ERC-223 never adopted as the dominant token standard despite fixing ERC-20's flaw?

ERC-223 required recipient contracts to implement tokenFallback, breaking backwards compatibility with the thousands of contracts already deployed for ERC-20 tokens. The existing ERC-20 ecosystem was too large to migrate. Subsequent proposals — notably ERC-777 and ERC-1363 — addressed the same problem with different compatibility trade-offs, but ERC-20 remained dominant through a combination of network effects and the introduction of wrapped token patterns that avoided the silent-loss scenario.

What happened to the EXTC token and platform?

EXTC was a proof-of-concept and early research project from 2018. The wider ICO and payment token market contracted sharply through 2018–2019 as Ethereum scalability limits and regulatory uncertainty became clear. The ideas embedded in the EXTC design resurfaced in later protocols that had access to Layer-2 infrastructure, better tooling, and clearer regulatory frameworks.

How does EXTC's collateral loan model compare to modern DeFi protocols like Aave?

The core mechanism is the same: lock collateral, receive a loan sized against an LTV ratio, repay or face liquidation. The differences are: (1) modern DeFi protocols use oracle price feeds for dynamic LTV rather than fixed ratios; (2) they use algorithmic interest rates that respond to pool utilisation; (3) they operate on Layer-2 networks with gas costs 10–100 times lower than 2018 mainnet; (4) Aave and Compound have undergone formal security audits and held billions of dollars in liquidity, providing empirical validation that the basic model is sound.

What were the Solidity version constraints in early 2018?

The EXTC contract was written for Solidity 0.4.x, the dominant version in early 2018. Solidity 0.4 lacked many safety features introduced in later versions: integer overflow checking (added automatically in 0.8.0), require/revert with error messages (limited in 0.4), and explicit function visibility (default was public in 0.4). The contract relied on OpenZeppelin's SafeMath library to guard against overflow, a common pattern before the compiler enforced this natively.

References #

Last reviewed .