CAPABILITY / C04 — DEFI · STABLECOINS

DeFi & stablecoins.

What we bring when protocols need the whole mechanism — not just contracts, but the math, the cross-chain plumbing, and the issuance design.

§1 — What we ship.

What we ship.

Zpoken's DeFi practice has built stablecoin infrastructure for institutional issuers (M0 — outstaff under MSDA), shipped a bond-backed RWA stablecoin protocol across three chains (Evidentia.fi — eUAH, eTRY, eVND), built cross-chain yield infrastructure with Sommelier, and shipped five lending protocols across six chains — including iLend on Injective, lendOS on Ethereum and Solana, LendLord on Manta, and AssetDesk on Stellar Soroban. We've also done smart contract and performance work for Neon EVM and the broader EVM-compatibility layer on Solana, and built a working proof-of-concept for ForwardX — a fixed-rate protocol with forward markets on yield-bearing assets: dynamic pricing with utilization-responsive floors, epoch-based markets, time-locked vault custody with batch settlement, oracle-guarded rate feeds, and an intent registry with committed matching.

The practice covers four kinds of work: stablecoin issuance and management infrastructure (M0, Evidentia), cross-chain yield and vault systems (Sommelier, RFQ/orderbook work), lending mechanism engineering (the lending portfolio), and smart contract performance work (Neon EVM and others). Stablecoin and RWA work is the core of the practice today; the lending portfolio is earlier work that demonstrates mechanism depth rather than current focus.

§2 — What DeFi mechanism work actually requires.

What DeFi mechanism work actually requires.

The gap between "deploy a fork" and "ship a protocol" in DeFi is the math, not the contracts. Four things matter.

01.

Mechanism design that holds up under adversarial use.

Stablecoin issuance, lending interest curves, AMM bonding curves, RFQ pricing — all of these are mechanism design problems before they're contract engineering problems. The mechanism has to be analyzed for failure modes (depeg under specific market conditions, liquidation cascades, oracle manipulation, MEV extraction) before the contracts are written. We do mechanism design at the start of engagements; we don't take engagements where the mechanism is fixed and someone else's contracts need to be ported.

02.

Cross-chain plumbing that doesn't treat bridge security as an afterthought.

Multi-chain DeFi protocols (Evidentia on 3 chains, M0 cross-chain) live or die on how they handle cross-chain state. Bridge dependencies are usually the highest-risk part of the stack. We've found protocols that scope cross-chain as "we'll use [bridge X]" without doing the security analysis of the bridge under their specific use case end up with vulnerabilities the bridge security model didn't cover. We do cross-chain threat modeling as part of mechanism design, not as a post-hoc audit.

03.

Stablecoin issuance under real institutional constraints.

RWA-backed and institutional stablecoins have to satisfy issuance, redemption, custody, and compliance constraints that don't exist for crypto-collateralized stablecoins. The engineering surface is larger because the off-chain processes (treasury management, compliance gates, reserve attestation) connect to on-chain primitives in ways that leak through to user-visible behavior. Stablecoin engagements are not just on-chain engagements.

04.

Oracle architecture that's specific to the use case.

Most DeFi oracle problems are downstream of choosing the wrong oracle for the use case. Lending protocols, perps, RFQ, AMMs each have different price feed requirements (latency, manipulation resistance, fallback paths, denomination). Picking Chainlink because everyone uses Chainlink isn't a decision; it's a default. We pick oracles per use case, sometimes including custom oracle infrastructure where third-party feeds don't fit.

§3 — Representative work.

Representative work.

01 / M0

Institutional stablecoin · cross-chain issuance (NDA).

Outstaff engineering partnership under MSDA. M0 is building cross-chain issuance infrastructure for institutional stablecoin issuers — the substrate that separates the issuance question (who can mint) from the deployment question (where the supply lives). Scope and chain coverage bounded by NDA.

→ /work/m0
02 / EVIDENTIA

Bond-backed multi-chain stablecoin.

