Devil9

Why traditional public blockchains fail in regulated finance In regulated markets, “open by default” is rarely a feature. Institutions need confidentiality for positions, counterparties, and execution while still proving that rules were followed. On most public chains, the ledger doubles as a broadcast channel: balances, flows, and timing are observable forever, which turns normal financial activity into a data exhaust trail. That becomes even harder when you try to move a private asset into a transparent environment: interoperability breaks at the boundary, because the bridge has to preserve privacy while still producing correctness signals the destination chain can validate without trusting a black box.
Bridging a private asset into a transparent chain is like moving patient records from a sealed hospital archive to a public courthouse someone must prove authenticity and authorization without reading the file aloud. Privacy model vs. full transparency Dusk’s privacy framing is closer to controlled disclosure than full anonymity: the system is built to keep sensitive details private by default, while allowing authorized parties to reveal what’s necessary. The interoperability challenge is that even if the asset remains private on Dusk, the act of bridging creates public artifacts deposits, withdrawals, amounts, and timing that can leak patterns through correlation. “Privacy on one side” doesn’t automatically survive a public settlement layer on the other side.Regulated flows often require explicit consent, deterministic settlement, and clear rollback boundaries. Fast finality matters because bridges are policy engines as much as technical pipes: you need a crisp point at which custody changes hands and compliance obligations attach. If finality semantics differ across chains, the bridge must decide what “final” means especially under congestion, validator downtime, or contested states without creating gaps that either freeze capital or enable double-spend-like disputes.Using separate transaction models helps express different confidentiality and programmability needs without forcing one-size-fits-all behavior. But crossing chains introduces a proof translation problem: the destination chain needs evidence it can verify, and not every environment supports the same verification costs, elliptic curves, or proof systems. Even when verification is possible, the economics can be hostile proof verification might be too expensive or too slow on the destination, pushing designs toward intermediaries or batching, which reintroduces timing and aggregation leaks.

Auditability in regulated finance is not “everyone can see everything,” it’s “the right party can verify the right fact at the right time.” Bridged assets highlight a compliance vs. transparency mismatch: public chains expose holdings and flows by default, while private assets need selective disclosure for issuers, auditors, and regulators without public broadcast. If the bridge mints wrapped representations, the trust model becomes central: who controls mint/burn keys, how custody is enforced, how redemptions are paused, and what happens during a bridge halt. These are not edge cases; they define whether an asset is institution-grade or simply “wrapped and hoped for the best.”For regulated instruments, smart contracts need to encode more than transfers: eligibility, roles, transfer restrictions, corporate actions, and settlement logic. A Jaeger-style environment is compelling when it can support confidential state updates while still producing proofs of compliance-relevant conditions (e.g., whitelisting, limits, and issuer controls) without exposing the full cap table. Interoperability complicates this because a wrapped token on a transparent chain can accidentally strip those controls down to a thin IOU. If policy logic lives on Dusk but the liquidity venue lives elsewhere, the bridge becomes the enforcement point—and enforcement is exactly where failures concentrate: halted exits, disputed withdrawals, finality gaps, and “temporary” admin controls that quietly become permanent.

The hardest part is that privacy is often undone by everything around the protocol: wallets that reuse addresses, explorers that label flows, predictable bridging schedules, and user habits that create identifiable timing fingerprints. Even with strong cryptography, boundary metadata can remain stubbornly informative, and making proofs cheap and universally verifiable across heterogeneous chains is still an engineering and governance challenge. In practice, a bridge design may need to choose between maximum privacy, minimal trust assumptions, and smooth UX and it’s not guaranteed you can fully optimize all three at once.
@Dusk #Dusk $DUSK

I’ve noticed that most “stablecoin outages” don’t look like dramatic hacks. They look boring: a withdrawal stuck longer than expected, a transfer that says pending for minutes, a market maker widening spreads because settlement feels uncertain. In payments, that kind of uncertainty is the real tax, even when everything is technically “working.”

On general-purpose chains, stablecoins inherit problems they didn’t create. Fees can spike when unrelated activity heats up, so the same $20 transfer might cost cents one hour and dollars the next. The gas model is usually optimized for open-ended computation, not predictable value transfer, so mempool dynamics and MEV behavior can turn routine settlement into a timing game. Liquidity also fragments across venues and bridges, which makes redemptions, rebalancing, and cross-platform settlement depend on intermediaries that weren’t designed to provide bank-like reliability.It’s like trying to run a payroll system on a highway where the toll price changes every minute and the on-ramps occasionally decide which cars get to merge first.

