Documentation
Soltechnics is a crowdfunding platform for robotics and applied AI. The distinctive rule is a collective vote: backers choose the builder when the work is open, and they accept or refuse each milestone before any of that money is paid. People stake a platform token for the right to take part, then fund a project in USDC. The pool stays in a program escrow. A passing vote releases that slice. Anything still in escrow can be claimed back.
A project is a public record with a creator, a pool of USDC, and either a creator who will build it or a short list of builder proposals. Projects groups the work into Robotics, Applied AI, and Hardware. The story, risks, FAQ, and files live off the chain. The program stores a SHA-256 of that description. What moves the money is the collective vote: the program enforces the deadlines, the quorum, and the result.
The current deployment is a Devnet beta. The tokens on that catalog are test USDC and a test stake token. They are not mainnet assets. The clocks are compressed so a full project can be walked in about an hour. The money rules are the same ones intended for a longer production run.
The public site at soltech.fun explains the desk. The catalog is a separate page. It talks to the Solana program through Phantom on Devnet. A description is saved by its hash so the catalog can show the title. The program never sees the title, only the 32-byte hash.
Anyone can send a settle instruction once the clock allows it, or once the interest threshold is already met. The site does not skip time. If a button says the action is too early, the deadline has not arrived and the threshold has not been met.
The shorter account of escrow, payout, and claims is the protocol note.
| Role | What they do |
|---|---|
| Staker | Locks at least one whole platform token. That stake is the pass for creating, depositing, bidding, and voting. Half of every creation fee is shared across stakers. |
| Creator | Opens a project, sets the interest threshold, and either names their own build or invites proposals. Receives 10% of each released slice. |
| Builder | The creator, or a wallet whose proposal won the vote. Posts proof, can ask for up to two extensions, and receives 87% of each released slice. |
| Backer | Deposits test USDC. A deposit of at least $25, made before a vote opens, is one vote. Claims any unreleased remainder when a project refunds. |
| Anyone | Can settle a phase, apply a decided vote, or expire a finished build. They pay the network fee for that transaction. They do not receive the project funds for doing it. |
One wallet can hold more than one role. A creator who is also the builder cannot vote on their own milestone or on an extension. They can still vote for a builder when the project is an open tender and they are not the only eligible backer.
Two assets are involved. USDC is the money in escrow. The platform token is the access pass and the claim on creation fees.
Create, deposit, bid, and vote each require a stake of at least one whole token. One token stays locked until the longest horizon of the projects that wallet has joined. Unstaking above that one token is allowed while the lock is in force. The lock uses the project's own copied clocks, so a later config change does not shorten a stake that is already committed.
The creator pays $25 of USDC. It is not refunded. Half is indexed for stakers in proportion to stake. Half is sent to the protocol treasury. A staker claims their share from the account page. The index is updated when the fee is paid, so a wallet that stakes afterward does not receive fees that were already distributed.
The creator, or a bidding builder, names a net amount. The gross goal is the net grossed up so that 87% of the gross equals that net, rounded up to the next base unit.
gross = ceil(net × 10000 / 8700)
A net of $870 is a gross goal of $1,000. The interest threshold is separate. The creator sets it between $1,000 and $1,000,000. Interest can close as soon as deposits reach the threshold. If the deadline passes below the threshold, the project refunds.
Milestones are 2 to 5 slices. Each slice is a whole percent above zero, they add up to 100%, and the first slice is at most 20%. When a slice is accepted, that percent of the USDC deposited so far is released:
| Share of the released slice | Receiver |
|---|---|
| 87% | Builder |
| 10% | Creator |
| The remainder, about 3% plus any rounding dust | Protocol treasury |
The percent applies to what has actually been deposited, including money above the goal. Deposits stay open through the build and may pass the goal. A released slice is not taken back. If a later milestone fails, only the unreleased balance is refunded.
Refunds are pulled. Each backer sends their own claim and pays their own network fee. The share is deposit × escrow balance / weight still to claim. The last claim takes the rounding remainder, so the escrow ends at zero. A refund of the original deposits, before any payout, divides exactly. Dust shows up after a partial release.
| Phase | What happens |
|---|---|
| Interest | Backers deposit toward the threshold. Meeting it closes the phase at once. Missing it by the deadline opens a refund. |
| Bidding | Only for an open build. Up to 8 staked builders each file one proposal: a net fee, a duration, and 2 to 5 milestone percents. Zero bids opens a refund. |
| Builder vote | Eligible backers pick one proposal. One wallet, one vote. A unique winner with quorum is selected. A tie, or too few votes, opens a refund. |
| Funding | Used when the pool is still short of the gross goal. Deposits continue. The phase ends when the goal is met or the funding clock ends. A shortfall opens a refund. |
| Execution | The builder posts a proof hash for the active milestone. Backers accept or reject it. An accepted slice is paid. A rejected slice refunds everything still in escrow. The builder may request up to two extensions, each no longer than half the original build. A rejected extension refunds even if build time remains. |
| Refunding | Backers claim. Released funds stay with the people who already received them. |
| Completed | The last milestone was accepted and its slice was paid. |
A self-build skips bidding and the builder vote. If interest closes at or above the gross goal, it goes straight to execution. If it has met the threshold but not the goal, it stops in funding first.
Proof cannot be posted while an extension vote is open. An extension cannot be requested while a milestone vote is open. Expire waits until an open vote is settled, and only after the build deadline.
A backer can vote when three things are true: they staked at least one token, their deposit is at least $25, and that deposit was eligible before the vote opened. Deposits made after a builder vote or a milestone vote has opened do not count for that vote.
The number of votes required is the larger of 25% of the eligible wallets, rounded up, and 5. It is never larger than the number of eligible wallets. Three eligible backers can finish: all three must vote. One hundred eligible backers need 25. A single eligible backer can settle the vote alone.
A milestone or an extension passes when the votes cast reach that number and Yes is strictly greater than No. A tie fails. The builder vote is a choice among proposals: the winner is the one proposal with strictly more votes than each of the others, and the same quorum applies. If every snapshotted wallet has voted, the vote can close before the deadline. The creator who is the builder is removed from the milestone and extension snapshot, so their missing vote does not block the others.
The Devnet beta uses the short clocks. A future production config uses the long ones. Projects keep the clocks they were created with.
| Devnet beta | Production defaults | |
|---|---|---|
| Interest | 10 minutes | 14 days |
| Bids | 15 minutes | 14 days |
| Vote | 10 minutes | 3 days |
| Funding | 10 minutes | 21 days |
| Longest build | 24 hours | 180 days |
On the beta, a build is entered in whole hours from 1 to 24. An extension is also in whole hours, and each one is at most half of the original build.
The program stores pubkeys, amounts, deadlines, vote counts, and 32-byte hashes. It does not store the story. The catalog keeps the description under the hash and refuses to open a project if that save does not match the hash the wallet is about to write.
Pause stops new projects, new deposits, and new bids. Votes, claims, payouts, and treasury withdrawal still work while paused. Config changes apply to projects created after the change.
The admin can pause, update the numbers for future projects, move the admin key, and withdraw USDC from the protocol treasury. The treasury is a token account controlled by the config account. The admin cannot pass the project escrow off as the treasury, and the program will not sign an escrow transfer for that withdrawal. There is no instruction that drains a project's deposits to the admin.
| Account | Address |
|---|---|
| Program | 9FFdLt7jvqy4oFqGCYxR7y8gdpYnDZJjSuti9yKsyyS1 |
| Test USDC, 6 decimals | 4CfXReBvS6P2PhLTUMnKRFneDuFMmcAtvTe12wVeLKMK |
| Test stake token, 9 decimals | 6tjrjiAyvcy7uYz6V3SXdLJFVYPRGZU5PzNqcSAhngtv |
Network: Devnet, https://api.devnet.solana.com. A little Devnet SOL is required for fees. The catalog faucet sends test USDC and the stake token. It does not send SOL.