Hashi and Native Bitcoin on Sui: How BTC‑backed Primitives Could Reshape Institutional DeFi
Summary
Executive overview
Hashi is the Sui Foundation’s new BTC‑backed primitive designed to bring native Bitcoin functionality into Sui’s execution environment in a way that caters to institutional needs: auditability, legal clarity, and programmable access. The primitive is meant to power lending and yield rails that rely on Bitcoin as the underlying collateral or yield source, while reducing the operational and compliance friction that typically comes with wrapped‑BTC approaches.
For many participants, Bitcoin remains the anchor asset. Hashi’s promise is to let developers and institutions use BTC within Sui with stronger custody and attestation guarantees than ad hoc wrapped solutions, enabling new cross‑chain product architectures and more institutionally palatable rails for yield and lending.
What Hashi is, its architecture, and the devnet approach
Hashi is presented as a BTC‑backed lending and yield primitive rather than a single app: a set of protocol‑level components and developer APIs that represent BTC economic exposure on Sui while linking that exposure to offchain custody, attestations, and compliance metadata.
At a high level the architecture includes three logical layers:
- Custody and legal layer: licensed custodians or regulated entities hold onchain BTC and provide legal assurances and attestations. This layer is intentionally stronger than the opaque custodial models often used to mint wrapped assets.
- Attestation & oracle layer: cryptographic and signed attestations from custodians (and potentially third‑party auditors) are published to Sui to prove backing and support redemptions; these feeds also provide proof‑of‑reserve signals.
- Onchain primitive & accounting: a native Sui object model that represents BTC exposure, enforces redemption flows and composability rules, and exposes APIs for lending, yield aggregation, and integrations with other Sui modules.
The Sui Foundation has launched a developer preview/devnet for Hashi to let builders experiment with the primitive and surface design questions (liquidity patterns, redemption UX, and attestation formats). The devnet release is staged as a sequence: a developer preview to iterate on APIs and attestations, followed by larger testnets for stress testing and then a mainnet governance/operational rollout once custody and compliance processes are formalized. During devnet, builders should focus on integration testing, oracle resilience, and end‑to‑end redemption flows before expecting production‑grade guarantees.
Why native‑BTC on Sui differs from wrapped‑BTC models (and why compliance matters)
Wrapped‑BTC models (wBTC, renBTC, etc.) were a pragmatic early solution: lock BTC at a custodian and mint a representation on another chain. They enabled rapid DeFi composability, but they left three core institutional concerns unresolved: legal recourse, auditability of reserves, and standardized compliance controls.
Hashi aims to address those by design. The differences in practical terms:
- Legal and contractual clarity: Wrapped tokens often rely on informal custody arrangements. Hashi’s model emphasizes licensed custodians, documented legal terms and onchain attestations that can be tied to those contracts.
- Continuous attestations and proof‑of‑reserve: instead of one‑off audits or opaque reserve claims, Hashi integrates automated attestation streams and onchain proofs that can be programmatically verified by smart contracts and external auditors.
- Composability with constraints: where wrapped tokens are maximally composable, Hashi’s objects may include enforcement mechanisms (e.g., KYC gates, whitelists, or conditional transfer restrictions) that make them safer for institutions but potentially less permissive for permissionless composability.
These design choices matter for institutions that must meet internal compliance, AML/KYC, and regulatory reporting standards. A compliance‑friendly BTC primitive reduces legal ambiguity and can lower capital and operational friction for asset managers, custodians and banks considering onchain yields.
Product outcomes: BTC‑backed lending, onchain yield primitives, and parallels with tokenized funds
If Hashi achieves its design goals, several product primitives become cleaner to implement on Sui:
BTC‑backed lending markets: Lenders can accept Hashi‑represented BTC as collateral with stronger proof‑of‑reserve guarantees. That makes institutional credit facilities and borrowing against BTC more palatable because exposure and custody are auditable.
Onchain yield aggregates and tokenized yield funds: Builders can construct yield primitives that wrap BTC collateral into yield strategies while preserving attestation trails, enabling products similar to the Coinbase/Apex Bitcoin Yield Fund on Base but natively composable inside Sui. See coverage of the Coinbase/Apex Base initiative for an example of how institutions are already tokenizing bitcoin yield on layer‑2s.
Tokenized funds and institutional product packaging: The industry is already experimenting with tokenized institutional funds — for example, Amundi’s tokenized fund on Ethereum. Hashi could catalyze similar product launches on Sui by providing a standardized, compliance‑forward BTC representation that fund managers can plug into their tokenized fund architectures.
In short, Hashi could be the plumbing that connects traditional institutional products (funds, custody services, regulated lending desks) to programmable onchain execution. Projects that built tokenized designs on Ethereum or Base may find Sui’s approach attractive for Bitcoin‑centric products that need tighter audit and custody linkages.
Technical and regulatory risks to adoption
Adopting a BTC primitive that targets institutions carries both technical and non‑technical risk vectors. Below are the main considerations that product teams and compliance officers should weigh.
Custody and legal risk
A primitive is only as trustworthy as its custody arrangements. Institutional adoption requires legally robust custody agreements, indemnities, insurance, and operational controls. If custodial attestations are disputed or if a custodian suffers a security event, downstream protocols and users can face cascading failures. Integrations must include rigorous operational due diligence and contractual protections.
Peg stability and liquidity risk
Peg stability (the 1:1 parity between onchain representation and native BTC) depends on transparent, timely attestations and reliable redemption mechanics. Slow redemptions, settlement delays, or mismatched settlement windows between Bitcoin’s UTXO finality and Sui’s execution model can cause transient or sustained peg deviations. Liquidity depth is also crucial: lending markets will only be functional at institutional scale if there’s dependable BTC supply and active borrowing demand to maintain low slippage and credit spreads.
Oracle and attestation risk
If Hashi relies on offchain attestations or oracles, those data providers become single points of failure. Signed attestations are only meaningful if the signing process is secure, keys are managed properly, and there are multi‑party verification options (e.g., multiple custodians or auditors).
Composability limits and governance constraints
One tradeoff for compliance is reduced permissionless composability. Conditional transfer rules, whitelists, or KYC requirements can make some forms of yield aggregation or cross‑protocol interaction impossible or legally risky. That design tension will affect how broadly Hashi can integrate into the wider Sui and cross‑chain DeFi ecosystem.
Regulatory uncertainty
Regulators are still forming views about tokenization, custody, and onchain financial products. Jurisdictional variability—what’s permitted in one country might be restricted in another—creates complexity for global funds and custodians. Institutions must build flexibility into their product design to adapt to changing rules without breaking core guarantees.
Roadmap: what institutions and builders should do now (integration checklist, composability & liquidity needs, KPIs)
Below is a practical roadmap and checklist for teams that want to evaluate or integrate Hashi into institutional products.
Integration checklist (practical steps)
- Legal & custody onboarding
- Execute custody agreements with regulated custodians and define legal recourse and indemnities.
- Verify insurance coverage, operational controls, and residency of keys.
- Attestation and oracle integration
- Define the attestation format and frequency expected from custodians; test signature verification flows in devnet.
- Build redundant attestation feeds (multiple custodians/auditors) where possible.
- Smart contract and onchain accounting
- Integrate Hashi’s onchain object model and test redemption, mint/burn, and transfer rules.
- Implement guardrails for emergency pauses and dispute resolution.
- Compliance and AML flows
- Map KYC/AML requirements into onchain permissioning or offchain workflows, balancing privacy and regulatory needs.
- Liquidity provisioning and market making
- Seed pools, design incentives to bootstrap TVL, and coordinate with custodians and OTC desks for initial liquidity.
- Security and audits
- Perform independent smart contract audits and operational reviews of custody/attestation processes.
- UX and settlement
- Build clear UX for redemptions and reconcile expected settlement windows with Bitcoin onchain finality.
Composability and liquidity needs
- Native integrations with lending protocols, automated market makers, and margin desks will accelerate product-market fit. However, early products may need permissioned integrations with institutional counterparties.
- Liquidity providers must be compensated for the more conservative treasury and custody constraints. Structured incentives (fee rebates, native rewards) can help bootstrap TVL.
- Bridges, swap routers, and liquidity aggregators should be designed to respect conditional transfer rules and attestation checks.
KPIs to monitor post‑launch
- TVL in BTC terms and USD terms: rate of growth and concentration by counterparty.
- Peg deviation and redemption latency: distribution of observed spreads between Hashi tokens and spot BTC and the time to redeem to native BTC.
- Reserve coverage ratio: cryptographic and attested reserve vs. outstanding supply.
- Liquidity depth: available depth at common slippage thresholds for lending and AMM pools.
- Utilization and default metrics: borrowing utilization rates, shortfall events, and resolution times.
- Counterparty diversity: number and regulatory diversity of custodians and institutional counterparties using the primitive.
Practical examples and parallels
The industry is already experimenting with institutional tokenized Bitcoin yield. Coinbase’s partnership with Apex to bring Bitcoin yield on Base shows how major exchanges and asset managers want onchain tokenized yield primitives, and Amundi’s tokenized fund on Ethereum demonstrates institutional appetite for programmable fund structs. Hashi’s compliance‑centric design on Sui could be the missing piece that lets similar products be issued directly against BTC exposure inside a high‑throughput execution environment.
Platforms like Bitlet.app and institutional product teams will be watching early devnet metrics closely: how easily custodians can publish attestations, how quickly liquidity forms, and whether composability limits are a meaningful tradeoff for institutional risk reduction.
Conclusion: what success looks like
Hashi aims to reduce the trust and legal friction that have historically limited institutional use of wrapped BTC. Success will look like a set of widely adopted attestation standards, multiple regulated custodians signing attestations, a growing TVL composed of institutional counterparties, and practical lending/yield products that settle reliably to native BTC. That outcome would not make Bitcoin any less decentralized, but it would create a clearer corridor for regulated capital to enter onchain markets with predictable controls.
Adoption will not be automatic: builders must design for auditability, proof‑of‑reserve, and limited composability where needed. Institutions must run operational and legal due diligence, and both groups should watch core KPIs on peg, liquidity and custody coverage as Hashi moves from devnet to production.
If Hashi achieves those tradeoffs, it could knit together the institutional workflows we already see on other chains into a Bitcoin‑centric DeFi stack that meets the compliance expectations of funds, custodians, and regulated desks.
Sources
- Sui Foundation launches Hashi: Sui Foundation and leading institutions launch Hashi — Bitcoin.com News
- Coinbase/Apex tokenized yield on Base: Coinbase partners with Apex to bring Bitcoin yield on Base — Blockonomi
- Tokenized institutional funds example: Ethereum: Amundi tokenizes $100M SAFO fund — Bitcoinist
