Smolder

Is a bridged token actually backed 1:1? I checked two on the Rayls Public Chain from both ends, and one of them is backed by 40,000,000 tokens that never crossed the bridge If you run treasury and hold $BRL1.p on Rayls, your claim is $BRL1 locked in a LayerZero lock box on Polygon BRL1.p: equal to the last unit On 4 Nov 2026 at 14:36 UTC my checker read both sides together (Rayls block 13,839,744, Polygon block 96,731,678): 255,291.961901 $BRL1.p on Rayls, 255,291.961901 $BRL1 in the lock box. Difference 0, in raw units. A matching total can still hide one bad message, so I paired every message since 14 Oct by its LayerZero guid. All 18, 16 locks and 2 releases, carry equal raw amounts on both chains. Polygon to Rayls took a median of 267 s, and LayerZero Scan's own 4m 28s for the largest one matches my 268 s for it. $RLS: covered, but not only by the bridge The Rayls Transparency Portal counts total supply as 9,931,411,076.81, the Ethereum figure alone, and lists official $RLS contracts on Ethereum, BNB Chain and Rayls. That only adds up if every $RLS outside Ethereum is backed by $RLS locked there. Independently verified: it is. In the same run, at Ethereum block 26,342,082, the lock box held 1,550,237,385.346767 against 1,355,164,746.546035 on Rayls plus 195,072,478.111849 on BNB Chain, so 160.688883 spare (cut to the bridge's 6 shared decimals; the digits after that are dust from direct transfers). But the bridge's own record comes up 40,000,000 short from both ends. On Rayls, all 310 mints sit inside bridge receives, and mints minus 205 burns land exactly 40,000,000 below supply. On Ethereum, 2,425 sends minus 948 receives land exactly 40,000,000 below Rayls plus BNB. $RLS also moves directly between Rayls and BNB, so Ethereum only has to match their total. Where the 40M came from On 28 Apr 2026, two days before the Public Chain went live, one unlabeled account sent 10 $RLS, then 39,999,990, straight into the lock box with a plain transfer and no message. The 160.69 spare is 9 small direct transfers, all on 1 Dec 2025. My analysis: that deposit backs 40,000,000 $RLS placed on Rayls at genesis. It counts as real backing because neither lock box is a proxy or has a withdraw or rescue function (11 write functions each, verified source). Tokens leave only through a bridge message, so the backing is as strong as the settings that decide which messages count. What this adds: neither the docs I read nor the portal show that 40M skipped the bridge. In practice, if you build proof of reserves for a bridged token, reconcile balances and messages together. Balances alone hide the top-up. Messages alone call it a 40M hole. Who sets those settings Documented: LayerZero's docs say there should be one lock box per token, that the owner sets the peer, and that an owner or delegate can change the verifier (DVN) settings, which L2BEAT also notes. Each route here needs 3 required DVNs. On the BRL1 route, the owner on both chains and $BRL1.p's admin is one account with a single onchain signer. The $RLS lock box is owned by a 4 of 6 Safe, while its LayerZero delegate is that same account. Still unconfirmed Rayls genesis state, since the public RPC has pruned it, and who controls the depositing account. A single onchain signer can still be an MPC or hardware key offchain, which I can't see from the chain. Onchain proof also stops at $BRL1 on Polygon; the reais behind it rest on the issuer's monthly attestations. @RaylsLabs @x10xalex one question: is moving the BRL1 route and that delegate role under the 4 of 6 Safe planned, or does that account already sit behind MPC custody? Checker, data and every tx are in the reply

