Pinned Tweet
Thread of 🧵s:
Web3 City States:
xitter.cf/RadixWiki/status/16364…
Web3 is a network of city-states all fighting for liquidity.
Switching sides is costly, so the benefits need to be 10x to be worthwhile.
In a few weeks, #Radix will storm the citadels of Web3 with its arsenal of 10x Moments.
Here are our top ten: 👇🧵
A Radix address says what it points at and which network it lives on before anything is decoded. account_rdx1… is an account on mainnet; resource_tdx_2_1… is a token on Stokenet, the public test network.
The first character after the "1" separator is predictable too. It comes from a type byte Radix sets for each kind of entity, so every validator address starts validator_rdx1s, every fungible token resource_rdx1t and every NFT resource resource_rdx1n.
For accounts it also names the key that secures them. account_rdx12… is derived from an Ed25519 key, the kind the Radix Wallet creates; account_rdx16… from a Secp256k1 key, which covers accounts carried over from Olympia, Radix's mainnet before the 2023 Babylon upgrade; account_rdx1c… was created by a transaction rather than derived from a key.
The decoder checks the prefix against the type byte, so an address relabelled as another kind of entity, or moved to another network, is rejected rather than misread.
How the format works, with the full table: radix.wiki/developers/transa…
OTER, an oracle built on Radix, runs a public randomness service that signs one value every 3 seconds, laid out so the Radix engine can verify each value on the ledger.
On 24 October it moved the service to a new signing key and a new chain, radixnet, after Railway, the company hosting it, disclosed that customer secrets may have been read. OTER found no sign of misuse. The signatures are deterministic, so anyone holding a copy of the old key could compute every future value in advance.
The old chain stays online until at least October 2028. Timelock encryption stores the chain's hash in each ciphertext and fetches that chain's round when it comes due, so switching the old chain off would leave anything encrypted to it unreadable.
radix.wiki/ecosystem/oter?ut…
Seven Radix validators now hold more than a third of the stake that runs consensus. A week ago it took eight.
The seven barely grew, from 1.34B to 1.36B radix:native. The other 93 active validators lost 467m XRD between them, 16% in a week.
A third matters because a group holding more than a third can stall the network. It is a share, not an amount, so stake leaving smaller validators raises the share of the largest without them gaining anything.
The week in full, with five hyperscale-rs merges and next week's fee rises: radix.wiki/blog/week-in-revi…
Radix DAO LLC, the company the Radix community is setting up to take over from the Radix Foundation, stays advisory until ten conditions in its Operating Agreement are met. Each is either met or not, and each names the evidence that proves it.
Two are moving in public. The community ratified the Charter and its 20 policies on 2 October, and candidacy for the Permanent RAC, the seven-member council that will act on the DAO's decisions, is open until 30 October.
Six depend on parties outside the DAO: formation in the Marshall Islands, the beneficial-owner filing, KYC, the custody wallet, and two on the Foundation's side, a signed continuity statement and the start of the asset handover.
Once the council holds the evidence for all ten, it has to publish it, then open the Activation Vote within 14 days. That vote is the only binding vote the DAO holds while it is advisory.
radix.wiki/ideas/dao-foundat…
hyperscale-rs, the community-built Rust implementation of a sharded Radix network, lets one machine run several validators. A change its lead developer, flightofthefox, merged overnight stops validators on the same machine duplicating each other's work.
Each validator identity is a vnode, with its own signing key, its own votes and its own record of missed duties. From this change a host keeps one replica per shard it serves: one copy of that shard's state, mempool and execution. Every vnode seated on that shard signs through the replica, so two vnodes in one shard share one store and execute each transaction once, and the second adds only its own signatures.
Each vnode still keeps its own voting record and writes it to disk before it signs, so two identities on one host cannot cast contradictory votes. The design notes give the aim: the cost of an extra validator seat should approach its stake, which is what the security model prices, while the hardware it needs costs little.
What a vnode is, and how Hyperscale shards: radix.wiki/contents/tech/res…
In December 2021 someone took about $120m from users of Badger DAO, an Ethereum app that pays yield on wrapped bitcoin. Weeks earlier they had altered Badger's website so that ordinary deposits also asked users to approve the attacker's address to spend their tokens, with no limit. Wallets showed the approval as contract data, and more than 500 addresses signed one. On 2 December the attacker drew on those approvals until Badger paused its contracts about two hours later.
On Radix there is no approval to collect. An account is a component that holds each token in its own vault, and tokens leave a vault only in a transaction the account's owner signs. Before signing, the wallet shows what that transaction withdraws and deposits, read from its manifest, the human-readable list of instructions that makes up a Radix transaction.
A hijacked Radix site could still ask a user for one bad trade, such as wrapped bitcoin for a fake token, and a user who skips the summary could sign it. The site could not gather standing permissions for weeks and spend them later.
What happened, and how a manifest shows a transaction: radix.wiki/contents/tech/cor…
Instruct is a browser tool for building a Radix transaction by hand, one instruction per row. A transaction on Radix is a manifest, a readable list of steps. Instruct's own example is a swap on Ociswap in four: withdraw radix:native from your account; put it in a bucket; pass the bucket to the pool's swap method; deposit the OCI that comes back.
Each row picks a command and its arguments, and the editor flags an error as you type and will not send an invalid manifest. Every row has an Enabled switch, so you can turn off a step to find the one that fails without deleting it.
It submits through the Radix Wallet to mainnet or Stokenet, the test network, so the wallet shows what the transaction does before you sign. It is in beta and has no on-ledger component of its own. The team behind The Radix Billboard built it for transactions no existing app's interface covers.
radix.wiki/developers/tools/…
On Radix, a token moves between smart contracts in a bucket, a container that exists only for the length of the transaction. The engine fails the whole transaction if any bucket still holds tokens when the transaction ends, so a token cannot be lost, duplicated or stranded in a contract that never wrote a withdrawal. Your account keeps one vault per token.
On Solana, a wallet needs a separate token account for every token it holds. Anchor's documented transfer example lists seven accounts, creates the recipient's token account first if they have never held that token, and the sender pays the refundable deposit that keeps the new account on chain.
radix.wiki/contents/tech/com…
Cerberus, the consensus protocol Radix specified for a sharded network, commits a transaction across shards in four steps, and the shards never vote together.
Each shard the transaction touches agrees which of its inputs it holds and whether they are still available. It sends that finding to every other shard involved. Each shard then commits if all of them had their inputs, and aborts if any lacked one. The client accepts the result once matching reports arrive from every shard.
If two transactions want the same input, each shard pledges it to the one it saw first, so both abort. An honest client never signs both.
radix.wiki/contents/tech/cor…
A validator running hyperscale-rs, the community-built Rust implementation of a sharded Radix network, now checks the signatures on a certificate before it syncs toward the block that certificate names.
A certificate is a block's proof that a quorum of its shard's validators signed it. Validators pass them to each other, and one that sees a certificate for a height it does not hold syncs up to that height. Until this change it started the sync first and verified later. A forged certificate naming a height far above the chain could hold a validator in sync mode, proposing only empty blocks, until it restarted, because a sync has no exit for a height the network cannot serve.
Now a cited certificate is only a claim until its signatures check out. Each validator gets its own slots for claims, so one that floods forgeries fills only its own, and each refuted claim costs the checker a bounded number of signature checks before that sender waits a round to try again.
flightofthefox merged it on 19 Oct, with a test that sends that forgery: github.com/hyperscalers/hype…
Radix's entry for the CAIP namespaces registry had its first review on the spec yesterday, from Chain Agnostic, which runs the registry. CAIP is the naming scheme wallets and cross-chain tools share for a network, an account or a token.
The reviewer suggested shorter identifiers: drop the address prefix from accounts and tokens, since radix:mainnet in front of them already names the network.
x402, the HTTP standard that lets an AI agent pay for an API call inside the request, names networks the same way. @a_vaunt's x402 spec for Radix, filed in August, lets an agent pay without holding any radix:native: the agent signs only the payment, as a subintent, and the facilitator wraps the subintent in a transaction and pays the fee.
Both submissions: radix.wiki/developers/ai-age…
hyperscale-rs, the community-built Rust implementation of a sharded Radix network, splits a shard in two when it grows too large, and merges two when they shrink. A change its lead developer, flightofthefox, merged today decides what happens to transactions caught across a split or merge.
Until now a shard kept taking cross-shard transactions right up to the moment it split, and the ones caught mid-way were sorted out afterwards. Now the shard drains first: it stops admitting transactions to and from other shards, waits until every transaction it has already agreed to has its answer from the other shards, and only then splits. Transactions that touch that shard alone keep running throughout.
With nothing at fault, the drain takes at most 444 seconds, about 7½ minutes. If the splitting shard is waiting on a shard that has halted, and the drain misses its deadline, the split is cancelled rather than forced, so no transaction can commit on one shard and abort on the other.
The design, including what the pause costs: github.com/hyperscalers/hype…
The Radix Foundation has recovered 419k of the roughly 443k $USDC caught in an unfinished bridge transfer during the 31 August exploit, it said in the main Radix Telegram chat this morning. The bridge is Hyperlane, which links Radix to other chains.
The other 24.7k is stuck on Hyperlane's route to Solana. The Foundation spent three days on it with Hyperlane last week and is still working on it. Hyperlane advised against paying out the 419k while that recovery continues, so the Foundation is holding it.
The money is due back as hUSDC, Radix's bridged USDC, to the accounts that held hUSDC at the time of the exploit, in proportion to what each held. Governance proposal #3 settled that on 4 October with 95% of the vote.
radix.wiki/contents/history/…
A Scrypto developer can attach a fee to any function or method they publish. The Radix Engine, which runs every transaction, charges it on each call, so calling code cannot skip it, and the royalty owner receives all of it.
Other transaction costs are split: execution, finalisation and storage each go 25% to the validator proposing the round, 25% to the validator set and 50% to a burn. Royalties bypass that split.
There are two kinds. A package publisher sets developer royalties inside the blueprint, and calls to every component built from it pay them. A component owner sets owner royalties per method and can lock one for good, which gives anyone composing with that component a fixed cost.
Royalties are paid in radix:native, but an owner can set one as a USD amount, converted to XRD at a rate fixed for each protocol version.
radix.wiki/contents/tech/cor…
hyperscale-rs, the Rust implementation of a sharded Radix network, merged an experimental network layer on 17 October. It uses iroh, a library that connects two machines directly even when both sit behind home routers, and falls back to a relay when it cannot. A node now picks iroh or its existing libp2p layer at build time, and a new test bed seats a validator committee across different router types.
The rest of the week is in Issue #17 of the Week in Review:
radix.wiki/blog/week-in-revi…
On Radix, who may call a method is written once in the blueprint: one block maps each method to the roles allowed to call it. The engine checks the caller's badges against that rule before the method runs.
A Solana program has to confirm that every account it is handed is owned by the right program and signed by the right key. Anchor makes those checks when the developer picks the right type for each account.
radix.wiki/contents/tech/com…
Staking radix:native on Radix gives you a token back. Each validator has its own, called a liquid stake unit (LSU), and the validator mints it to you when you stake.
An LSU is a share of that validator's pool of staked XRD. Every epoch, about five minutes, the network mints new XRD for stakers and adds it to the pool, less the validator's fee. The number of LSUs you hold stays the same while the XRD each one redeems for goes up.
An LSU is an ordinary token, so it can be traded or deposited into another dApp while it keeps earning.
Getting the XRD back takes three steps: you return the LSUs to the validator, which burns them and gives you a claim NFT recording the amount and the epoch it unlocks; 2,016 epochs pass, about 7 days; then you hand in the claim NFT and receive the XRD.
radix.wiki/contents/tech/cor…
Radix Wiki | RadixWiki.xrd retweeted
Replying to @RadixWiki
Não vamos deixar Radix morrer, vamos engajar nossos soldados para que o projeto decole brevemente. Radix não é uma memecoin, mas sim uma das principais Layer 1 do mundo. Por mais que não estejamos bem, vamos fazer isso por Dan e por nós.
#radix
A Radix component that holds a token and gives it away takes 33 lines of code in the official hello-world example. The method that pays out is one line: take a token from the vault and return it. The caller's transaction decides where it goes.
Anchor's documented example of a similar job on Solana runs to 93 lines, most of them listing and checking the accounts it touches.
radix.wiki/contents/tech/com…
On Radix, one transaction can call several smart contracts, and either every step happens or none of it does.
On mainnet that is the normal case. Seböööl counted transactions on the Babylon ledger: 89.6% touch at least two components (Radix's smart contracts), not counting accounts. The median transaction writes 4 entries of ledger state; one in ten writes 19 or more.
A swap routed through two exchanges settles as one transaction. If any step fails, the whole thing reverts and only the network fee is charged.
How it works: radix.wiki/contents/tech/cor…



