Dora Factory and DORA: migration, Dora Vota and validator roles
Dora Factory uses DORA across its public-goods infrastructure and Dora Vota appchain, with an irreversible migration path from Ethereum ethDORA to the native asset.
Dora Factory’s public-goods focus
Dora Factory describes its role as infrastructure for open-source communities and public-good projects. Its ecosystem includes governance and funding tools rather than a single consumer application. DORA is connected to that infrastructure, but the token’s exact role depends on where it is held: an Ethereum ERC-20 representation and native DORA on the Dora Vota appchain are related assets with different operational contexts.
That network distinction is the first identity check for readers. A wallet displaying DORA does not by itself show whether the balance is ethDORA, native appchain DORA or an unrelated imitation. The migration documentation provides a specific route between the Ethereum and Dora Vota forms, while the developer documentation establishes the native chain denomination and validator environment.
How the ethDORA migration works
Dora Factory documents migration from Ethereum ERC-20 ethDORA to native DORA on Dora Vota. The migration is not merely a bridge transfer between two interchangeable token contracts. The official process burns the submitted ERC-20 tokens and issues the corresponding native asset on the appchain, making destination details and the official migration interface critical before a user authorizes a transaction.
The documentation publishes 0xe4aa3d3282aE54a8677B93885d4e3B8285cCdD6b as the Ethereum migration contract. It is a migration contract, not automatically the canonical token-contract address for every DORA representation. Confusing those roles can lead to incorrect verification. Because migrated ethDORA is described as permanently burned, a mistaken destination or counterfeit interface may create an irreversible loss.
Native DORA on Dora Vota
Dora Vota’s developer documentation identifies peaka as the native denomination and defines one DORA as 10^18 peaka. This is comparable to the relationship between ether and wei: software may process the smaller unit even when interfaces display DORA. The denomination clarifies transaction and development behavior, but it does not establish a separate tradable token named peaka.
Official migration material lists staking, appchain governance, public-good funding and MACI or aMACI voting among the stated uses for native DORA. These uses describe the intended network economy. They do not guarantee that every holder can access every program, that governance proposals will pass or that funding rounds and reward parameters will remain unchanged.
Validators, governance and slashing
Dora Vota validators participate in block production and voting, and the validator documentation also connects them with governance. Running a validator is an operational role rather than a passive token benefit. It requires infrastructure, key management and reliable participation. Delegators and operators should distinguish protocol-level staking mechanics from promotional estimates of rewards, which can change with network conditions.
The same documentation describes slashing for downtime or double-signing. Slashing means validator participation can reduce stake when the operator violates protocol rules or fails required availability standards. That risk extends beyond market-price volatility. Hardware failures, configuration errors, compromised signing keys and duplicated validator instances can all create operational consequences for an otherwise valid native DORA position.
Practical verification and open risks
The durable workflow is to identify the network first, then verify the current official migration contract and destination chain details. Users should not send assets based on a ticker, an old tutorial screenshot or a third-party address. The cited migration contract has a narrowly defined role, and the burn mechanism makes pre-transaction verification especially important. Current chain status and migration availability remain time-sensitive.
DORA exposure includes migration, smart-contract, appchain, validator, governance, custody and market risks. Dora Factory’s sources support its public-goods purpose and the documented native uses, but they do not promise adoption, funding outcomes or returns. Validators face slashing and uptime requirements, while migrating users face irreversibility. Live parameters, supported wallets and official interfaces should be confirmed immediately before use.
Key takeaways
- Dora Factory builds infrastructure for open-source communities and public goods.
- Official documentation describes migration from Ethereum ethDORA to native DORA on Dora Vota.
- Migrated ERC-20 tokens are permanently burned, making verification essential.
- One native DORA equals 10^18 peaka in Dora Vota’s denomination system.
- Validators can be slashed for downtime or double-signing.
YearBull Rank context
Current YearBull Rank for dora-factory-2: #4298.
Rank change (nearest points).
Reading rule: a smaller rank number indicates stronger placement.
- 7d window (2026-10-20): #8834 → #4298 (up by 4536).
- 30d window (2026-09-27): #6273 → #4298 (up by 1975).
YearBull Rank is an internal ordering on YearBull that positions a coin relative to the rest of the tracked universe. A smaller rank number indicates a stronger position at that moment. It is a context signal for relative placement, not an outcome forecast.
Market depth: liquidity often shows up as how easily the rank holds its gains.
Venue context: improvement with higher churn can be a rotation phase.
Stability posture: consistency often matters more than speed.
Trend context: a quick bounce can still be a mean-reversion phase.