In a private atomic swap, what happens if the other side never delivers? If you run settlement for a desk that swaps tokenized bonds against cash, that is the first thing to check. So I ran the open-source Enygma DvP code from Rayls on a local Hardhat chain and followed one failed swap until the refund left the vault Short answer: the refund works, and a stranger can trigger it after the deadline but can't touch the money. Nobody is paid to make that call, though What I ran 12 of the repo's own tests (25 subtests), mostly swaps and timeouts, untouched, plus my own test. All passed in a GitHub Codespace at commit 135637a Rayls pushed a new commit to main the same day (3dd403e), so I reran everything on it, in the Codespace and on a fresh GitHub Actions runner. Same results. Unlike the repo's deadline test, mine uses a stranger as the caller Verified in my logs Alice deposits 50 tokens and opens a swap for Bob's NFT. The flow doc shows a 60 second deadline, but the contract refuses it with SwapDeadlineTooSoon. Its floor is 15 minutes, so I used 960 seconds Her note is now locked, not spent. A fresh account, neither Alice nor Bob, calls claimSwapTimeout early and gets SwapNotExpiredYet. After I move the chain clock 965 seconds, the same account tries again and it goes through Inside the vault, her original note is marked spent and a new refund note appears. She withdraws it to a fresh address: recipient +50, vault -50. Spending the refund again fails with InvalidNullifier, and so does the original note Who gets to press the button Documented: the contract comment calls claimSwapTimeout "Deliberately callable by ANYONE". The reason: a front-runner could file Alice's public leg first, so a submitter-only rule could strand her note. Opening it to anyone is safe: her own proof fixes the refund. Verified: the stranger's call inserted exactly the refund note her proof named Bitcoin's hash time-locked swaps (BIP 199) work the other way: the refund branch needs the buyer's own signature after the timeout. My read on the trade-off: an HTLC refund waits for its owner, while here anyone can act for her, but nobody is paid to That stranger spent 517,610 gas on 135637a and 512,081 in three reruns on 3dd403e, with no reward. My read: a wallet should plan to make this call itself, as it tracks the deadline The second exit On 28 Oct I tested it too, in the Codespace and on Actions. Through SwapRelayer, a stranger's cancelSwap is refused before the expiry and accepted after. Her original note comes back free and unspent, with no new note, and she withdraws it: +50. A second spend fails In the Codespace run the relayer was cheaper at both ends: Alice's leg 949,938 gas vs 1,006,630 direct, and the cancel 198,392 vs 512,081 for the timeout. My read: the timeout pays for a nullifier write and a new note What an observer sees Who sent each transaction and the swap's commitments, but no amount. The 50 only shows up at the edges, as ERC20 transfers into and out of the vault. My read: an address that both deposits and submits the leg, as my test account did, is easy to link Why a local chain The repo's own tests only run against a local Hardhat node, and I couldn't find a public deployment of these contracts. A timeout test also needs a clock I can move: locally I skip the 15 minute floor in one call and rerun in minutes The cost is realism: demo accounts its config marks "FOR DEMO AND LOCAL DEVELOPMENT PURPOSES ONLY" and keys from its own keygen. Still unconfirmed: anything on a deployed network @myaksetig I keep wondering: the repo's deploy script doesn't ship SwapRelayer, yet that route was cheaper at both ends of my failed swap. Which route should a wallet default to? @RaylsLabs curious about gas too: with nobody paid to call claimSwapTimeout, do you expect wallets or relayers to make that call? Logs, tests and sources in the reply