Plasma (XPL) frames stablecoins as the primary workload and designs protocol incentives around endpoint guarantees: finality that’s dependable, correct settlement that’s consistent, and a shared expectation that “this transfer has settled” means the same thing for users, apps, and liquidity providers. Fees are treated as a reliability input, not a speculative lever aiming for a schedule and market structure that stays usable under load instead of turning payments into an auction. The gas model follows the same philosophy: constrain the surface area where unpredictable computation and priority games can destabilize simple transfers, so payment flows remain boring in the best way.

The liquidity design matters because stablecoins don’t succeed on issuance alone; they succeed when conversion, routing, and inventory management remain steady during stress. Instead of assuming liquidity will “just be there,” the network’s design tries to reduce the reasons liquidity providers pull back: unclear settlement, reorg fears, censorship anxiety, or downtime uncertainty. This is where validator economics becomes more than a security slogan. Staking exists to give validators real skin in the game, and slashing exists to convert endpoint guarantees from a promise into an enforceable rule. If a validator double-signs, participates in invalid state transitions, shows detectable censorship patterns, or causes prolonged downtime, slashing makes the failure expensive. In that model, uptime and correctness aren’t just “good behavior,” they’re bonded obligations: do the job reliably, earn; break the guarantees, pay.

On EVM compatibility, the goal isn’t to impress developers with novelty it’s to let existing stablecoin tooling, contract patterns, and payment integrations port without rewriting the world. Familiar execution semantics reduce integration risk, which is a reliability feature in itself: fewer bespoke components means fewer unknown failure modes. Privacy, at a high level, fits the payments mindset when it’s about controlled disclosure rather than hiding everything. Businesses usually don’t want their transactions broadcast to the world. They want to keep who they’re paying and why reasonably private, but still be able to prove later if an auditor or regulator ask that everything was done by the book.Designing privacy as optional, purpose-driven rails rather than blanket opacity keeps stablecoins usable as financial tools.

The token’s utility follows the same “enforcement over narrative” approach. It is used for fees to pay for settlement, for staking to bind validators to uptime and correct state transitions, and for governance to coordinate parameter changes that affect fee policy, validator requirements, and risk controls. In other words, it’s there to run the system and police the guarantees, not to be the story.

The boundary is that economic enforcement is strongest when violations are clearly observable and provable. Subtle censorship, gray-area liveness failures, or ecosystem-wide liquidity stress can be harder to measure cleanly, and the effectiveness of slashing depends on good detection, fair attribution, and governance discipline under pressure. In payments, the hard part isn’t declaring guarantees it’s keeping them credible when the network is having a bad day.
@Plasma

Most “mainstream onboarding” breaks at the first step. New users hit a seed phrase they don’t understand, gas they didn’t plan for, and wallets that feel like developer tools. For gamers and creators, that friction isn’t a small inconvenience—it’s a hard stop. High fees make experimentation expensive, and every extra step adds drop-off. Even investors who understand crypto still underestimate how quickly normal users bounce when the first experience feels risky or confusing.
Vanar is built around a simple assumption: if entertainment apps are supposed to scale, the chain has to feel invisible most of the time. “Low cost” matters here less as a brag and more as a UX requirement small in-game actions, creator drops, or social interactions can’t feel like a financial decision. The idea of shipping more infrastructure on-chain from day one is also practical: apps shouldn’t have to stitch together five external services just to deliver something that feels normal to a user.Account abstraction is easiest to understand as changing what an account is. Instead of forcing every user to manage a seed phrase like a vault key, accounts can behave more like modern profiles with safer recovery options and flexible permissioning. Gas can be handled in ways that don’t interrupt the flow sponsored transactions, predictable fee experiences, or app-level fee logic that doesn’t demand users understand “native token first.” The goal isn’t to hide responsibility; it’s to remove the moments where a user feels they might lose everything because they clicked the wrong button.
Gaming, metaverse environments, and VR/AR are high-throughput by nature: lots of small actions, frequent state changes, and user-driven economies that can’t pause for “network congestion.” These products also operate on trust. If an item transfer fails, a marketplace lags, or onboarding is confusing, users blame the game—not the chain. That’s why validator resilience becomes a UX feature, not just a decentralization metric. Geographic diversity among validators reduces the chance that block production is pressured, interrupted, or slowed by one region’s outage, one ISP issue, or one legal environment. If too many validators sit in the same city, cloud, or jurisdiction, you’ve created a single failure domain one correlated event can ripple into visible downtime for players.