Zpoken's internal protocol. Bond-backed stablecoins denominated in local currencies — Ukrainian hryvnia, Turkish lira, Vietnamese dong. Live across three chains (Ethereum, Solana, Tron) with LayerZero omnichain messaging and ERC-1155 token model. The protocol Zpoken built for itself before doing the same work for clients.

→ /work/evidentia
03 / SOMMELIER

Cross-chain yield infrastructure.

Yield vault infrastructure. The cross-chain dimension is the part that requires senior engineering — running yield strategies that span multiple chains has to handle bridge latency, gas variance, and state consistency in ways single-chain vaults don't.

→ /work
04 / NEON EVM

EVM compatibility on Solana — performance and contracts.

EVM compatibility layer on Solana. Paid client engagement covering smart contract engineering and performance testing. The work demonstrates that "EVM compatibility on a non-EVM chain" is a non-trivial DeFi engineering surface, not a configuration flag.

→ /work

§4 — Engineering tradeoffs we've converged on.

Engineering tradeoffs we've converged on.

The calls we keep arriving at across DeFi engagements.

Mechanism design before contract engineering, always.

DeFi engagements that start with "port these contracts to chain X" usually fail or ship vulnerable. The mechanism analysis has to happen before the contracts are written, even when the contracts already exist. We've taken engagements where step one was redoing the mechanism analysis the original team skipped.

Cross-chain protocols are bridge-security-shaped.

For multi-chain protocols, bridge security is part of the protocol's threat model, not an external dependency. We treat bridge selection and integration as a protocol-design decision, including running our own threat models of the chosen bridge under the protocol's specific use case. Most protocols that lose funds to bridge exploits did so because the bridge was treated as infrastructure rather than as part of the protocol.

Oracle choice is per-use-case.

Lending protocols want manipulation-resistant slow feeds. Perps want low-latency feeds with fallback paths. RFQ wants deterministic pricing at execution time, not market price feeds. Stablecoin issuance wants reserve attestation feeds, which most general-purpose oracle networks don't provide. We pick oracles per use case; sometimes that means custom oracle infrastructure for the parts general-purpose oracles don't cover.

Institutional stablecoin work isn't crypto-stablecoin work plus compliance.

The instinct on RWA and institutional stablecoin work is to start from a crypto-collateralized stablecoin design and add compliance and reserve attestation on top. This produces stablecoin protocols that are unstable under institutional issuance flows because the on-chain mechanism wasn't designed around the off-chain process. We design from the issuance flow inward; the on-chain primitives are downstream of the off-chain treasury and compliance design, not the other way around.

§6 — How we engage.

How we engage.

Engagement model.

DeFi engagements run 3–6 months for a stablecoin or yield vault build with no cross-chain complexity, 6–12 months for multi-chain RWA or institutional stablecoin work, multi-year for ongoing maintenance relationships and outstaff partnerships.

What we'll take on.

[01]
Stablecoin and RWA infrastructure for institutional issuers
[02]
Multi-chain DeFi protocols where the cross-chain part is the hard part
[03]
Yield vault infrastructure with cross-chain dimension
[04]
Lending and AMM mechanism design for chains or use cases where existing forks don't fit
[05]
Productized stablecoin modules + ongoing support contracts

What we won't take on.

[01]
DEX or lending fork-and-rebrand work where the mechanism is unchanged from upstream
[02]
NFT-financialization plays where the underlying NFT economics are the project's actual risk
[03]
Stablecoin work where the issuance design is fixed by someone else and we're only being brought in for the contracts
[04]
Pre-mechanism "let's see what works" projects without a defensible thesis
— CASE STUDYM0→
— CASE STUDYEvidentia→
— INTERSECTIONDeFi × M0 stack→
— ENGAGEMENT

If you're building stablecoin infrastructure or multi-chain DeFi, talk to a founder.

If you're building stablecoin infrastructure for institutional or RWA-backed issuance, multi-chain DeFi where the cross-chain part is the hard part, or yield/lending mechanism work that has to ship with real adversarial review, the engagement starts with a 30-minute call.

That call is with a founder. Shapes, discovery, and terms → /engagement

Book a call→ Open the form