Can a crypto vault change its rules after you've deposited? If you're about to put stablecoins into a real-world-asset vault, ask this first. The short answer is yes, when one key can upgrade the code, and you can check who holds that key yourself. I checked it on the first Rayls vault, whose launch-deposit contract took in 250,000 $BRL1.p in its first two days. All nine deposits, from six wallets, landed by 16 Oct 15:39 UTC, and as of 24 Oct none has arrived since. Documented: the original code, VaultSeed 1.0.0, is verified on the Rayls explorer. It fixes each deposit's RLS when it's made, a comment says "Rates of weeks that have opened are frozen, so per-week RLS stays derivable", and setWeek reverts with WeekAlreadyOpened once a week has opened. Independently verified with my read-only script, cross-checked on the explorer: on 19 Oct at 15:48:50 UTC, in block 12820048, one account (0x633A...1ce1) deployed new code and switched the contract to it in that same block. No onchain waiting period. The new code reports VERSION 1.1.0, and as of 23 Oct its source isn't published. 63 seconds later the same account called a new function, 0xf2eab735, with 5000. The log shows WeekSet for week 1, still open until 22 Oct, at 5,000 RLS per 1,000, down from the 10,000 the contract logged at launch on 14 Oct. By hash, 0xf2eab735 matches setOpenWeekRate(uint128). Upgrades were expected: the verified code says RLS payout comes "in a later upgrade". This one didn't add that. It keeps all 56 old entry points and adds two, setOpenWeekRate and 0xb5190e4a, an unnamed getter. That account holds the admin, upgrader, operator and pauser roles, and the contract's events show nobody else was ever granted admin or upgrade rights. It has 0 bytes of code, so onchain it is one key, not a multisig contract. Here's the reassuring part. Every deposit came before the change, so all six wallets kept 10,000 RLS per 1,000 $BRL1.p, matching what AJ said at the Rayls AMA on 20 Oct (8:18). Nobody's reward was cut. But week 1 now reads 5,000, so the contract's own rate table no longer explains what week 1 was credited: 1,250,000 RLS at today's rate, 2,500,000 actually credited. My own AMA question on code verification and upgrade controls was read at 34:56. The answer was that the vault technology comes from Lagoon and is audited (clip trimmed, full answer 35:04 to 35:50). Lagoon's docs add the part that matters: upgrades only go to Lagoon-whitelisted code, and each waits a delay the admin sets between 24 hours and 30 days. My analysis: that answer covers the vault, and it's a good one. The money today sits in the separate deposit contract, whose vault() was still unset on 23 Oct, and that contract changed in one block. A delay matters less while deposits are locked until 19 Nov, because you couldn't leave anyway. What it buys is time for anyone to read new code before it runs. AJ expects a lock of about 3 months in the vault too (22:08), so the same trade-off carries over. My opcode diff finds nothing else changed in the old functions beyond shifted addresses, the version string, the code's own address and how one event ID is loaded. That's a bytecode reading; only the published source can prove it. To be fair, this is a pilot, the rate cut for new deposits was announced, the launch blog says the terms aren't final, and AJ said at 8:39 there's no promise rates stay the same. Still unconfirmed: how that key is protected off-chain. MPC or a hardware wallet would still look like one key onchain. @RaylsLabs a question no public source answers yet: will the launch-deposit code be verified before 19 Nov, and will its upgrades move behind a delay like Lagoon's? Before you deposit into any vault, look up who can upgrade it and how long they'd have to wait. Script, data and both bytecode comparisons are in the reply.

How can a bridge or light client check who really signed each validator handover on the Rayls Public Chain? From the signed handover record itself. All 170 since launch pass my own checker, and on 18 October the committee is set to grow from 7 to 8 for the first time. Each handover will then need 6 signatures instead of 5, yet can still only lose 2. I didn't want to take a node's word for any of this. Every day the chain writes a record naming the current committee, the next one and the last block of the day, and the outgoing validators sign it with BLS signatures combined into one. Sui uses the same pattern with its end-of-epoch checkpoint. So I wrote the checker in Go and ran it read-only against the public RPC on 16 October, covering every record from launch on 30 April to that day's handover. For each one I rebuilt the hash, checked the combined signature against that committee's keys, confirmed it links to the record before it, and found its checkpoint block with the same hash on both the RPC and the explorer. The 7 keys match the ConsensusRegistry contract. Forged versions fail: a signature from another day, one signer removed, one block number changed. One correction for the docs. rpc.md says rayls_epochRecordByHash takes keccak256(encode(record)), but the code hashes with blake3, and the node agrees: the blake3 hash of record 169 returns it, the keccak256 hash returns nothing. Then a pattern I didn't expect. Up to 10 September, 17 of 134 records carried the bare minimum of 5 signatures (13%). From 11 September, 21 of 36 did (58%). That doesn't show validators going offline. A certificate is sealed once quorum is in (the current code saves it at that moment, the older code after a one-second lull), so a late vote simply misses it. Every validator signed between 131 and 163 of the 170. My read: 11 September is also when, in my earlier check, the daily changeover pause jumped from 2 to 32 seconds, a day after rounds sped up. A busier boundary could make the last votes late. I can't see vote timing from outside, so that stays a hypothesis. Now the change. 0xbbd0b352...9662 was allowlisted on 15 Oct at 15:28 UTC, staked 5,000,000 RLS on 16 Oct at 06:40 and called activate 49 seconds later. At 09:17 UTC my check showed it as PendingActivation. After the 15:58 handover it was Active, and getCommitteeValidators(172) returned 8. That fits the code, which builds each committee three epochs ahead from active and pending validators. Its key also had to pass an onchain proof-of-possession check when it staked. That matters because the IETF BLS draft only treats combining signatures on the same message as safe when every key comes with such a proof. The arithmetic, from the quorum formula in epoch.rs, floor(2n/3)+1: 7 validators need 5 signatures, 8 need 6. Both can lose 2 and still certify a handover. What 8 adds is overlap: any two groups of 6 share at least 4 validators, versus 3 for groups of 5. Slack only grows at 10, the next size in the n = 3f+1 model these DAG protocols target. What I have not verified: everything came through one public node, an observer, and the explorer is a second view of the same chain, not a second node. I can't see why signatures dropped after 10 September, or which version of the collection code mainnet runs. Record 171, due on 18 October, should be the first to carry the 8-key list. For a bridge or light client: verify the record, don't treat the signer count as a health check, and plan for 6 from epoch 172. @RaylsLabs one thing I can't see from outside: are mainnet validators already on the PR 186 code that seals the certificate at quorum, or on the older one-second version? That decides how to read the 58%. Code, raw data and method are in the reply.

