VCS = Vibe Code Store · on Solana

VCSThe Vibe Code Store

A safe place to vibe-code: let every employee build with AI, without the security risk. And the Solana token that powers the network.

Download the full paper (PDF)v0.5 · 9 pages · problem, product, security, market, business, token

Version 0.5 draftUpdated October 2026Token VCS

Abstract

In one lineEvery employee can build apps with AI. VCS makes sure every one of those apps is safe, checked and approved.

Companies that do not use AI will fall behind, but the usual routes are slow, expensive or unsafe: wait for IT, build it yourself, or let staff paste company data into any AI tool. Employees who vibe-code their own tools are more productive, yet every unmanaged app is a new path for a data leak or an attack.

VCS, the Vibe Code Store, gives each company its own safe place to vibe-code. Apps written by any AI run in sealed sandboxes with their own database, reach company systems only through connectors the company approves, sit behind single sign-on, and are scanned and scored before a teammate approves them. The approval is anchored on Solana. VCS runs inside the company's own systems, or is set up and managed for it in Singapore.

VCS is also an SPL token on Solana. Teams can pay with it, every payment burns some, and new VCS is minted only to the builders, security reviewers and bug hunters whose work makes the network safer and more useful.

01Introduction

Simply putUse AI, or fall behind. But letting staff use any AI tool is a security risk. VCS gives you the speed without the risk.

Every company now faces the same choice. Teams that use AI to build their own tools move faster; teams that do not, fall behind. A non-engineer can now describe a tool in plain words and receive working code in minutes. The demand for small internal tools was always far larger than engineering capacity, and that demand can now be met at the point of need.

Option	Fast	Affordable	Safe
Wait for IT	✕	✕	✓
Build it yourself	✕	✕	✓
Let staff use any AI	✓	✓	✕
Use VCS	✓	✓	✓

1.1 Shadow AI

Employees are already building with AI, usually without guardrails. Six risks recur:

company data pasted into public AI tools;
apps running on personal accounts;
code nobody reviewed;
passwords and keys inside the code;
no record of who built what;
open doors for attackers through unmanaged apps.

Each unmanaged app sends the decision back to engineering or security, which says no, and the productivity gain is lost. What is needed is a place where anyone can build and security is measured, not assumed. The rest of this paper describes that place.

◆The safe place to vibe-code

Simply putYour company's own space to build with AI: your data, your approved systems, your sign-on, and a security score on every app.

What the company controls

Its own database for every app, inside the company's environment.
Approved connectors only: the company chooses which systems apps may reach.
Single sign-on on every app the company creates (Okta, Microsoft Entra ID, Google Workspace).
A security score for every app. Below the bar, it does not go live.
An audit log and a kill switch for every app.

Security score

Every build is checked before a person sees it: secrets, vulnerable dependencies, network egress, permission scope, unsafe code patterns and company policy. Each check has a weight and the weights add up to 100.

σ(b) = Σ_k w_k · c_k(b), go live only if σ(b) ≥ 80 and every critical check passes

Every new build is scored again, so an approved app that is edited must be checked and approved again.

Two ways to run it

Option	For	How
In your system	Companies with an IT team	Your cloud or servers, your database, your single sign-on. Company data never leaves.
We set it up for you	Companies with no tech team	A private VCS environment for your company, with its own database and single sign-on, hosted in Singapore and run by VCS.

02Applications

Simply putEvery version of an app is fingerprinted and linked to the one before it, like a chain.

We define an application as a chain of signed builds. Each build commits to three things: the hash of its source, the hash of its configuration, and the set of connector scopes it requests. The builder signs the build, and each new build includes the hash of the one before it.

A reviewer can walk the chain to see exactly what changed between any two versions. The problem is that the reviewer cannot know whether the code that runs is the code that was signed. The solution is to make the platform, not the builder, compile and run the build. Only a build whose hash matches a signed record can execute.

03Sandbox

Simply putEach app lives in its own sealed box. If it breaks, nothing else breaks.

Every build runs in an isolated runtime with its own database. The runtime has no network path to the outside world except through the connector layer described in section 4. Compute, storage and request rates are bounded per application, so a faulty build cannot exhaust resources shared with others.

Isolation means the system does not need to trust that model-written code is correct. It only needs the boundary around that code to hold.

04Connectors

Simply putAn app can never see more than the person using it, or more than its reviewer allowed.

A connector is the only path between a sandbox and a company system such as a finance, sales or people database. Each connector exposes typed objects with read and write scopes. An application never holds credentials; it asks the connector, and the connector decides.

The access an application has at runtime, for a given user, is the intersection of three sets:

A = S_req ∩ S_appr ∩ R_user

where S_req is the scope set the build requested, S_appr is the scope set the reviewer approved, and R_user is what the current user's role permits.

05Attestation

Simply putEvery approval gets a stamp on Solana. Nobody can fake it or quietly change it later, and each stamp costs a fraction of a cent.

