SERV Hackathon - RWA Vaults - IXS
CapitalRail
Check if you can really enter an IXS vault before you sign anything. GO only when deposit capacity is real. How it works
- Tell us
- We check
- Decision
- Review & sign
Where do you want to put your USDC?
Say it in your own words. We check live IXS vaults before you sign anything.
How it works
From a sentence to signable deposit steps, in six checked steps
CapitalRail is a preflight: it answers "can I actually enter this vault right now?" before any capital moves.
- 01Chat
Describe your intent
Type what you want to deposit in your own words (amount, chain, KYC, withdrawal speed), or edit your rules by hand.
- 02SERV
SERV turns it into your rules
SERV Reasoning turns your sentence into typed rules validated against a schema. You see what was understood and can edit it.
- 03IXS REST + MCP
Scan the live IXS vaults
CapitalRail reads the 4 live IX High Yield Bond USDC vaults on BSC and Avalanche through the IXS REST API and MCP tools: access mode, deposit limit, whitelist status and settlement mode.
- 04Code + SERV Reasoning
Rules are code, judgment is SERV
Code applies the hard rules (chain, capacity, KYC, withdrawal speed, balance) and sets GO / WAIT / NO-GO. SERV Reasoning then writes fact-grounded risk notes, cross-checks the rules, ranks the vaults that pass and independently verifies the memo. Every step is schema-validated and traced.
- 05Guardrail
Code-level safety override
Deterministic checks run again after the model. A vault with a deposit limit of 0 or an unmet whitelist can never be selected, whatever the model says. SERV can veto an entry, never unlock one.
- 06Deposit steps
Review and sign yourself
Only on GO, and only for your connected wallet, IXS tools build unsigned approve + deposit steps. You sign them in order in your own wallet. Nothing is signed server-side.
Why CapitalRail
A naive agent would deposit. CapitalRail checks first.
The failure case
The Avalanche IX High Yield Bond USDC vault is listed as open, but its deposit limit is 0. An agent that only reads "open" would build a deposit that fails or gets stuck.
CapitalRail reads the real capacity, flags DEPOSIT_LIMIT_ZERO, and refuses that rail. A code-level override enforces it even if the model disagrees.
No custody
SERV and CapitalRail never hold funds. They read public vault data and return a decision.
Nothing signed server-side
Deposit steps are unsigned and built for your connected wallet only. Only you can sign, after review.
Attested snapshot
Each decision carries a snapshot hash and an attestation time, so you know exactly which IXS state it was based on.
Refuses instead of guessing
If capacity is not real, CapitalRail says WAIT or NO-GO and explains why, rather than proposing a transaction that will fail.
Business model
Every failed deposit avoided is worth something.
Failed deposits avoided on this instance
-
Real count from this server, since start
1 · AI agents and wallets
Preflight API
One POST /api/preflight call before any deposit returns GO / WAIT / NO-GO, reasons, risk notes and an unsigned tx pack. Agents stop sending transactions that fail.
Free tier, then pay-per-check
2 · RWA issuers such as IXS
"Can I enter?" widget + blocked-demand dashboard
A white-label widget for vault pages, plus a dashboard of demand blocked by capacity, KYC or withdrawal rules, so the issuer sees which limit to raise or which onboarding to push.
Monthly license per issuer
3 · Allocators on WAIT
Capacity alerts
When a vault that fits your rules reports deposit limit 0, get notified the moment capacity returns, with a fresh preflight attached.
Subscription
4 · Partner vaults
Referral on validated deposits
A routing fee only on deposits that passed the preflight and settled on-chain.
Subject to an agreement with IXS
Pricing models, not live revenue. The counter above only counts real results served by this server; it resets on restart.
FAQ