How long does a zero-knowledge proof take for a private payment? I ran the open-source Rayls prover on an old two-core laptop: typically 1.5 to 3 seconds per transfer once warm, and 8 to 24 seconds for the very first one If you're a payments engineer at a bank weighing private settlement, plan around that slow first proof, not the warm ones. What Rayls documents: their 19 Sep blog "Privacy has a price" says a single proof for a basic confidential transfer "can take from several hundred milliseconds to several seconds on commodity hardware, depending on the circuit complexity". No hardware or benchmark is named. The repo README says its keys come from a single-party setup and are for development and testing only, so this is a test bench, not production. What I verified myself (10 Oct, UTC, commit 67c4c26, Core i3-6006U, prover log "acceleration=none"): The transfer circuit hides a payment among k accounts. A constraint is one equation the proof has to satisfy. At k=2 it's 37,140 constraints, at k=6 it's 69,588. From k=2 to k=6, each extra account adds exactly 8,112. Warm proofs at k=6 had a median of 3.04 s and 3.02 s in two sessions. At k=2, medians of 1.55 to 2.11 s. The first request is slower because the server loads that circuit and its key: k=6 took 15.5 to 23.6 s cold. The server's own log splits a warm k=6 proof into about 0.4 to 0.75 s of solving the circuit and 2.2 to 3.3 s of building the proof, and its own totals were within 0.1 s of my timer. The time is the math, not the network call. One session ran k=6 at a median of 6.15 s, twice as slow, on the same laptop. I couldn't find the cause. A controlled rerun, charger in and nothing else open, went back to 3.02 s. Sending 1,001 from a balance of 1,000, with the commitments recomputed so everything looks consistent, was refused by the circuit in about half a second. 1,000 of 1,000 passed. Then I checked the proof outside their server. Their own Solidity verifier in Remix (sandbox VM, no chain) returned true for my proof and false after I changed one public input, block 1497 to 1498. A second check against the verifier's constants agreed. My analysis: for warm proofs, their range holds on this laptop, but only at the slow end. Nothing came near a few hundred milliseconds. For scale, gnark's docs quote over 2 million constraints per second on an AWS HPC server for large circuits, while this laptop did roughly 23,000 per second end to end. Not a fair comparison, but it shows why "commodity hardware" needs a spec. The blog title is literal here. From the k=2 and k=6 medians of my two matching sessions, each extra account in the anonymity set cost this laptop roughly 0.2 to 0.4 s of proving. And for anyone running this, the cold start is the practical lesson: load the keys when the node starts, not on the first payment. The team told me k is a system parameter that can go up to 100. If the same step holds, that's about 832,000 constraints, 12x k=6. I didn't test it. Verification is the cheap side. Priced with Ethereum's EIP-1108 costs, this k=6 verifier needs about 488,500 gas for the curve math alone (50 x 6,150 + 45,000 + 4 x 34,000), plus 49,200 per extra account. That's my arithmetic, not a measurement, and Rayls ledgers may not price it this way. Proving time has been the cost to beat before: Zcash's 2018 Sapling upgrade was announced as cutting the time to build a shielded transaction by about 90%. Still unconfirmed: production hardware, GPU acceleration, production keys, and why that one session slowed down. Small find: the repo's Postman samples for Deposit and Withdraw no longer match the API. @RaylsLabs which hardware is behind the several-hundred-millisecond figure? @myaksetig does production Enygma load proving keys when the prover starts, or on the first request like the public repo? Video below. Scripts, CSVs and links in the first reply