A network built for entertainment is shaped by people who’ve watched users quit over tiny delays and confusing flows. Teams with real time in gaming and immersive tech tend to obsess over retention curves, not just throughput charts. That background usually shows up in product decisions: stability over novelty, predictable performance over peak benchmarks, and developer ergonomics that reduce shipping risk for live economies.

The long-term vision reads like a platform mindset: make the underlying rails reliable enough that creators and studios can focus on content, communities, and economies instead of constant wallet support and “how to explain gas” tutorials. If account abstraction makes onboarding feel familiar, and geographically distributed validators reduce correlated downtime and censorship pressure, the chain becomes easier to trust for persistent worlds where users expect things to keep working across regions and time zones.
Vanar matters because the next wave of adoption is less about convincing people that blockchains are important, and more about removing the reasons they leave. In gaming and immersive experiences, UX is the product, not a wrapper and infrastructure choices leak directly into player trust. Account-abstracted onboarding reduces early fear, low and predictable costs keep interactions natural, and validator geographic diversity lowers the risk of region-specific failures becoming everyone’s problem. For dynamic, high-throughput sectors, those “boring” details are often the difference between a concept demo and a world that can stay online.
@Vanarchain  

I keep seeing teams treat a blockchain like it’s a hard drive: upload big files, pin them forever, and assume “immutability” means “durable storage.” In practice, that usually turns into bloated state, expensive writes, and a network that’s forced to carry everyone’s old baggage. The weird part is that the chain is doing exactly what it was designed to do just for the wrong job.

Most blockchains use state machine replication (SMR): every validator re-executes the same transactions and stores the same data so the system can agree on one history. That’s great for consensus and correctness, but it’s a bad fit for large blobs. If a 50 MB blob is “on-chain,” it’s not just 50 MB once it’s 50 MB multiplied by the number of replicas across time, plus re-sync costs for new nodes, plus bandwidth pressure during propagation. Even if execution is simple, the storage burden compounds because the safety model assumes broad, repeated duplication to tolerate faults. In other words, the chain’s security comes from everyone holding the same thing, which turns large data into a permanent tax on the whole system.Putting large files directly on a blockchain is like forcing every accountant in a company to keep a full copy of every receipt image, forever, just to reconcile the same ledger.This is why decentralized blob layers emerged: keep consensus and execution focused on ordering and verifying actions, while offloading big data to a storage network designed for durability and availability. The key difference from “content routing” systems like IPFS (high level) is the reliability contract. IPFS is excellent at addressing content by hash and moving it around, but persistence is a separate promise you must arrange through pinning, incentives, or external operators. A blob layer is built around “store this for a defined durability target,” with redundancy and repair as first-class protocol behaviors rather than optional add-ons. That’s the separation: blockchains commit to what happened; blob networks specialize in keeping the data needed to prove or reconstruct it available over time.

Walrus fits into that gap as a specialized blob layer: it aims to make large data cheap to store, easy to retrieve, and still verifiable without dragging execution or consensus into a storage arms race.

A detail that matters in decentralized storage often more than people admit is governance. Governance is only useful if it can tune durability and cost forward without putting already-stored data at risk. The core idea here is separation of time: redundancy parameters apply to new blobs at the moment they’re stored, not retroactively to old ones. That means governance can adjust knobs like replication factor, erasure-coding thresholds, and repair cadence for future uploads, while past data remains protected by the parameters it was originally committed under.
Technically, the safety comes from immutable commitments. Once a blob is accepted, its commitment (a cryptographic fingerprint plus whatever metadata anchors its storage rules) stays verifiable under the original scheme. If governance later decides “new blobs should use a different redundancy profile,” the network doesn’t rewrite history: it doesn’t force re-encoding, doesn’t require clients to re-upload, and doesn’t invalidate old proofs. This avoids the most dangerous failure mode in storage governance migration by surprise,” where a policy change quietly turns into forced work or hidden data loss risk.There’s also a clear safety boundary: governance can tune the cost vs durability trade-off for the future, but it cannot reduce availability guarantees for already-stored blobs. Put simply, it can’t vote to make yesterday’s data less safe. That boundary matters because it keeps governance from becoming an upgrade lever that can accidentally (or politically) weaken the durability of existing datasets.Rollups & data availability: Rollups need a place to publish data so anyone can independently verify state transitions. If blob availability is fragile, verification becomes “trust the sequencer.” A blob layer provides a dedicated place to store that proof data with redundancy and repair built in, while the settlement chain only needs to reference commitments.

