The short answer
A credible Solana launch for an existing EVM application is an account-model redesign plus a tooling decision, not a recompile. Cryptuon starts with a paid assessment of your real contracts, decides per contract whether to port, redesign, or leave it on EVM, and then delivers tested Solana programs against acceptance criteria you sign off before any build starts.
The tooling — SolScript, Solang, Neon EVM, or a native Anchor rewrite — is chosen after we have read your code, not before.
Decision criteria
The questions that decide cost and approach:
How much state lives in mappings and dynamic arrays?
Solidity hides storage layout. Solana makes it explicit: every piece of state lives in an account that must be created, sized, funded for rent exemption, and passed into each instruction. A mapping(address => uint256) usually becomes one PDA per key. That is mechanical. A mapping(address => Position[]) that grows without bound is not mechanical, and needs a redesign: paging, a zero-copy account, or moving history off-chain.
Do any flows exceed Solana’s per-transaction limits?
- Transaction size: 1,232 bytes, including signatures and account keys. Flows that touch many accounts need address lookup tables or splitting.
- Compute: 200,000 compute units per instruction by default, up to 1.4 million per transaction on request. Loops over storage that are cheap to reason about on the EVM can run out of compute.
- Cross-program invocation depth: limited to 4. Deep proxy or router call chains need flattening.
What is your team going to maintain?
If the long-term team is Solidity-first, a Solidity-syntax toolchain lowers the ongoing cost. If you are hiring Rust engineers anyway, a native Anchor rewrite is often simpler to own.
What must not change?
Token addresses, user balances, governance rights, and integrations with partners. Settling these early prevents expensive late redesign.
How do existing users and balances arrive on Solana?
There are three common patterns, and they have very different costs:
- Fresh deployment. Solana starts empty and users opt in. This is the cheapest option, and it is right when the Solana launch is a new market rather than a move.
- Snapshot and mint. You take a snapshot of balances or positions at a block height and recreate them on Solana. This needs a reconciliation report that proves the two states match, plus a plan for activity that happens after the snapshot.
- Bridged assets. Tokens move through a third-party bridge. You inherit the bridge’s security model, and wrapped-asset UX becomes part of the launch.
The choice affects the account design, the audit scope, and the launch runbook, so it is settled in the assessment rather than during the build.
Implementation options
| Approach | How it works | Strength | Tradeoff | Maturity |
|---|---|---|---|---|
| SolScript (Cryptuon) | Compiles Solidity syntax to Rust/Anchor, mapping mappings to PDAs | Output is ordinary Anchor code you can read, edit, and audit | Not every Solidity pattern maps cleanly; complex contracts still need redesign | Open source, public tests; no third-party audit published |
| Solang | Compiles Solidity to Solana bytecode directly | Mature, long-running Hyperledger project | Account handling must be reasoned about in Solidity annotations; output is bytecode, not editable Rust | Established |
| Neon EVM | Runs EVM bytecode inside a Solana program | Closest to “deploy unchanged” for EVM tooling | Emulation overhead and a different cost and composability model from native programs | Established, on mainnet |
| Native Anchor rewrite | Engineers rewrite contracts in Rust with Anchor | Full control, idiomatic programs, largest talent pool | Highest upfront cost; the team must be Rust-capable | Industry standard |
In practice many migrations are mixed. Simple token, vault, and access-control contracts go through a compiler. The one or two contracts that carry the core economic logic get a native redesign.
The delivery sequence
- Inventory. List contracts, external calls, storage shape, upgrade patterns, and every off-chain client that builds transactions.
- Classify. Mark each contract port, redesign, or keep on EVM, with a reason.
- Account design. Lay out PDAs, account sizes, rent, and the instruction list for each flow.
- Build. Compile or write the programs, and update clients (wallet adapters, transaction builders, indexers).
- Prove parity. Run the same scenario tests against the EVM and Solana deployments and compare the results.
- Launch preparation. Deploy to devnet, measure compute budgets, write runbooks, and prepare the audit-readiness pack.
Example of the kind of parity check that becomes an acceptance test:
// Parity test: the same deposit/withdraw scenario on both chains must
// leave identical user-visible balances.
import { expect } from "chai";
const scenario = [
{ action: "deposit", user: "alice", amount: 1_000n },
{ action: "deposit", user: "bob", amount: 250n },
{ action: "withdraw", user: "alice", amount: 400n },
];
it("matches EVM balances after scenario", async () => {
const evm = await runOnEvm(scenario); // Hardhat/Foundry fork
const sol = await runOnSolana(scenario); // Anchor test validator
for (const user of ["alice", "bob"]) {
expect(sol.balanceOf(user)).to.equal(evm.balanceOf(user));
}
});And the compute-budget check that runs in CI:
// Fail the build if an instruction exceeds its agreed compute budget.
let result = banks_client
.simulate_transaction(tx)
.await?;
let units = result.simulation_details.unwrap().units_consumed;
assert!(units <= 150_000, "withdraw used {units} CU; budget is 150k");Stacks and Clarity
For Stacks the trade is different. Clarity is decidable and interpreted, with no compiler step to hide behaviour. Teams that prefer TypeScript-style syntax can author in StxScript and review the Clarity it emits. Teams that prefer the reference toolchain write Clarity directly with Clarinet. The same steps (inventory, classify, prove parity) apply.
Evidence
- SolScript emits standard Rust/Anchor and publishes worked examples: tokens, escrow, multisig, staking, and a constant-product AMM. You can inspect the generated code in the SolScript playground before any engagement.
- The tradeoffs between SolScript, Solang, and Neon are documented openly in the SolScript comparison and in our article on why Solidity developers should deploy on Solana.
- Lessons from building eleven Solana projects are written up in Solana infrastructure lessons.
- Current evidence levels for each tool are listed in the maturity register. Neither compiler has a published third-party audit, which is why generated programs still go through an independent audit before mainnet.
What drives the cost
- Number of contracts and the share needing redesign. A compiler-friendly contract can cost a fraction of a redesigned one.
- Client surface. Every frontend, bot, indexer, and partner integration that builds EVM transactions has to change.
- Upgrade and admin model. Proxies, timelocks, and multisig admin have to be reproduced with Solana upgrade authorities and governance.
- Data migration. Snapshotting balances or positions and reconstituting them on Solana needs its own tests and a reconciliation report.
- Audit lead time. Booking an independent auditor often sets the critical path more than engineering does.
Limitations and what we won’t do
- We will not claim that a compiler makes any codebase portable. The assessment exists to find the parts that are not.
- Neither SolScript nor StxScript replaces an independent audit, and the generated programs need one before they hold user funds.
- We do not launch tokens, provide liquidity, or market-make. Where your launch involves tokens, it also needs legal advice; we flag this but do not provide it.
- If the right answer is “stay on EVM and use a bridge or an L2”, the assessment says so.
Next step
Send us your contract inventory, or simply the repository URL and target date. The assessment returns a per-contract verdict, an account design for the hard parts, and a costed implementation plan.