ERC-1450: RTA-Controlled Security Token Standard

ERCs
1

Hello Magicians! I’m excited to share our work on regulated security tokens.

Abstract

This EIP introduces a token standard for securities that require regulatory compliance under SEC regulations (Reg CF, Reg D, Reg A+). The standard enforces Registered Transfer Agent (RTA) exclusive control over all token operations, implementing a request/review/execute workflow that ensures compliance checks before any transfers occur.

Motivation

Current token standards like ERC-20 were designed for utility tokens and lack the necessary controls for regulated securities. Direct peer-to-peer transfers bypass compliance requirements, creating regulatory risks. Security tokens need enforced KYC/AML checks, transfer restrictions, recovery mechanisms, and complete audit trails.

This standard is based on StartEngine’s operational experience with $1B+ in compliant security token offerings, addressing real-world requirements from 5+ years of production usage.

Specification

Check out the full specification on GitHub:

ERC Draft: https://github.com/ethereum/ERCs/pull/1335

The complete reference implementation can be found here.

Key Features

  • Transfer request system with RTA approval workflow
  • Multi-sig security through RTAProxy pattern
  • Court order execution and lost wallet recovery
  • Configurable fee management
  • Account freezing for compliance

Would love to see an insightful discussion rolling!

6 Likes
2

Hello everyone,

Following our initial post, we’ve made significant enhancements to the ERC-1450 reference implementation based on early feedback and production requirements. Here’s what’s new:

  1. UUPS Upgradeability Pattern
    We’ve added fully upgradeable versions of both contracts:

  2. Security Improvements

  • Fixed critical vulnerabilities in transfer request processing
  • Added replay attack protection
  • Implemented time-lock features for sensitive operations
  • Multi-sig bypass vulnerabilities patched
  1. Fee Function Improvements
  • Updated getTransferFee() to match specification exactly
  • Better handling of fee collection in transfer requests
  • Support for batch operations with fee optimization

:memo: Links

Best,
Devender

3

Hello everyone,

Quick update on ERC-1450’s progress:

PR Status (Update ERC-1450: Move to Draft by devender-startengine · Pull Request #1335 · ethereum/ERCs · GitHub):

  • All CI checks passing (EIP Walidator, CodeSpell, Markdown Linter, HTMLProofer, Link Check)
  • John Shiple (@johnshiple), the original 2018 author, has reviewed and approved the PR
  • Currently awaiting editor review from @g11tech, @SamWilsn, or @xinbenlv

Reference Implementation Update:
Since our last post, the GitHub - StartEngine/erc1450-reference has matured significantly:

  • 643 passing tests across 38 test files
  • 86%+ branch coverage
  • Active security audit underway with Halborn
  • Clean static analysis (Mythril, Slither)

We believe the specification is ready for review. The standard addresses a real gap in the ecosystem—there’s currently no ERC that properly handles SEC-regulated securities with RTA-exclusive control, which is a legal requirement for compliant security tokens in the US.

We’d welcome any technical feedback from the community, and respectfully request editor attention when bandwidth permits.

Thank you!

4

We’d love community feedback on a few design decisions:

  1. RTA-Exclusive Control vs Shared Control: ERC-1450 gives the RTA
    exclusive control over transfers. ERC-3643 uses a validator system.
    What are the tradeoffs for US-regulated securities specifically?

    @TokenySolutions - curious about your experience here.

  2. Fee Token Design: We use a single fee token (e.g., USDC) rather
    than multiple accepted tokens. This simplifies validation but reduces
    flexibility. Thoughts?

  3. Recovery Mechanism: We rely on controllerTransfer() for
    court-ordered transfers rather than a separate recovery system.
    Is this sufficient for regulatory requirements?

  4. Compatibility with ERC-3643: Has anyone explored interoperability
    between RTA-controlled (ERC-1450) and validator-controlled (ERC-3643)
    security tokens?

Reference implementation (643 tests, Halborn audit in progress):
GitHub - StartEngine/erc1450-reference

cc @adamdossa @vladimirfomene

5

Subject: ERC-1450 Update: Halborn Audit Complete :white_check_mark:

Hello everyone,

Exciting update on ERC-1450:

Security Audit Complete

The Halborn security audit has been finalized (December 2025) with 100% of findings addressed:

Severity Count Status
Critical 1 :white_check_mark: Solved
High 0 -
Medium 0 -
Low 6 3 Solved, 3 Risk Accepted
Informational 11 1 Solved, 10 Acknowledged

The critical finding (fee bypass vulnerability) was resolved by implementing a single ERC-20 fee token design. Full report will be published by Halborn shortly.

Key Remediations:

  • Single ERC-20 fee token design (simplified, more secure)
  • .transfer() → .call() for ETH transfers
  • 7-day expiration for multisig operations
  • Double rejection prevention

Reference Implementation: GitHub - StartEngine/erc1450-reference

  • 643 tests passing
  • 86%+ branch coverage
  • Production-ready

PR #1335 is updated and ready for editor review.

Thank you!

6

Update: Security Audit Complete & Ready for Editor Review

Hi everyone,

Sharing a status update on ERC-1450. Since our last post, we’ve hit several key milestones:

Security Audit (Halborn, Dec 2025)

  • 1 Critical finding — Solved
  • 0 High/Medium findings
  • 6 Low findings — 3 Solved, 3 Risk Accepted
  • 11 Informational — 1 Solved, 10 Acknowledged

Full audit report is available in the reference implementation repo.

Reference Implementation

  • 643 passing tests across 38 test files
  • 86%+ branch coverage
  • Mythril & Slither static analysis clean
  • Production-deployed on Polygon mainnet

PR Status

  • ERC PR #1335 has all author approvals (including original author John Shiple)
  • EIP Walidator, CodeSpell, Markdown Linter, and Link Check all passing
  • Awaiting 1 editor review f@g11techom @g11tech, @jochem-brouwer, @SamWilsn, or @xinbenlv

We’d welcome any feedback on the specification itself — particularly around the transfer request lifecycle, multi-sig RTA proxy pattern, or the fee structure design. Happy to answer questions or
clarify any aspect of the standard.

Thank you!
Devender

7

Update — June 2026

Two additions to the public record for this standard:

White paper now publicly available. We’ve published a general overview of ERC-1450 on the StartEngine blog, alongside the full white paper and the audited reference implementation:

Production usage continues to grow. The standard is live on Polygon mainnet behind 400+ deployed securities (RTA proxy + token contract pairs), operated under our SEC-registered transfer agent.

On the process side: PR #1335 remains ready for editor review, and I’ll be attending EIP Editing Office Hours Meeting #102 (June 16) to discuss it — including whether editors would prefer the status change split into a minimal diff with content follow-ups. If you have feedback on the spec itself, this thread is the place.

8

Update — ERC-1450 is now officially in Draft :tada:

PR #1335 (Stagnant → Draft) merged on June 11 after editor review. Thank you to @xinbenlv for the review, and to the EIP Editing Office Hours crew for carrying this on the agenda.

We also merged a follow-up, PR #1811, which marks the document-management and structured-recovery components as OPTIONAL extensions. With that change, the normative core of the spec exactly
matches the audited reference implementation (v1.17.0, Halborn, Dec 2025) that runs in production on Polygon mainnet behind 400+ securities — every deployed contract reports version() = 1.17.0 on-chain. The required baseline for lost-wallet recovery and court-ordered transfers remains controllerTransfer; the time-locked recovery workflow with on-chain evidence anchoring is available for deployments that want it.

Next step: we plan to move the spec to Review in the coming weeks to formally invite peer review.

Feedback on the specification is very welcome — especially from teams building transfer-agent, RWA, or compliant-securities infrastructure who’d like to evaluate or adopt the standard. Happy to answer questions here or walk through the design on a call.

9

Update — ERC-1450 is now in Last Call. :smiley:

We’ve opened PR #1835 to move ERC-1450 from Review to Last Call.

This is the final review window before the spec is frozen at Final, and we’d genuinely welcome scrutiny of the text now — anything ambiguous or unsafe to freeze is much cheaper to fix today than after.

Why we believe the spec is ready to freeze:

  • Stable in production for ~6 months. The audited reference implementation (v1.17.0, Halborn, Dec 2025) has run unchanged on Polygon mainnet since December 2025 — zero contract changes since release. version() on any live contract returns 1.17.0, identical to the public reference repo HEAD.
  • Proven at scale. 410 securities from 275 companies are deployed as ERC-1450 tokens (over $705M in capital raised); 259 have live on-chain supply — 389M+ shares, 208,000+ holders, 3,892 on-chain mint operations, zero open failures.
  • Tested and audited. 643 tests passing, 86.2% branch coverage; Halborn findings 100% addressed (including the one critical), with a separate audit covering the post-audit single-fee-token redesign.
  • Spec matches implementation. Following #1811 (which marked document-management and structured-recovery as OPTIONAL extensions), the normative core now exactly matches the audited deployment. A line-by-line read of the merged spec against v1.17.0 found no spec↔implementation conflicts in the normative core.

Reference implementation (public): GitHub - StartEngine/erc1450-reference: Reference implementation of ERC-1450 — an SEC-compliant, RTA-controlled security-token standard. Halborn-audited UUPS contracts with multi-sig transfer authority. · GitHub

Feedback is especially welcome from anyone building transfer-agent, RWA, or compliant-securities infrastructure who’d like to evaluate or adopt the standard. We don’t plan to make any normative changes during the Last Call window, so this is the moment to raise concerns.

Thank You!!

10

Hello @devender-startengine,

Thanks a lot for your work on this standard and for pushing the standard further.

Some feedbacks if it is not too late:

ERC-1643
Since ERC-1450 uses ERC-1643, for information, I have made a PR to advance the standard further, which does not appear in the Ethereum repository. My new draft version does not change the interface and it is compatible with the one you use for ERC-1450

burnFrom

Not a big problem for me, but for information:
burnFrom(address,uint256) shares an identical function selector with OpenZeppelin’s ERC20Burnable.burnFrom, yet the two carry fundamentally different semantics: the OpenZeppelin function performs an allowance-based holder burn, whereas ERC-1450 defines it as a discretionary burn executed by the RTA. Because the selectors coincide while the underlying trust models are opposed, integrators relying on interface detection or generic tooling may invoke the function under incorrect assumptions.

The interface is monolithic

IERC1450 bundles, in a single interface, everything: ERC-20, an ERC-1643 document subset,
ERC-1644 controller operations, a fee engine, a broker registry, a transfer-request state
machine, recovery workflow, per-lot regulation tracking, account freezing, and optional
EIP-3668 pre-checks.

This is a lot of different interface and it could make sense to split the standard into several different interfaces inherited by a final ERC-1450 token

Here is the interface from the standard.

Only two interfaces are inherited: IERC20 and IERC165 while it could be possible to use more interfaces such as IERC-1643

interface IERC1450 is IERC20, IERC165 {
    // ============ ERC-6093 Standard Errors ============
    // Using standard errors from ERC-6093 for consistent tooling support

    // Standard ERC-20 errors (from ERC-6093)
    error ERC20InsufficientBalance(address sender, uint256 balance, uint256 needed);
    error ERC20InvalidSender(address sender);
    error ERC20InvalidReceiver(address receiver);
    error ERC20InvalidApprover(address approver);
    error ERC20InvalidSpender(address spender);
    error ERC20InsufficientAllowance(address spender, uint256 allowance, uint256 needed);

    // Standard Access Control errors (from ERC-6093)
    // NOTE: We retain OpenZeppelin error names for tooling compatibility, but semantics differ:
    // - "Owner" in ERC-1450 means "Issuer" (the entity that created the token)
    // - Unlike OpenZeppelin's Ownable, only the RTA can change the issuer, not the issuer themselves
    error OwnableUnauthorizedAccount(address account);  // Non-issuer attempts issuer-only operation
    error OwnableInvalidOwner(address owner);  // Invalid issuer address (e.g., zero address)

    // ============ ERC-1450 Specific Errors ============
    // Custom errors only when ERC-6093 standard errors are insufficient

    error ERC1450TransferDisabled();  // For disabled transfer/approve functions
    error ERC1450OnlyRTA();  // Operation restricted to RTA only
    error ERC1450TransferAgentLocked();  // RTA proxy is locked from changes
    error ERC1450ComplianceCheckFailed(address from, address to);  // KYC/AML failure
1 Like
11

ERC-1450 is now Final. :tada:

The Last Call period closed on 2026-07-14 with no normative changes, and the status-only PR to Final has now merged. ERC-1450 has completed the full ladder — Draft → Review → Last Call → Final. Thank you again to @xinbenlv and the EIP Editing Office Hours crew.

@AccessDenied403— thank you so much for the thoughtful review ; responses to your three points:

  1. ERC-1643.
    Glad to hear your new draft keeps the interface stable and stays compatible with the subset ERC-1450 uses — that’s exactly what we’d hoped for. We’ll track your PR and align documentation references to it as it advances.

  2. burnFrom selector collision.
    You’re right that burnFrom(address,uint256) collides with OpenZeppelin’s ERC20Burnable.burnFrom while carrying opposite semantics (discretionary RTA burn vs. allowance-based holder burn). This is a real interoperability sharp edge. Two things mitigate it in practice: an ERC-1450 token is not ERC-20-transferable at all (transfer/approve/transferFrom revert, and supportsInterface deliberately returns false for the ERC-20 interface ID), so tooling that keys off ERC-165 detection won’t mistake it for a standard burnable ERC-20. But naive selector-based tooling is a fair concern, and it’s now noted for the errata/Security-Considerations record.

  3. Monolithic interface.
    Agreed this is the main design trade-off. The single IERC1450 was chosen so that “conformant ERC-1450 token” is one unambiguous detection target for the regulated-securities use case, matching the audited production deployment one-to-one. Interface segregation (splitting out document management, controller ops, fee engine, etc. as separately-inheritable interfaces) is a legitimately better shape for composability, but it’s a structural change we can’t fold into a now-Final spec. It’s a strong candidate for a companion/successor interface-segregation ERC, and I’d be glad to collaborate on that with you given your ERC-1643 work.

Feedback stays welcome — the spec is frozen, but the surrounding tooling and companion-standard conversation isn’t.

1 Like