Decentralized app distribution: Frontends and static assets change frequently, but users expect fast fetch and long-lived availability for specific versions. Using a blob layer avoids turning app assets into on-chain ballast, while still letting users verify they received the exact build that was referenced.AI provenance: Provenance isn’t “store everything on a chain”; it’s “anchor a verifiable reference to the dataset, model, or artifact used.” Large training sets and artifacts belong in blob storage, with commitments and retrieval guarantees that let third parties audit claims later.

Encrypted data storage: For sensitive data, the goal is not public readability but dependable custody: store ciphertext blobs, keep keys off-network, and still have strong guarantees the encrypted payload remains retrievable in the future. This is where redundancy policy and repair cadence matter more than flashy execution features.The open question is governance discipline under stress: even with “new blobs only” parameter changes, the network still needs credible processes to decide when to increase redundancy (higher cost) versus accept more risk (lower cost) for future data. If incentives or coordination fail, you can end up with policies that look optimal on paper but lag real-world failure conditions. The architecture can prevent history from being rewritten, but it can’t fully automate good judgment about future resilience.
@Walrus 🦭/acc

Most public blockchains were built around universal transparency: every balance change, counterparty link, and position history is visible by default. That works for open settlement, but regulated finance has a different baseline confidentiality for client data and strategies, plus the ability to prove compliance on demand. When everything is public, institutions end up choosing between leaking sensitive information (front-running risk, exposure mapping, relationship disclosure) or moving critical workflows off-chain where oversight becomes fragmented. Add-on privacy layers can help, but they often introduce new trust and integration boundaries: separate proving systems, different failure modes, and operational complexity that compliance teams must sign off on.

A transparent ledger is like conducting every audit by publishing everyone’s bank statements on a bulletin board and then asking the market to “ignore” the sensitive parts.
The Dusk Foundation design approach starts from the assumption that privacy in regulated markets is controlled disclosure, not full anonymity. Instead of “hide everything forever,” the goal is: keep transaction details confidential by default, but make it possible to reveal specific facts selectively, cryptographically, and with consent when a regulator, auditor, or counterparty is authorized to see them. This changes the architecture: privacy is not a separate optional lane that only some users take; it’s part of the normal transaction lifecycle, so the assurance story is more uniform. In contrast, on Ethereum the base layer’s transparency creates friction for sensitive activity, so privacy often arrives through L2s, app-specific zk systems, or specialized contracts. Those approaches can be valid, but they add dependencies (bridges, provers, sequencers/relayers, and new composability constraints) that institutions must evaluate as part of their risk model.

On consent and fast finality (high level), the institutional requirement is not “fast for trading hype,” but “fast enough to reduce settlement risk while keeping governance and disclosure rules enforceable.” A system that can finalize transactions predictably helps with operational controls: reconciliation windows shrink, margin and collateral rules can be enforced more deterministically, and disputes are easier to bound. The key is that finality and privacy can’t fight each other; you want confidential execution that still yields clear, verifiable settlement.

Dusk’s dual transaction models Moonlight and Phoenix can be understood as two rails optimized for different disclosure and data-handling needs. One model supports richer programmability and account-style interactions; the other is optimized for privacy-preserving transfers and simpler flows. From an institutional viewpoint, the important part isn’t the branding; it’s that the protocol acknowledges different transaction shapes and compliance expectations, and tries to support them without forcing everything through a single “one size fits all” privacy wrapper.

Audit and controlled disclosure is where “built-in privacy” shows its practical value. A regulated workflow needs an audit trail that is both privacy-preserving and legally usable: you need to prove that rules were followed (eligibility, limits, disclosures, settlement integrity) without exposing all counterparties and amounts to the public. If privacy is embedded at the protocol level, the disclosure mechanism can be standardized: clients can generate proofs and selectively reveal fields to authorized parties, while third parties can verify correctness without learning the underlying private data. With add-on privacy stacks, you often end up with multiple disclosure formats across L2s and apps—fine for experimentation, harder for institutional assurance at scale.

