When you build a token backed by time, there is one question you cannot avoid: which unit of time? One token equals one second? A minute? An hour? A day? A year? The choice is not arbitrary. It has mathematical, economic and communicative consequences that shape the entire model. At beep, we chose the second. This article explains why — and which other design decisions follow from that choice.
The question of granularity
Tokenisation is always an act of discretisation. Something continuous is broken into countable units. For shares, this unit was historically the share itself: one share, one vote, one slice of profit. For bonds, it is the denomination: 1,000 francs per bond, 100,000 per tranche. For crypto tokens, the denomination is often extremely fine — Satoshis in Bitcoin, Wei in Ethereum.
The question is always the same: how small should the smallest unit be? Too coarse, and the token becomes unusable for many cases. Too fine, and the complexity becomes unmanageable.
At beep, the starting point was the idea that every token should represent a unit of real economic power. Robots work in time. The natural unit of their work is a unit of time — and the question was just: which one.
Why not the hour
The hour would be the obvious unit. Hourly wages are how people measure working time. Robots are often rented at hourly rates in practice. An hour is small enough to be flexible, large enough to feel economically relevant.
Three problems argue against it.
First — the token count would be too small. With 8,760 hours per year and a robot fleet that will later consist of thousands of machines, you would have a relatively small quantity of tradable units. This makes the market illiquid. It makes investing small amounts hard — because an hour of robot work can quickly cost twenty or thirty francs, excluding many potential participants.
Second — the hour is not universal. An industrial robot works differently from a service robot. Some tasks take seconds, some take hours. A unit too large makes accounting across different robot types difficult.
Third — the hour has no cultural meaning. It is an administrative unit. A second, by contrast, is what every person experiences directly. It ticks in the phone, in the heartbeat, in consciousness. This is not poetic — it is communicatively serious.
Why not the day or the year
Larger units have the same problems amplified. A day would correspond to 86,400 seconds — the token count per year would then be about 365,000. That is too little to build a globally accessible asset class. A year would be even more absurd. With only a few thousand tokens per year, beep would be nothing but a very coarsely structured limited partnership.
Why the second
The second solves all of these problems.
It is small enough that the annual issuance is 31,104,000 tokens — a number that enables liquid markets and allows entry prices of a few francs. It is universal: every robot type delivers seconds, from industrial arm to humanoid system. It is intuitive: every person understands what a second is, without explanation.
And it has an additional property we particularly value at beep: it connects robot work to human time. One second of robot work is exactly as long as one second of human attention. This equality is not coincidence — it is the core of our long-term vision. In the first step, we make the time of robots liquid. In the second step, also the time of people. For this to work, the unit must be the same.
The 30/360 convention
A second design decision follows from the choice of the second. How many seconds does a year have exactly? The astronomically correct answer would be 31,557,600 seconds — based on a tropical year of 365.2422 days. That is mathematically correct, but communicatively and bookkeeping-wise unusable. A leap year every four years would make annual issuance irregular.
We therefore chose the 30/360 convention — a banking convention used for decades in international bond mathematics. It defines:
- A year has 360 days
- Each month has 30 days
- A day has 86,400 seconds
- A year therefore has exactly 360 × 24 × 3,600 = 31,104,000 seconds
This yields an annual issuance of 31,104,000 tokens — exactly. Every day issues the same amount. Every month is the same. Every year is the same. No February shorter than July. No leap years throwing the system off rhythm.
The 30/360 convention is not poetic. It is the mathematical foundation on which the entire beep model rests.
Why issuance must be fixed
A third design decision follows from the second: issuance must be fixed and unchangeable.
Why not variable? A variable issuance model could in theory have advantages — adjustment to market conditions, response to demand, steering of the token price. In practice, however, every variable issuance leads to two problems.
First — loss of trust. Anyone who can control issuance can also misuse it. Investors must be able to rely on the rules not being changed after the fact. With Bitcoin, the fixed issuance curve is the most important reason for its value. The same principle applies at beep.
Second — scarcity as value anchor. If issuance is fixed while demand grows, structural scarcity emerges. This scarcity is not speculative, but mathematically guaranteed. It is anchored in the smart contract and cannot be changed by any party — not even by beep itself.
We have capped issuance at 31,104,000 tokens per year and locked it in the smart contract. This is not a marketing statement. It is a technical fact every person with blockchain knowledge can verify on the Ethereum chain.
Why ERC-20 instead of ERC-1400
A final design decision concerns the technical standard. We could have implemented the beep token under the ERC-1400 standard, which was specifically developed for security tokens and brings built-in compliance mechanisms. We chose ERC-20 instead — the world’s most widely deployed token standard.
The reason: compatibility. ERC-20 is supported by every wallet, every DeFi application, every crypto exchange working with Ethereum. ERC-1400 is supported only by specialised platforms. If our long-term goal is to establish the beep token in a broad application landscape, we need maximum compatibility.
Compliance requirements — whitelist for KYC-verified addresses, sanctions list screening, transfer restrictions — are handled at beep through a separate compliance smart contract. This is a proven architecture also used by other serious asset token projects in Switzerland. It offers the same compliance security as ERC-1400, but without losing ERC-20 compatibility.
The picture that emerges
When you look at these design decisions together, a clear picture emerges: the beep token is not the product of a single idea, but the product of many decisions all pointing in the same direction.
Second as unit, because it is real and intuitive. 30/360 as convention, because it is mathematically clean and bookkeeping-wise handleable. Fixed issuance, because scarcity creates trust. ERC-20, because compatibility matters long-term.
None of these decisions was inevitable. We could have gone other ways. We chose these because together they form a consistent system — one that is mathematically verifiable, economically robust and long-term stable.
Anyone who designs a token also designs a value system. At beep, these values are transparent: clarity, scarcity, compatibility, long-term stability. They are not in the marketing brochure. They are anchored in the smart contract.
That is the mathematical logic behind tokenising time. It is less spectacular than the vision, less visible than the robot fleet. But it is the foundation on which everything else stands.