Technical Considerations

ERC-20E introduces specific initialization mechanics and accounting safeguards to preserve deterministic NAV behavior, prevent edge-case failure modes, and eliminate collateral manipulation vectors.

Table of contents

1. Initial Ratio Definition

2. Decimals Harmonization

3. Bootstrapping Mechanism

4. Owner-Restricted Mint Phase

5. Public Activation

6. Surplus Collateral Isolation

---

1. Initial Ratio Definition

Every ERC-20E contract defines an immutable Initial Issuance Ratio r_0:

$$r_0 = \frac{Collateral\ Units}{Token\ Units}$$

This ratio:

• Defines the starting NAV

• Establishes denomination scaling

• Determines minimum viable collateralization

• Cannot be modified post-deployment

The initial ratio is not cosmetic, but a structural parameter required for correct NAV bootstrapping and mathematical continuity.

Read more: Initial Ratio and Contract Initialization

---

2. Decimal Harmonization

ERC-20E requires explicit decimal alignment between the ERC-20E token and the underlying collateral asset (e.g., ETH or ERC-20 assets such as WBTC, DAI, USDC, etc).

Precision scaling is deterministically computed to ensure NAV=TVL/Supply remain dimensionally consistent across differing decimal standards.

This prevents rounding drift, truncation asymmetry, or precision leakage in minting and redemption operations.

Decimal harmonization is resolved at the contract level and remains immutable.

---

3. Bootstrapping Mechanism

After deployment, the contract owner must call:

bootstrapLock()

Function Requirements

The owner must:

1. Deposit collateral equal to the Initial Issuance Ratio

2. Mint exactly 1 token

3. This 1 token is permanently locked within the contract

Example

Initial Ratio:

$$1 : 0.001\ ETH$$

Owner deposits:

$$0.001\ ETH$$

Contract receives:

$$1\ token$$

That 1 token is permanently locked in the contract.

Purpose

This mechanism:

• Prevents total supply from ever reaching zero

• Eliminates division-by-zero NAV edge cases

• Guarantees mathematical continuity

• Ensures NAV can always resume from its last computed value

Even if all circulating supply is redeemed, one token remains permanently in existence.

Importantly:

• The locked token can never be withdrawn

• Subsequently, the collateral backing it can never be redeemed

• The invariant Supply > 1 always holds

This is a structural solvency anchor.

---

4. Owner-Restricted Mint Phase (initMint)

After bootstrapLock() execution, the ERC-20E contract enters an "owner-only minting phase".

During this phase:

• Only the contract owner may execute mint operations

• All minting strictly follows the NAV formula

• Redemptions remain disabled

Issuer fees are excluded during this phase. Protocol fees are applied.

Purpose

This phase enables:

• Controlled supply and liquidity formation prior to public launch

Importantly:

• No discretionary NAV is introduced

• NAV remains fully deterministic

• No alteration of economic invariants occurs

The owner cannot modify NAV logic, only participate in minting.

---

5. Public Activation (depositEnabled)

Upon calling:

depositEnabled()

The ERC-20E contract transitions into fully permissionless mode.

After activation:

• Anyone may mint

• Anyone may redeem

• Issuer and protocol fees apply normally

• The owner permanently loses centralized mint control

This transition is irreversible.

Post-activation, the contract becomes:

• Fully permissionless and decentralized

• Trustless

• Governance-free

• Immutable in behavior

No privileged economic control remains.

---

6. Surplus Collateral Isolation (surplus)

ERC-20E introduces strict separation between:

• NAV collateral (protocolPool)

• Externally received collateral (address(this).balance)

Collateral that enters the contract via the mint function is credited to protocolPool.

Collateral sent directly to the contract address (e.g., mistaken transfers, selfDestruct injections, manual sends) is stored in address(this).balance and does not affect NAV.

NAV Formula Isolation

$$NAV = \frac{protocolPool}{Supply}$$

account.Balance is excluded.

surplus() Function

The owner may call:

surplus()

to withdraw the collateral accumulated in address(this).balance.

---

Structural Invariants

The above mechanisms ensure the following ERC-20E invariants always hold:

1. Supply > 1

2. NAV is never undefined

3. NAV is computed solely from controlled internal accounting

4. External collateral cannot influence NAV

5. Post-public activation, no centralized economic control exists

---

Summary

The ERC-20E bootstrapping and accounting architecture is engineered to:

• Prevent zero-supply edge cases

• Eliminate division discontinuities

• Ensure decimal precision integrity

• Protect against forced collateral manipulation

• Provide a controlled pre-launch liquidity phase

• Transition irreversibly into full permissionlessness

These technical considerations are not auxiliary features, but structural safeguards required to preserve the monotonic, deterministic, and insolvency-proof properties of ERC-20E.