For regulated markets, smart contracts are not just “code that runs,” they’re instruments with lifecycle obligations: issuance terms, transfer restrictions, corporate actions, reporting hooks, and settlement rules. Jaeger (as described in the Dusk ecosystem) is positioned around expressing those instruments in a way that aligns with compliance: embedding constraints, supporting privacy-preserving interaction, and enabling verifiable state transitions that an auditor can validate when permissioned. The institutional payoff is straightforward: you can model instruments so that compliance checks are not external paperwork bolted onto an otherwise permissionless flow, but part of the transaction logic while still keeping sensitive details off the public surface area.

Even with protocol-level privacy, real-world deployment depends on governance choices, implementation quality, and the willingness of institutions and regulators to standardize on specific disclosure practices. “Controlled disclosure” also introduces operational questions: who holds view keys, how access is granted and revoked, how disputes are handled, and how to prevent permissioned visibility from turning into brittle central points of failure. And while built-in privacy can reduce L2 dependency risk, it doesn’t eliminate all external constraints legal enforceability, custody integration, and cross-venue settlement remain hard problems that no single protocol design can fully solve.
@Dusk_Foundation

I’ve watched stablecoin “depegs” up close and it rarely feels like a single dramatic failure. It’s usually a bunch of small frictions stacking at once: a withdraw queue here, a bridge delay there, and suddenly the price you see depends on where you’re standing. In calm markets you don’t notice the plumbing, but stress has a way of forcing every assumption into the open.
The core problem on general-purpose chains is that stablecoins inherit the chain’s fee volatility, MEV behavior, and shared blockspace congestion. That matters because stablecoins aren’t trying to be exciting they’re trying to be predictable. When gas spikes, the cheapest path to move or rebalance liquidity disappears. When ordering becomes adversarial, arbitrage isn’t a public good anymore; it’s a private race. And when everyone is competing for the same execution lane, stablecoin liquidity doesn’t “vanish,” it fragments: issuer redemption channels, on-chain pools, market makers, and bridge inflows start distrusting each other at the same time, so spreads widen as each source prices exit risk rather than transfer speed.
It’s like a city where the roads still exist, but during a storm every neighborhood closes different bridges, so deliveries become expensive even though nothing “ran out” of goods.
Plasma is designed around the assumption that stablecoins are the primary workload, so the protocol tries to make the liquidity paths more reliable under stress instead of optimizing for generic activity. On fees, the goal is to reduce surprise: stablecoin-heavy execution should not be competing with unrelated demand spikes that reprice blockspace minute to minute. A predictable fee environment matters because it keeps arbitrage and treasury rebalancing economically viable when you need them most, which is exactly when spreads are otherwise tempted to blow out.
On the gas model, Plasma’s design focuses on making stablecoin transfers and the common “maintenance transactions” (rebalancing pools, topping up inventory, routing through approved rails) behave like routine operations rather than emergency bidding wars. In practice, that means the chain architecture is oriented toward stablecoin-style flows, where the user expectation is “this should settle at a known cost,” not “I’ll pay whatever to win the block.” If your gas regime is stable, you keep more liquidity sources connected, because market makers and routing systems can keep quoting with less fear of being trapped by fees.
Liquidity design is where stress shows up first. In a healthy market, primary liquidity (issuer redemption at 1:1) anchors secondary liquidity (DEX/CEX pricing). Under stress, redemption latency or limits push price discovery onto secondary venues, and then inventory risk takes over: market makers widen spreads when hedging paths break, and on-chain pools get imbalanced because the cheapest external refill route is suddenly slower or capped. Plasma’s stablecoin-first orientation is meant to keep those refill routes usable: if the chain’s fee and execution behavior stays more predictable, then on-chain pools, professional market makers, and bridge inflows are less likely to all “pause” simultaneously. You’re not preventing stress you’re reducing coordination failure, which is what makes spreads widen in the first place.
EVM compatibility matters here for a boring reason: stablecoin liquidity is already mediated by EVM tooling risk engines, routing,custody workflows, audits, and integrations that assume EVM semantics. If you can reuse that stack, you reduce operational risk and time-to-fix during incidents. That’s not about chasing apps; it’s about keeping the people who manage liquidity issuers, market makers, and integrators on familiar infrastructure so they can respond quickly when latency and trust constraints tighten.
Privacy, at a high level, fits the same reliability story. Large stablecoin flows often carry sensitive business context (treasury movements, payroll runs, merchant settlement). If every move is fully transparent, participants sometimes delay or route inefficiently to avoid signaling, which can worsen fragmentation under stress. A privacy layer that supports selective disclosure can reduce that signaling risk while still allowing compliance workflows so liquidity providers can operate without broadcasting their playbook to the whole network.
On token utility, XPL sits in the “keep the system operating” bucket: it’s used for fees, it can be staked to align operators with uptime and correct behavior, and it can be used for governance decisions around protocol parameters that affect stablecoin reliability (fee policy, execution rules, and potentially which rails are treated as core infrastructure). That’s the functional role: paying for resources, securing the network, and coordinating changes.
One honest boundary: even a stablecoin-focused chain can’t force issuer redemption to stay instantaneous, can’t eliminate off-chain banking constraints, and can’t guarantee bridges won’t be throttled during systemic stress. Plasma can make on-chain behavior more predictable, but the widest spreads still tend to appear when external trust breaks so the real test is how well the protocol keeps multiple liquidity sources connected when everyone is pricing worst-case exits.
@Plasma

