Shubh

well, that's enough internet for today 😭

I agree with @durov You take the risk , you build the product, you make the sacrifices, you carry the responsibility And then someone else gets to decide whether you are allowed to keep leading what you created? founders should think carefully before giving away control of the companies they build and never loose the sight of whose vision it was in the first place.

a bunch of you kept asking so here are my dotfiles lol. nvim , zsh, tmux, ghostty one script and you are set on mac and debian. change whatever you want , adjust the setup according to your machine. github.com/subhdotsol/dotfil…

shipped @neapdex , a perp engine on @NEARProtocol - pool to peer markets - integer only risk engine - keeper + indexer its a perps exchange where any token with a dex pool can get a perps market, settled in USDC in one NEAR contract. Its live on testnet today

the perp engine is working now 😎

A week ago, I barely understood what happens under the hood of perpetuals. since then, it's been hours of reading, researching, breaking things down, understanding the mechanics, questioning existing designs, and connecting dots. Been quietly working through something that brings a few different worlds together. This is just a glimpse of what's been keeping me busy lately.

repo link : github.com/subhdotsol/near-a…

Wrote my first smart contract on @NEARProtocol Built an English Auction smart contract using rust and near-sdk, along with a web client. Some features : - Initialize an auction with an end time and auctioneer. - Place bids in NEAR tokens. - Automatically refund the previous highest bidder. - Track the highest bid. - Claim the winning bid after the auction ends. - Connect NEAR wallets and sign transactions.

Okay, I'm no DeFi expert, so correct me if I've got this wrong, but here's what I understood happened with @PercolatorTrade . They're launching a new token through @MetaDAOProject and seem to be leaving the old Pump.fun token behind. The problem is, this was announced without properly informing the existing holders first, and the old token took a pretty big hit. What makes it worse is that compensation for old holders was apparently discussed, but the team seems more interested in keeping their new token allocation. Maybe there's more to the story, but from the outside, it doesn't look great.

something i got to know today about rust and C, which might be a pretty basic or dumb question. C is generally much faster to compile than Rust. but you must have heard that rust can often produce performance comparable to C, and sometimes even outperform it. how does that work? well, compile time and execution time are two different things. compile time is how long it takes to convert your code into an executable. execution time is how long that executable takes to run. C is a relatively simple language when it comes to compilation. Rust, on the other hand, performs extensive compile time checks, including ownership, borrowing and lifetime checks. but the interesting part is, why can rust perform just as well as C at runtime ? one reason is that neither Rust nor C requires a garbage collector. C gives you manual memory management. Rust uses ownership and borrowing to ensure memory safety at compile time without needing a garbage collector at runtime and then there's LLVM. think of LLVM as a toolkit that helps compilers optimize code before turning it into machine instructions. Rust uses LLVM as its default backend, and Clang, a popular C compiler, uses LLVM too. so basically C gives you more control with fewer compile time checks. Rust gives you similar low level control with compile time memory safety both can produce incredibly fast binaries.

built a @solana auction protocol using @magicblock ER + PER with rust and pinocchio what it offers ? - public auction with visible real time bindings on ER - private sealed bid auctions with confidential bids on PER - winner determination without revealing losing bids - L1 handles escrow, refunds and final settlement

I'm actually building a game on @magicblock too and will be listing it here once it's ready. If you're building on MagicBlock, you should definitely check this out!

spent the night losing to @solana toolchain versions just to write pinocchio contract on the latest stack. Six failures later, I have a scaffold that pins everything. Here's the version hell, condensed : The dependency pileup: - pinocchio 0.12 pulls solana-address ^2.8, LiteSVM pins ~2.7, so cargo can't resolve one lockfile - LiteSVM breaks on Agave 4.4, but the newest RPC client is 4.4 - cargo build-sbf 4.1 silently defaults to SBPF v0 The runtime traps: - @surfpool_sol rc1 refuses a v3 .so: "sbpf_version not enabled" - v1 transaction limits default to zero, so you hit MaxLoadedAccountsDataSizeExceeded - platform-tools ships rustc 1.95, the host has 1.99, so rust-version must satisfy the older one The fix: stop forcing one lockfile to do everything. - program: pinocchio crates only - tests: Agave 4.3.x, what LiteSVM supports - client: Agave 4.4.x, what the RPC client wants - three workspaces, three lockfiles, every version pinned and documented.

Validator and Verifier architecture : The magicblock validator is the execution infrastructure behind ERs. The leader processes transactions and maintains rollup state. Verifiers follow and replay the leader's transaction stream, providing replicated execution.

Magic router, Magic actions and Cranks : These solve different infrastructure problems. Magic Router directs transactions to the correct execution environment. Magic Actions let a rollup application request actions on the Solana base layer and react to their results. Cranks provide automated, time-based instruction execution, so applications don't have to rely on a connected client to trigger every operation.

Session Keys : A session key is a restricted signer that lets an application perform authorized actions without asking the user to approve every transaction. The program can validate the session's authority and constraints.

Price Oracle : MagicBlock's oracle infrastructure brings low latency external data into on chain accounts. the current implementation ingests Pyth Lazer feeds and pushes updates into ephemeral rollup accounts at roughly 50–200 ms intervals, depending on the asset. Your program reads the account directly instead of making an external API request during execution this matters for liquidations, funding, copy trading and prediction markets.

Solana VRF : Randomness on chain is harder than calling rand(). a program requests randomness, an oracle generates a value and its cryptographic proof, and the VRF program verifies that proof on-chain before invoking the consumer's callback. Invalid proofs are rejected. Useful for games, lotteries, random rewards and other applications where the operator shouldn't control the outcome.