Token development

A token is a smart contract deployed on a blockchain: a program that records who owns what and under which rules those holdings can move. Developing one means deciding those rules and writing them into code that cannot be changed casually afterwards.

That is a different job from the placement itself — the round, the documentation, the registration — which we cover in token issuance. It makes sense once you know what the token represents and need it to exist on-chain with guarantees; it does not if you are still unsure it solves anything, and there you start with tokenomics.

The standard shapes everything else, so it is settled first.

• ERC-20: fungible, interchangeable units. Utility tokens, points, governance rights or internal units of account.
• ERC-721: unique items with their own identifier, for cases where every unit has an identity: certificates, individual titles, collectibles.
• ERC-1155: several fungible and non-fungible series inside a single contract. Lower gas costs and a simpler inventory when you run many collections.
• ERC-1400 and ERC-3643: designed for instruments with restrictions. They add a register of authorized holders, lock-up periods, transfers conditioned on verified identity and forced recovery of positions.

Choosing between them is not a technical call: if the token behaves as a financial instrument, MiCA does not govern it — securities rules do, LMVSI in Spain and MiFID II — and the contract has to enforce those restrictions inside the transfer itself. Our MiCA/MiFID classifier frames that discussion before any code is written.

Before writing code we settle, in writing, the choices that define the contract for its whole life:

• Supply: fixed, capped or open; who can mint, up to what limit and until when.
• Permissions: separate roles to administer, pause and burn, held by a multisig rather than a single owner account.
• Upgradeability: an immutable contract gives certainty and allows no corrections; a proxy allows fixes and hands significant power to whoever controls the upgrade.
• Pause and blocklists: necessary in regulated setups, hard to justify in a utility token.
• Non-standard behavior: transfer fees, rebases or unusual decimals break integrations with exchanges, bridges and DeFi protocols.

Code ships tested, not merely written:

• Unit tests that cover the failure paths, not only the happy case.
• Invariant testing and fuzzing on the rules that must never break, such as balances always adding up to the supply.
• Static analysis plus manual review of access control, reentrancy, overflows and rounding.
• Testnet deployment, a rehearsal of the real operation and only then the move to mainnet.
• Source code verification on the block explorer and publication of the address.

When the contract will hold real value we add an independent review: smart contract audits. As of July 2026, none of the contracts we have deployed has suffered a known security incident.

You receive the repository with source code and deployment scripts, the test suite, the coverage report, documentation of roles and administrative functions, the verified addresses and an operations runbook.

The mistakes that keep coming back:

• Picking the standard after promising a feature that standard does not support.
• Deploying with the admin key sitting in a single-signature hot wallet.
• Leaving an upgradeable proxy with no timelock and no governance, then finding out during the first due diligence.
• Copying a contract from a public repository without checking how it deviates from the standard.
• Hand-coding transfer restrictions when the project is a security token and ERC-3643 already solves it.