The biggest barrier to Web3 adoption is not ideology or lack of interest. It is friction. New users are asked to understand seed phrases, pay unpredictable fees, manage wallets they have never seen before, and accept slow or confusing interfaces just to try a game or explore a virtual world.For gamers and creators who expect to jump in instantly and get moving, that kind of setup just feels like extra friction. Instead of excitement, it creates hesitation, and for many people, that’s enough to walk away before they even start. Complexity, high fees, and fragile user flows quietly push people away before they ever see the value.

Vanar Chain is built as a direct response to this problem. Instead of asking users to adapt to blockchain habits, the network adapts to user expectations. It is designed to be fast and low-cost, but more importantly, it treats usability as a first requirement. Core infrastructure that applications normally have to rebuild themselves is available on-chain from the start, making it easier for developers to deliver familiar, Web2-like experiences without hiding behind custom workarounds.

A central piece of this approach is account-abstracted wallets.Instead of telling every new user “write down this seed phrase and don’t lose it” and “make sure you have gas,” the account can feel more like the kind of login people already understand something closer to a regular digital profile where getting started (and coming back later) doesn’t feel scary or complicated.Access recovery, transaction handling, and permissions are abstracted away from the user. The result is an experience where players can enter a game, interact, and return later without feeling like they are managing financial software. The blockchain remains present, but it stays in the background, where most users expect infrastructure to live.

This design choice matters most in gaming and immersive environments. Games, virtual worlds, and creator-driven platforms depend on speed, consistency, and uninterrupted sessions. High latency or expensive transactions break immersion and limit experimentation. These sectors also involve frequent micro-interactions items, upgrades, cosmetics, social actions that simply do not work well when every step feels heavy or costly.A chain built around these “game-like” patterns just makes life easier. Players aren’t stopped every few seconds by fees, pop-ups, or waiting, and developers don’t have to keep redesigning features just to fit around blockchain limitations. When the basics feel smooth, teams can spend their time on fun mechanics, storytelling, creator tools instead of constant technical trade-offs.
That entertainment focus also matches the people behind the network. With 10+ years across gaming, VR, AR, and metaverse work, they’ve lived the reality that tiny delays kill momentum and clunky onboarding kills retention. If a login feels risky or a transaction feels slow, users leave. So the product choices lean toward things that keep sessions stable and predictable, and let builders ship without babysitting the plumbing.

The bigger idea is simple: make blockchain infrastructure feel normal inside entertainment apps. As games and virtual worlds blend with real economies items, tickets, creator revenue, digital ownership the winners will be the platforms that fade into the background and let the experience stay front and center. Vanar’s place in that story is being the “quiet layer” that supports high activity without forcing users to think like crypto users.
Right now, usability is turning into the real dividing line. And Vanar matters because it’s clearly designed around that reality: keep it simple, keep it fast, and keep the focus on what players and creators actually came for.
@Vanarchain