A review is only as useful as the proof that it happened. When a reviewer approves a build, the platform takes the hash of the build, the approved scopes, the reviewer's signature and a timestamp, and publishes their combined hash to Solana. Each attestation includes the hash of the previous one, so the history of approvals forms a chain that cannot be rewritten without being detected.

An auditor can later prove that a given version of an application was approved, by whom, with which scopes and when, without trusting the platform operator's own records.

06Network

The steps to run an application are as follows:

A builder signs in with a Solana wallet (Sign In With Solana) and writes the application with any AI assistant.
The platform compiles the build in a sandbox and computes its hash.
The build requests the connector scopes it needs.
A reviewer approves the build and scopes; the attestation is signed with the reviewer's wallet and anchored on Solana.
The application is published to the store; each user's access resolves by the formula in section 4.
Any change produces a new build, and the process repeats from step 2.

Platform architecture: four steps, one connector layer.

The layer is model-neutral. Builders keep their choice of assistant; the governance does not depend on which model wrote the code.

◎Built on Solana

Simply putVCS runs on Solana: fast, nearly free, and where our first customers already have wallets.

Component	How it works on Solana
Sign-in	Sign In With Solana message, signed by Phantom, Solflare, Backpack or any Solana wallet
Approval	Reviewer's wallet signature; teams can require a Squads multisig threshold
Proof	The VCS program writes each attestation to Solana and checks it links to the previous one
VCS token	SPL token; the emission program holds mint authority and enforces the halving and the 1B cap
Burn	Market buys followed by the SPL burn instruction, public and auditable
Cost	Base fee of 0.000005 SOL per signature, so a proof costs a fraction of a cent

07Tokenomics

Simply putTeams pay in dollars or in VCS. Every payment burns some VCS. New VCS only goes to people whose work makes the network safer and more useful.

VCS is an SPL token on Solana. Everything a company buys from VCS (its plan, usage credits and security reviews) is priced in dollars and can be paid in USD, USDC or VCS. Every payment burns some VCS, and new VCS is minted only to reward the builders, security reviewers and bug hunters whose work makes the network safer and more useful. Companies that pay in dollars never carry token price risk.

7.1 Two units

Unit	Transferable	Value	Purpose
VCS	Yes	Set by the market	Pays for plans, credits and security reviews (15% off); staked by security reviewers; burned with every payment; minted to contributors.
Build Credit (BC)	No	Fixed at US$0.01	What companies spend on usage. Cannot be traded or withdrawn.

A company's finance team sees a fixed price in dollars. The token's price can move without changing anyone's software bill. Because credits cannot be transferred, they are a prepaid service balance, not an asset.

7.2 The credit loop

The top rows are demand: every dollar of usage removes VCS from supply. The bottom row is supply: new VCS reaches only builders whose work people pay to use.

7.3 Metering

Action	Unit	Rate (BC)
Build	Each build or rebuild compiled in a sandbox	[to fill]
Run	Each hour an application is live	[to fill]
Connect	Each 1,000 connector calls	[to fill]
Attest	Each review anchored on chain	[to fill]

Rates are set at cost plus margin from early usage data. Plans and security reviews are priced the same way, in dollars.

How a team pays	What happens
USD or USDC	70% is kept as revenue. 30% buys VCS on the open market and burns it.
VCS	15% off the dollar price. Half of the VCS paid is burned, half goes to the network treasury.
12 months ahead	The team keeps today's rate for the year. If paid in VCS, the tokens sit in an on-chain escrow and are released monthly, so they leave circulation for the year.

7.4 Supply

No more than 1,000,000,000 VCS can ever be minted. 60% is allocated at genesis (7.6). The remaining 40% is emitted to the network over time, halving every 48 months. Monthly emission in month t is:

M_t = M₀ · 2^{−⌊t/48⌋}, M₀ = 400,000,000 / 96 ≈ 4,166,667 VCS

Circulating supply moves with emission and burn, where U_t is dollar usage in month t and P_t is the VCS price:

S_t+1 = S_t + M_t − B_t, B_t = 0.3 · U_t / P_t + 0.5 · V_t

Here V_t is VCS paid directly by teams in month t. The analysis below sets V_t = 0, so every result holds before counting direct payments, which only add to the burn.

Supply is stable when burn equals emission, which happens at the price:

P^* = 0.3 · U_t / M_t

The equilibrium price rises with usage and with each halving. The token's value is tied to how much people build on the network, not to speculation alone.

7.5 Rewards and staking

Pool	Share	Paid to
Builders	70%	Authors of apps and connectors, in proportion to verified paid usage
Security reviewers	20%	Reviewers who staked VCS on apps and connectors that stayed safe and earned usage
Bug bounties and grants	10%	Paid to people who find security holes, and to connectors the network votes to fund

A builder's share in month t is their component's usage over all usage, where c_i is credits spent through builder i's work:

r_i = c_i / Σ_j c_j

Only credits bought with dollars or burned VCS by verified tenants count, and usage from a builder's own tenant is excluded. Rewards cost more to fake than they pay. Security reviewers stake VCS on the apps and connectors they certify; if one is exploited, fails review or reaches outside its scopes, part of the stake is slashed.

