What Is ERC1400?
ERC-1400 is a security token standard for regulated instruments. It extends fungible token behaviour with partitions, so a single holding can be split into tranches with different rules, transfer restrictions with machine-readable reason codes, controller operations for forced transfers, and document references attached to the token.
It exists because regulated instruments cannot behave like ordinary tokens. A share transfer may need to be blocked because the recipient is not accredited, is in the wrong jurisdiction, or is inside a lock-up period, and the transferring party needs to know which of those it was.
What You Receive
| Component | What It Covers |
|---|---|
| Partitioned token | Holdings split into tranches carrying their own rules and restrictions |
| Restriction rule engine | Eligibility by investor type, jurisdiction, lock-up and holder cap |
| Reason code layer | Machine-readable explanations for every blocked transfer |
| Controller operations | Governed forced transfer and recovery for legal and key-loss events |
| Document management | Prospectus and terms hash-committed and referenced on-chain |
| Register reconciliation | On-chain holdings continuously matched to the official record |
| Corporate action processing | Distributions, redemptions, splits and consent collection |
| Repository transfer | Contracts, compliance mapping and operational documentation |
Send us your token parameters and distribution plan and we will return contract scope, an audit path and a timeline.
Get a Free Live DemoRestriction Without Explanation Is an Operational Problem
A regulated token that simply reverts a transfer creates a support case every time. The holder does not know whether they are ineligible, the recipient is ineligible, the tranche is locked, or the transfer would breach a holder cap, and nor does your operations team.
That is precisely why ERC-1400 includes canTransfer with reason codes: a transfer can be checked before submission and, when blocked, explained. Implemented properly it turns a compliance failure into a clear message; implemented lazily it becomes a queue of tickets nobody can answer.
Reason codes implemented properly every restriction returns a specific, documented reason.
Pre-transfer checks exposed so interfaces can warn before a transaction is submitted.
Partitions mapped to real tranches lock-ups, classes and rounds represented rather than approximated.
Controller operations governed forced transfers behind multisig with documented legal triggers.
Documents attached on-chain by reference prospectus and terms hash-committed to the token.
Register reconciliation on-chain holdings aligned continuously with the official register.
We implement restriction reason codes and pre-transfer checks fully, because a regulated token that only reverts gives your operations team nothing to work with and your holders nothing to act on.
Surfaces This Scope Covers
Reference concepts for a token build — deployment, distribution and holder surfaces. Not screenshots of a delivered client launch.
What We Build
Standard Implementation
- Partitioned holdings with per-partition rules
- canTransfer and canTransferByPartition with reason codes
- Transfer restriction rule engine by jurisdiction and investor type
- Lock-up and holding period enforcement per partition
- Holder cap and concentration limit enforcement
- Document management with hash-committed references
- Controller operations for forced transfer and recovery
Investor and Eligibility
- Identity and eligibility registry integration
- Accreditation and suitability status tracking
- Jurisdiction rules with configurable matrices
- Whitelist and blacklist management with audit trail
- KYC provider integration
- Investor classification changes with effective dating
Corporate Actions
- Dividend and distribution execution at record date
- Redemption and buyback processing
- Share splits, conversions and reclassification
- Voting and consent collection
- Issuance and cancellation with register reconciliation
- Fee and waterfall calculations
Compliance and Operations
- Audit logging on every privileged operation
- Four-eyes approvals on controller actions
- Regulator reporting exports
- Reconciliation reports against the official register
- Role-based administration console
- Independent audit of restriction and controller logic
Mapped to a release plan
We will send a prioritized build plan with your token parameters, distribution schedule and audit path.
Request a Feature PlanHow ERC1400 Token Development Is Put Together
The modules above map onto these layers. Each one ships with its own tests, documentation and runbook, so nothing arrives as a black box you inherit without an explanation.
Requests flow down, settlement and events flow back up. Every boundary carries logging, so a failure is traceable to a layer instead of guessed at.
Chains and Assets We Work With
Each chain is a separate implementation with its own standard, tooling and supply accounting. Multi-chain issuance needs an explicit chain of record or your reported circulating supply drifts from reality.
How We Build Your Token
Tokenomics are modelled before contracts are written, because the contract only enforces decisions made earlier.
Instrument and rule mapping
With your counsel: tranches, eligibility, lock-ups, holder caps and reporting duties.
Output → rule matrix mapped to the offering documents
Token and restriction design
Partition model, transfer hooks, reason codes and recovery mechanisms specified.
Output → contract specification with compliance mapping
Implementation
Contracts and administration console built with invariant coverage on restriction paths.
Output → tested contracts with a restriction test matrix
Audit and control review
External code review plus a walkthrough of restriction and controller logic.
Output → audit report with control documentation
Issuance and reconciliation
First issuance, register alignment, corporate action rehearsal and reporting setup.
Output → live issuance with reconciliation runbooks
Standards and infrastructure
Development Timeline
| Scope | Timeline | Includes |
|---|---|---|
| Single-tranche instrument | 4 to 6 weeks | Contract, restriction engine, one jurisdiction |
| Multi-partition instrument | 8 to 12 weeks | Several tranches, eligibility matrix, documents, audit |
| With corporate actions | 3 to 5 months | Distributions, redemptions, voting, register reconciliation |
| Full issuance platform | 5 to 9 months | Transfer agent integration, reporting stack, multi-jurisdiction |
What extends the timeline: legal structuring and the eligibility matrix your counsel defines; transfer agent and administrator onboarding; audit of the restriction and controller logic, where errors are compliance failures; and reconciliation tooling against whichever register is authoritative.
Revenue Models
| Model | How It Works |
|---|---|
| Issuance charges | Fees on each tranche or offering brought to market |
| Administration fees | Recurring charges on tokenised value under administration |
| Transfer processing | Fees on approved secondary transfers |
| Corporate action processing | Charges for distributions, redemptions and conversions |
| Reporting services | Statement, tax and regulator reporting fees |
| Platform licensing | Fees from issuers using your infrastructure |
| Permissioned venue fees | Trading fees where you operate the secondary market |
Revenue on regulated instruments is administrative and recurring. It is earned by never getting a distribution or a restriction wrong, which is why the engineering budget sits in reconciliation rather than features.
Related services
Who This Is For
Equity, debt and fund units on-chain.
Tokenising fund interests with tranches.
Issuing SPV equity with lock-ups.
Distributing loan participations.
Offering tokenised securities to clients.
Operating on-chain registers for issuers.
Why Choose Coinsclone
Reason codes implemented in full
Every restriction returns a specific cause, so your operations team and interface can explain a blocked transfer.
Pre-transfer checks exposed
Interfaces can warn before submission instead of leaving holders with an unexplained revert.
Partitions mapped to real tranches
Lock-ups, rounds and classes are represented as the documents describe them, not approximated.
Controller powers governed
Forced transfers sit behind multisig with documented legal triggers and full audit logging.
Registers kept in agreement
Continuous reconciliation with break detection, because divergence is what auditors find first.
Restriction logic audited
External review focused on eligibility and controller code, where an error is a compliance breach.
What Our Clients Say
Operators who launched with us, in their own words. Hover to pause.
A members-only NFT marketplace for Digital Freemasonry
Digital Free MasonryNFT marketplace · delivered and liveNext phase in progress: the ODFT Token and the MasonicVerse platform.
Working with Coinsclone has been one of the best professional experiences I have had in the blockchain industry.
From the very beginning of our NFT Marketplace project until its successful completion, the entire team demonstrated exceptional technical expertise, professionalism, patience, and commitment. Every stage of development was handled with great attention to detail, and every challenge we encountered was approached with a solution-oriented mindset.
Read the full client note
Our project was far from a standard NFT Marketplace. It included custom blockchain architecture, Polygon integration, ERC-721 and ERC-1155 standards, royalty implementation, token-gated access through Masonic Passport, multiple payment methods, marketplace customization, advanced testing, and many unique business requirements. Throughout the entire process, the team consistently delivered high-quality work while maintaining clear communication, transparency, and a strong commitment to excellence.
I would especially like to express my sincere appreciation to Mr. Jeeva, Mr. Bala, Mr. Saravanan, Mr. Veeramani, Mr. Akshay, and the entire development team for their outstanding support, professionalism, responsiveness, and dedication throughout the project. Their technical expertise, patience, and willingness to understand even the most complex business requirements gave us complete confidence during every phase of development.
What impressed me the most was not only their excellent blockchain development skills, but also their ability to understand our vision and transform it into a secure, scalable, and highly professional NFT Marketplace.
For me, Coinsclone is not simply a software development company — they are a trusted long-term technology partner. After successfully completing our NFT Marketplace, we are now preparing to continue our collaboration on the next major phase of the Digital Freemasonry ecosystem, including the development of the ODFT Token and the future MasonicVerse platform.
I highly recommend Coinsclone to anyone looking for a reliable, experienced, and highly professional blockchain development company. They have earned my complete trust and respect, and I sincerely look forward to working with them again on future projects.
Map Your Regulated Instrument
Send us your tranches and eligibility rules and we will return a restriction design mapped to your offering documents.
- Rule matrix drafted against your legal opinion
- Reason codes specified for every restriction path
- NDA in place before any documents are exchanged
Request received
A solution architect will reply within one business day with a scoped proposal and demo link.
Frequently Asked Questions
What is ERC-1400?
A security token standard for regulated instruments, extending fungible token behaviour with partitions, transfer restrictions with reason codes, controller operations for forced transfers, and document references attached to the token.
What are partitions and why do they matter?
They divide a single holding into tranches with different rules, so tokens from a locked private round and tokens from a public tranche can coexist in one balance while remaining subject to their own restrictions.
What are restriction reason codes?
Machine-readable explanations returned when a transfer would fail: recipient not eligible, jurisdiction restricted, lock-up active, holder cap reached. They turn an opaque revert into something your interface and operations team can act on.
How is ERC-1400 different from ERC-3643?
Both target regulated instruments. ERC-1400 emphasises partitions, documents and controller operations, while ERC-3643 centres on an on-chain identity registry with modular compliance rules. We recommend based on your structure and integration requirements.
What are controller operations?
Privileged forced transfers and redemptions, used for court orders, lost keys, death or regulatory instruction. Regulated instruments need them, and they belong behind multisig with documented legal triggers and full audit logging.
Can transfer rules be changed after issuance?
Yes, through a governed rule engine, since eligibility regimes change. Every change is logged and approved under four-eyes controls, because rule changes affect who may hold a regulated instrument.
How are documents attached to the token?
By reference with a committed hash, so the prospectus and terms in force can be proven and cannot be silently substituted, while the documents themselves live in appropriate storage.
Does the on-chain register replace the official register?
No. The official register remains authoritative and the on-chain holdings are reconciled against it continuously, with break detection. Divergence between the two is the failure mode auditors look for.
How are dividends and corporate actions handled?
Executed against holdings at a record date with per-holder statements, including redemptions, splits, conversions and consent collection, all reconciled against the register.
Does an ERC-1400 token need an audit?
Yes, and specifically of the restriction and controller logic, because an error there is a compliance breach affecting who legally holds the instrument rather than a functional bug.
Which chains can it be deployed on?
Any EVM chain, with the choice driven by where your investors, custodians and administrators operate and whether you need public or permissioned infrastructure.
Do I own the contracts and source code?
Yes. Contracts, tests, deployment scripts and documentation transfer on delivery, with compliance mapping documentation for your counsel and auditors.
Estimate Your Build
Pick a scope and the extras you need. Independent audit is the line that cannot be compressed, because a deployed contract cannot be quietly patched.
{{ estSummary }}
Ranges assume decisions arrive on time. Licensing, banking and third-party audits run on their own schedules and we plan around them rather than inside them.
Get This Scoped ProperlyReady to Issue a Regulated Token?
Share your instrument type and jurisdictions and receive a token design mapped to your legal structure with an audit path and timeline.