If you run settlement for a bank on the Rayls Public Chain, there is one minute a day worth putting in your calendar: 15:59 UTC Since 11 September, every changeover at that minute has come with 6 to 34 seconds of no new block. In early September it was 1 to 2 seconds That minute is when the chain closes one day, called an epoch, and opens the next. I wanted to know what changed, so I measured it myself with read-only calls on 2 and 3 October First, who runs the chain. The ConsensusRegistry contract returned 7 active validators and already listed the committee for the next two days. With seven, five have to agree for the chain to move, the usual Bullshark rule the node follows Then I watched the 2 October changeover live. My screen stayed on block 11503284 from 15:58:54 to 15:59:16 UTC. The next check, at 15:59:21, showed block 11503285, with the registry already on the new day Here is the odd part. The explorer stamps that block 15:58:53, so the last block of the old day carries a time from before the pause but only reached me after it. The blocks on both sides were empty, and the new committee matched the one written in advance Next I wanted the history. The registry has no event logs, but every block header carries its epoch and round number, so I found the first block of all 156 epochs since launch on 30 April. Every one started within about a minute of 15:59 UTC The pause itself kept moving: 1 to 2 seconds in May, about 18 on most June days, 4 to 6 on most days in July and August, 1 to 2 from 28 August, then 2 to 16 from 5 to 10 September Then the surprise. Around 14:02 UTC on 10 September the voting rounds got almost twice as fast, from 0.65 to 0.35 seconds each, with the same validators. A day went from about 132,900 rounds to about 245,000 to 250,000 That day's changeover, two hours later, paused for 2 seconds. The next one, after a full day at the new speed, paused for 32. None since has been under 6 So why the pause? My read: at each changeover the node stops and saves its consensus data to disk before the new day can start. A comment in the node's code (transition.rs) says a backlog built up over the day "surfaces here as a network-wide transition pause" The same code only processes the last block after that save, which matches what my screen showed. More rounds, more to save But that is not the whole story. The pause was already 3 to 16 seconds the week before the speed-up, June had 18-second pauses at the old block speed, and since 10 September it swings from 6 to 34 seconds while the round count barely moves One correction on my own method. My first scan showed gaps of hours, but that was me, not the chain On 18 days between June and late August, some blocks before the changeover carry older timestamps, matching the team's own write-up of the 21 June halt. Measured from the latest real block, the longest pause in five months was 47 seconds What I have not verified: I did not send a payment during a pause, so I cannot say when it would land. I watched one changeover live, timed by my PC clock I also cannot see what changed on 10 September. There is no release tag that day, and the mainnet settings file left the public repo on 9 September in PR 153. All of this is the Public Chain only So for a settlement team the changeover is a scheduled minute, not a random stall: same time every day, validators known two days ahead. It has lasted longer since the chain sped up, and the code already names the guard: "the real guard is keeping the queue shallow" @luishsoares your PR 102 made committee size and participation visible, but as far as I can see the pause itself is not tracked as a metric. Is a changeover-duration metric planned? And @RaylsLabs what changed around 14:02 UTC on 10 September, was it the first rollout after PR 153? Scripts and data are in the reply, so anyone can rerun every number