7.6 Allocation and distribution

Pool	Share	Release
Network emission	40%	Monthly, halving every 48 months
Team	15%	1-year cliff, 4-year vesting
Early investors	15%	1-year cliff, 3-year vesting
Treasury	15%	Governed, multi-year
Ecosystem and partners	10%	Grants against milestones
Liquidity	5%	At token launch

We recommend the first capital be raised as equity or SAFE with token warrants, not a public token sale. The token launches only after the network has paying customers and legal sign-off in each sale jurisdiction (section 10).

7.7 The formal model, in one box

Proven in the PDF

Hard cap. G + Σ M_t = 10⁹. Emission can never push supply past one billion.
Break-even price. P* = θU_t/M_t. Below it, supply shrinks every month; above it, supply grows.
Convergence theorem. With velocity V, supply follows S_t+1 = (1−κ)S_t + M, κ = θV/12, and converges geometrically to S* = M/κ for any V < 80. The clearing price at S* is exactly P*.
Wash-usage bound. Faking usage is unprofitable while αM_tP_t ≤ U_t. At equilibrium that is 0.21 ≤ 1, so price would need to exceed 4.76 × P* before any attack pays.
Honest reviewing. Vouching for broken apps loses money when slash × detection > reward rate; the protocol sets λ ≥ 2ρ/q_min.

κ = θV / 12, |S_t − S*| = |1 − κ|^t · |S₀ − S*|

08Privacy

Simply putYour data stays private. Only the proof goes on chain.

Company data never leaves the company's tenant. The public ledger holds only hashes and signatures. The public can see that an attestation was made, but not what it attests to. A company can reveal the underlying record to an auditor when it chooses, and the auditor can check it against the hash on chain.

09Economics

The company earns in dollars; the token captures value from usage. Fiat revenue funds the business, while 30% of credit sales buys and burns VCS.

Stream	Payer	Unit	To the company
Platform subscription	Company	Per active builder or user, per month	100%
Build Credits	Company	Prepaid usage, US$0.01 per credit	70% (30% buys and burns VCS)
Implementation	Company	One-time, custom systems	100%
Marketplace fee	App buyers	Share of each sale	[to fill]

10Roadmap

Each phase opens only when the gate before it is met. The token launches on top of a working network, not a promise of one.

Phase 1

Build

Product, security scoring, first connectors.

gate: security audit passed

Phase 2

Pilot

Paid pilots with finance and crypto teams in Singapore.

gate: paying customers

Phase 3

Launch

Token launch with its uses live. Builder and reviewer network.

gate: legal opinion

Phase 4

Scale

Regulated enterprises, then every company.

10.1 Go to market: strictest teams first

Simply putFinancial services and crypto first, starting in Singapore. If it's safe enough for them, it's safe for everyone.

Stage	Who	Why them
Now	Financial services and crypto in Singapore: banks, fintechs, insurers, exchanges, protocols, DAOs	The strictest security needs and the clearest cost of a leak
Next	Regulated and data-sensitive enterprises	Same need for safe AI tools, larger budgets
Later	Every company	Through the managed option; no tech team or crypto knowledge needed

Sales follow a standard enterprise path: an introduction by form or email, scoping and a security review under NDA, a signed pilot agreement and data processing addendum, workspace set-up with single sign-on and approved connectors, a 30 to 60 day pilot against agreed metrics, then an order form, paid in USD, USDC or VCS.

10.2 Funding and token launch

The first capital is raised from investors, including crypto venture funds, as a SAFE or a simple agreement for future tokens, with rights to the investor allocation under its lock-ups. The token launches only when its uses are live (payment, escrowed annual plans, reviewer staking, bug bounties and builder rewards), and the launch doubles as the network's main community moment.

Illustrative use of a first round (~US$1.2M, 18 months)	US$
Engineering team	270k
Founder salary	145k
Security audits	120k
Legal: entity, token opinion, agreements	100k
Infrastructure and AI	90k
Go-to-market and community	150k
Buffer	120k

11Risks

Platform risk: model and cloud providers may bundle hosting, connectors and governance into tools companies already pay for.
Integration risk: custom systems can turn each sale into one-off work instead of reusable connectors.
Token risk: token value may not track network usage, and token regulation differs by country and changes often.
Adoption risk: IT teams may resist a new layer even when business teams want it.

12Conclusion

Companies have to use AI to keep up, but letting every employee build with any tool is a security risk they cannot accept. VCS gives each company a safe place to vibe-code: its own database, approved connectors, single sign-on, a security score on every app, and approvals anchored on Solana, running in the company's own system or managed in Singapore. We begin with financial services and crypto, where the cost of a leak is highest, and expand to every company. Prices stay in dollars; the token lets teams pay, burns with every payment, and rewards the builders, reviewers and bug hunters who make the network safer, with a capped supply and incentives that make cheating unprofitable.