Binance Square
Lào Thoại Ngân
268 投稿

Lào Thoại Ngân

278 フォロー
70 フォロワー
131 いいね
投稿
·
--
翻訳参照
A profile with zero completed orders messaged me wanting to buy $4000 worth of crypto on Binance P2P in a single trade. No history, no reviews, account created that same week. I did not refuse automatically, since everyone starts somewhere, but I slowed the whole process down and treated it like a case study in what verification is actually for. Binance P2P requires every user to pass identity verification before trading, which already filters out a huge share of casual scammers who rely on anonymity. On top of that baseline, I look at three things before accepting any counterparty: their completion rate, how long their account has existed, and the pattern of their past trade sizes. Someone jumping straight from no history to a large order is not proof of bad intent, but it raises the amount of care I bring to confirming payment. For this particular trade, I asked to split it into two smaller orders instead of one large one. He agreed without pushback, which told me more than any badge could. Halfway through, I checked my banking app directly rather than trusting the payment notification he sent in chat, confirmed the exact amount had landed, and only then released the crypto for each portion. Red flags I watch for beyond account age: requests to leave the official Binance P2P chat, urgency language pushing me to skip steps, and payment proof that arrives suspiciously fast with no bank reference number attached. None of those appeared here, so the trade closed cleanly. Splitting the order also gave me a natural checkpoint. If the first portion had gone wrong in any way, I would have stopped before the second payment ever moved, instead of committing the full amount up front to someone I had no track record with. I still saved the order number and my banking confirmation for both portions, because keeping records costs nothing and Binance P2P support will always ask for them if anything gets disputed later. New traders deserve a fair chance, but a fair chance is not the same thing as skipping verification. @Binance_Vietnam #BinanceP2PAnToan $BTW $BLESS
A profile with zero completed orders messaged me wanting to buy $4000 worth of crypto on Binance P2P in a single trade. No history, no reviews, account created that same week. I did not refuse automatically, since everyone starts somewhere, but I slowed the whole process down and treated it like a case study in what verification is actually for.

Binance P2P requires every user to pass identity verification before trading, which already filters out a huge share of casual scammers who rely on anonymity. On top of that baseline, I look at three things before accepting any counterparty: their completion rate, how long their account has existed, and the pattern of their past trade sizes. Someone jumping straight from no history to a large order is not proof of bad intent, but it raises the amount of care I bring to confirming payment.

For this particular trade, I asked to split it into two smaller orders instead of one large one. He agreed without pushback, which told me more than any badge could. Halfway through, I checked my banking app directly rather than trusting the payment notification he sent in chat, confirmed the exact amount had landed, and only then released the crypto for each portion.

Red flags I watch for beyond account age: requests to leave the official Binance P2P chat, urgency language pushing me to skip steps, and payment proof that arrives suspiciously fast with no bank reference number attached. None of those appeared here, so the trade closed cleanly.

Splitting the order also gave me a natural checkpoint. If the first portion had gone wrong in any way, I would have stopped before the second payment ever moved, instead of committing the full amount up front to someone I had no track record with.

I still saved the order number and my banking confirmation for both portions, because keeping records costs nothing and Binance P2P support will always ask for them if anything gets disputed later. New traders deserve a fair chance, but a fair chance is not the same thing as skipping verification.

@Binance Vietnam #BinanceP2PAnToan $BTW $BLESS
翻訳参照
I use the name on a Binance P2P payment as a security signal, not a formality. A common danger begins when the buyer says a spouse, customer, colleague, or company will send the money. The deposit may be real, yet the person whose funds moved may not be the verified counterparty. That can point to a triangle scam, a disputed transfer, or an account being used without clear authority. My checklist begins with the order, not the bank alert. I review the counterparty profile, completed activity, terms, and payment method. KYC helps establish the Binance user's identity, while escrow reserves the crypto during the trade. I then compare that verified name with the payer name visible in my payment account. If they do not match, I do not release, negotiate a workaround, or return funds to a new account supplied in chat. I keep the conversation in the order chat and describe the mismatch plainly. This matters because Binance Support can inspect the on-platform timeline if an appeal is needed. A request to discuss elsewhere, split the payment among several senders, hide a crypto-related note, or refund to a different beneficiary raises the risk further. I take screenshots or records of the order, payer details, transaction ID, amount, and chat without exposing them publicly. Payment verification still comes next. Even with a matching name, I open the official bank or wallet app, confirm the exact amount is credited and usable, and ignore screenshots or "successful" messages from the buyer. Identity alignment does not replace receipt confirmation, and receipt confirmation does not excuse an identity mismatch. When the facts disagree, I leave the asset in escrow and select Appeal or contact Binance Support from the official platform. I would rather explain a delayed release with evidence than turn a suspicious payment into an irreversible loss. My rule has 3 matching lines: Binance identity, payment-account name, and order details. If one line breaks, the trade pauses. @Binance_Vietnam #BinanceP2PAnToan $BTW $ON $HFT
I use the name on a Binance P2P payment as a security signal, not a formality. A common danger begins when the buyer says a spouse, customer, colleague, or company will send the money. The deposit may be real, yet the person whose funds moved may not be the verified counterparty. That can point to a triangle scam, a disputed transfer, or an account being used without clear authority.

My checklist begins with the order, not the bank alert. I review the counterparty profile, completed activity, terms, and payment method. KYC helps establish the Binance user's identity, while escrow reserves the crypto during the trade. I then compare that verified name with the payer name visible in my payment account. If they do not match, I do not release, negotiate a workaround, or return funds to a new account supplied in chat.

I keep the conversation in the order chat and describe the mismatch plainly. This matters because Binance Support can inspect the on-platform timeline if an appeal is needed. A request to discuss elsewhere, split the payment among several senders, hide a crypto-related note, or refund to a different beneficiary raises the risk further. I take screenshots or records of the order, payer details, transaction ID, amount, and chat without exposing them publicly.

Payment verification still comes next. Even with a matching name, I open the official bank or wallet app, confirm the exact amount is credited and usable, and ignore screenshots or "successful" messages from the buyer. Identity alignment does not replace receipt confirmation, and receipt confirmation does not excuse an identity mismatch.

When the facts disagree, I leave the asset in escrow and select Appeal or contact Binance Support from the official platform. I would rather explain a delayed release with evidence than turn a suspicious payment into an irreversible loss. My rule has 3 matching lines: Binance identity, payment-account name, and order details. If one line breaks, the trade pauses.

@Binance Vietnam #BinanceP2PAnToan $BTW $ON $HFT
翻訳参照
"Not your keys, not your coins" has been crypto's oldest warning, and it's mostly been aimed at exchanges. Babylon applies the same logic somewhere people rarely think to ask it: DeFi borrowing itself. Depositors using Trustless Bitcoin Vaults keep control of their Bitcoin through the entire loan, it stays locked on the Bitcoin network in a Taproot output rather than moving into a lending desk's custody or a bridge's reserve wallet. I want to be precise about what self-custodial actually covers here, because I think the phrase gets used a little too cleanly in crypto marketing generally. The private keys controlling redemption stay with the depositor's designated address. But the system as a whole still depends on other participants behaving correctly: Vault Providers who manage vault claims, Arbitrageurs who buy seized collateral during liquidations, and Universal Challengers watching for invalid redemption attempts. None of them can move your BTC without a valid proof, and any of them, including you, can challenge a bad claim. That's meaningfully different from custodial risk, but it isn't the complete absence of dependency on other people. What Babylon has actually removed is the single point of failure, no custodian can freeze funds, no bridge operator can disappear with the reserve, no signer quorum can collude to move coins outside the rules written into the Taproot script itself. Borrowing supported assets such as USDC or USDT against native BTC through Aave v4 while your Bitcoin sits exactly where you locked it is a real structural shift from how BTC-backed lending has worked until now, even if "trustless" describes the math rather than a world with zero remaining actors. @babylonlabs_io $BTW $GRVT #baby $BABY {spot}(BABYUSDT)
"Not your keys, not your coins" has been crypto's oldest warning, and it's mostly been aimed at exchanges. Babylon applies the same logic somewhere people rarely think to ask it: DeFi borrowing itself. Depositors using Trustless Bitcoin Vaults keep control of their Bitcoin through the entire loan, it stays locked on the Bitcoin network in a Taproot output rather than moving into a lending desk's custody or a bridge's reserve wallet.

I want to be precise about what self-custodial actually covers here, because I think the phrase gets used a little too cleanly in crypto marketing generally. The private keys controlling redemption stay with the depositor's designated address. But the system as a whole still depends on other participants behaving correctly: Vault Providers who manage vault claims, Arbitrageurs who buy seized collateral during liquidations, and Universal Challengers watching for invalid redemption attempts. None of them can move your BTC without a valid proof, and any of them, including you, can challenge a bad claim. That's meaningfully different from custodial risk, but it isn't the complete absence of dependency on other people.

What Babylon has actually removed is the single point of failure, no custodian can freeze funds, no bridge operator can disappear with the reserve, no signer quorum can collude to move coins outside the rules written into the Taproot script itself. Borrowing supported assets such as USDC or USDT against native BTC through Aave v4 while your Bitcoin sits exactly where you locked it is a real structural shift from how BTC-backed lending has worked until now, even if "trustless" describes the math rather than a world with zero remaining actors.

@BabylonLabs_io $BTW $GRVT #baby $BABY
翻訳参照
Most people who know Babylon know it first as a security layer, a protocol that lets Bitcoin's economic weight back the finality of proof of stake chains. That's not a small thing. Extending Bitcoin's security to PoS blockchains solves a real problem: young or smaller chains don't have decades of accumulated hash power or economic stake behind them, so Babylon lends them Bitcoin's credibility instead. I've been thinking about this original mission while reading through the recent Trustless Bitcoin Vaults announcement, because the through-line is more consistent than I expected. Trustless Bitcoin Vaults takes the same instinct, using Bitcoin's trust and security without weakening it, and applies it to lending. The first use case, native Bitcoin-backed borrowing with Aave v4, is live on public testnet with several major brands already testing it. Depositors post native BTC as collateral and borrow assets like USDC or USDT on Ethereum, and none of it requires wrapping or bridging the underlying asset. What I want to understand better is whether the security guarantees from the staking side actually translate into the vault mechanics, or whether these are 2 separate trust models running under one brand. Babylon hasn't fully answered that in public documentation as far as I've found, and it's the kind of technical detail that determines whether this is one coherent architecture or 2 good ideas bolted together. Either way, the ambition is consistent: make Bitcoin useful without asking anyone to trust a third party with it. @babylonlabs_io $BTW $GRVT $BABY #baby {spot}(BABYUSDT)
Most people who know Babylon know it first as a security layer, a protocol that lets Bitcoin's economic weight back the finality of proof of stake chains. That's not a small thing. Extending Bitcoin's security to PoS blockchains solves a real problem: young or smaller chains don't have decades of accumulated hash power or economic stake behind them, so Babylon lends them Bitcoin's credibility instead. I've been thinking about this original mission while reading through the recent Trustless Bitcoin Vaults announcement, because the through-line is more consistent than I expected.

Trustless Bitcoin Vaults takes the same instinct, using Bitcoin's trust and security without weakening it, and applies it to lending. The first use case, native Bitcoin-backed borrowing with Aave v4, is live on public testnet with several major brands already testing it. Depositors post native BTC as collateral and borrow assets like USDC or USDT on Ethereum, and none of it requires wrapping or bridging the underlying asset.

What I want to understand better is whether the security guarantees from the staking side actually translate into the vault mechanics, or whether these are 2 separate trust models running under one brand. Babylon hasn't fully answered that in public documentation as far as I've found, and it's the kind of technical detail that determines whether this is one coherent architecture or 2 good ideas bolted together. Either way, the ambition is consistent: make Bitcoin useful without asking anyone to trust a third party with it.

@BabylonLabs_io $BTW $GRVT $BABY #baby
翻訳参照
Show most people a headline about Bitcoin becoming DeFi collateral and they assume it's the same trick again: mint a token somewhere else, call it Bitcoin, move on. That reaction isn't stupid. Less than 1% of all bitcoin sits on smart contract platforms today, and nearly every route that gets it there involves a wrapper or a custodian holding the real coins while a synthetic version circulates. Babylon Trustless Bitcoin Vaults were built against that exact pattern. When native Bitcoin backed borrowing went live on Aave v4 public testnet on June 2, 2026, the BTC involved never left the Bitcoin chain. It sits locked in a Taproot UTXO, and Aave recognizes the position through a transfer-restricted token called vaultBTC that represents the vault rather than replacing the coin. Compare that to how wrapped Bitcoin has worked for years, where a centralized issuer holds BTC in reserve and mints a separate asset elsewhere, a structure Babylon's own vault paper points to directly when arguing wrapped and custodial Bitcoin adoption has stayed limited relative to Bitcoin's total supply. The signal that this is a different model, not sharper packaging on an old one, showed up again in March 2026, when Babylon partnered with Ledger so its 8 million hardware wallet users could approve vault actions through Clear Signing, reading the real transaction on their own device screen instead of trusting a browser popup or an issuer's word. Babylon isn't rebranding wrapped Bitcoin with better marketing, it's refusing that model's central move, the part where custody quietly changes hands. TBV still carries its own risks, mostly around Aave's liquidators and oracles, but "another wrapped coin" isn't one of them. @babylonlabs_io $AKE $BTW $BABY #baby
Show most people a headline about Bitcoin becoming DeFi collateral and they assume it's the same trick again: mint a token somewhere else, call it Bitcoin, move on. That reaction isn't stupid. Less than 1% of all bitcoin sits on smart contract platforms today, and nearly every route that gets it there involves a wrapper or a custodian holding the real coins while a synthetic version circulates.

Babylon Trustless Bitcoin Vaults were built against that exact pattern. When native Bitcoin backed borrowing went live on Aave v4 public testnet on June 2, 2026, the BTC involved never left the Bitcoin chain. It sits locked in a Taproot UTXO, and Aave recognizes the position through a transfer-restricted token called vaultBTC that represents the vault rather than replacing the coin. Compare that to how wrapped Bitcoin has worked for years, where a centralized issuer holds BTC in reserve and mints a separate asset elsewhere, a structure Babylon's own vault paper points to directly when arguing wrapped and custodial Bitcoin adoption has stayed limited relative to Bitcoin's total supply.

The signal that this is a different model, not sharper packaging on an old one, showed up again in March 2026, when Babylon partnered with Ledger so its 8 million hardware wallet users could approve vault actions through Clear Signing, reading the real transaction on their own device screen instead of trusting a browser popup or an issuer's word.

Babylon isn't rebranding wrapped Bitcoin with better marketing, it's refusing that model's central move, the part where custody quietly changes hands. TBV still carries its own risks, mostly around Aave's liquidators and oracles, but "another wrapped coin" isn't one of them.

@BabylonLabs_io $AKE $BTW $BABY #baby
翻訳参照
Every time I mention Babylon's Trustless Bitcoin Vaults to someone new, the first question is some version of, so it's basically WBTC with extra steps. I understand the reflex. Bitcoin holders have watched years of bridge hacks and custodial failures, and the mental shortcut of new bitcoin product equals new wrapped token equals new counterparty risk is not an unreasonable prior to carry around. It is also wrong here, and the mechanics show why. Wrapped BTC products like WBTC work by handing coins to a custodian who mints a matching token elsewhere, so users are trusting that one entity to hold reserves honestly and stay solvent. Bridges move BTC by routing it through a federation of signers who collectively control the funds. TBV does neither. The bitcoin stays in a self-custodial, pre-signed vault on the Bitcoin chain itself, and it never gets represented as a freely tradable IOU on another network. Access to it is gated by a zero-knowledge proof tied to a specific external smart contract state, not by an entity's promise to redeem a token 1 to 1. One widely cited figure captures the problem TBV is aimed at: over 99 percent of bitcoin sits idle, with roughly 1 percent touching DeFi at all, mostly through custodied wrapped products. Babylon is not running a wrapping business and TBV is not a bridge, despite how familiar the pitch sounds at first mention. The custodian and the federation are the two things this design was built to remove, not repackage. @babylonlabs_io $BTW $AKE $BABY #baby
Every time I mention Babylon's Trustless Bitcoin Vaults to someone new, the first question is some version of, so it's basically WBTC with extra steps. I understand the reflex. Bitcoin holders have watched years of bridge hacks and custodial failures, and the mental shortcut of new bitcoin product equals new wrapped token equals new counterparty risk is not an unreasonable prior to carry around.

It is also wrong here, and the mechanics show why. Wrapped BTC products like WBTC work by handing coins to a custodian who mints a matching token elsewhere, so users are trusting that one entity to hold reserves honestly and stay solvent. Bridges move BTC by routing it through a federation of signers who collectively control the funds. TBV does neither. The bitcoin stays in a self-custodial, pre-signed vault on the Bitcoin chain itself, and it never gets represented as a freely tradable IOU on another network. Access to it is gated by a zero-knowledge proof tied to a specific external smart contract state, not by an entity's promise to redeem a token 1 to 1. One widely cited figure captures the problem TBV is aimed at: over 99 percent of bitcoin sits idle, with roughly 1 percent touching DeFi at all, mostly through custodied wrapped products.

Babylon is not running a wrapping business and TBV is not a bridge, despite how familiar the pitch sounds at first mention. The custodian and the federation are the two things this design was built to remove, not repackage.

@BabylonLabs_io $BTW $AKE $BABY #baby
翻訳参照
Your keys, your Bitcoin sounds simple until you read the fine print on how a self-custodial vault actually enforces that promise when something goes wrong. I went through Babylon's testnet documentation specifically to find that fine print, because slogans do not survive contact with edge cases. Trustless Bitcoin Vaults deposit BTC into a vault where, under normal conditions, a Vault Provider handles the Bitcoin-side redemption once a loan is repaid. Babylon's design does not stop there though. Every user downloads a WOTS keypair file and claimer artifacts at the moment the vault is created, existing specifically so a depositor can redeem their own Bitcoin without needing the Vault Provider at all, if that provider ever goes offline. That is a real self-custody guarantee, not a marketing phrase. No third party, custodian, or signer consortium holds discretionary power over the underlying BTC. But it comes with a responsibility I do not think casual users fully appreciate yet: the WOTS keypair cannot be regenerated if lost, and Babylon's own guidance says to treat losing it as seriously as losing a wallet seed phrase. I like that the fallback exists. I am less sure the average depositor backing up one more irreplaceable secret file, on top of a seed phrase, is a UX problem Babylon has fully solved yet. Genuine trustlessness has a cost, and here the cost is personal responsibility. @babylonlabs_io $1000RATS $GRVT $BABY #baby
Your keys, your Bitcoin sounds simple until you read the fine print on how a self-custodial vault actually enforces that promise when something goes wrong. I went through Babylon's testnet documentation specifically to find that fine print, because slogans do not survive contact with edge cases.

Trustless Bitcoin Vaults deposit BTC into a vault where, under normal conditions, a Vault Provider handles the Bitcoin-side redemption once a loan is repaid. Babylon's design does not stop there though. Every user downloads a WOTS keypair file and claimer artifacts at the moment the vault is created, existing specifically so a depositor can redeem their own Bitcoin without needing the Vault Provider at all, if that provider ever goes offline.

That is a real self-custody guarantee, not a marketing phrase. No third party, custodian, or signer consortium holds discretionary power over the underlying BTC. But it comes with a responsibility I do not think casual users fully appreciate yet: the WOTS keypair cannot be regenerated if lost, and Babylon's own guidance says to treat losing it as seriously as losing a wallet seed phrase.

I like that the fallback exists. I am less sure the average depositor backing up one more irreplaceable secret file, on top of a seed phrase, is a UX problem Babylon has fully solved yet. Genuine trustlessness has a cost, and here the cost is personal responsibility.

@BabylonLabs_io $1000RATS $GRVT $BABY #baby
翻訳参照
Every few months another Bitcoin DeFi product launches promising native, trustless access, and every few months it turns out to mean the same custodian-minted token with a new name attached. WBTC has run since 2019, cbBTC since late 2024, and together they still represent under 1 percent of Bitcoin's total market cap. That is not a rounding error, it is a sign that most BTC holders never trusted the wrapping model enough to actually use it at scale. So when I first read that Trustless Bitcoin Vaults also mint something called vaultBTC on Ethereum, my first reaction was skepticism, because on paper that sounds exactly like WBTC with a rebrand. A token representing locked Bitcoin, minted on Ethereum, used as collateral. Same shape, same pitch, I assumed. The difference shows up once you look at who can move that token and why. WBTC and cbBTC are minted and burned at a custodian's discretion. vaultBTC transfers are restricted to the Aave V4 Hub, the Babylon Core Spoke, and the adapter contract, and redemption back to native Bitcoin runs through a zero knowledge proof of an Ethereum event rather than a custodian's signature. There is no signer consortium and no third party with discretionary control over the underlying BTC. It looks like a wrapped token from a distance. Up close, the minting authority is cryptography, not a company. Babylon isn't running a custodial wrapper with better marketing copy. vaultBTC only exists as a restricted receipt for BTC that cryptography, not a custodian, agreed to release, and that distinction is the entire point of the design. @babylonlabs_io $BANK $ON $BABY #baby
Every few months another Bitcoin DeFi product launches promising native, trustless access, and every few months it turns out to mean the same custodian-minted token with a new name attached. WBTC has run since 2019, cbBTC since late 2024, and together they still represent under 1 percent of Bitcoin's total market cap. That is not a rounding error, it is a sign that most BTC holders never trusted the wrapping model enough to actually use it at scale.

So when I first read that Trustless Bitcoin Vaults also mint something called vaultBTC on Ethereum, my first reaction was skepticism, because on paper that sounds exactly like WBTC with a rebrand. A token representing locked Bitcoin, minted on Ethereum, used as collateral. Same shape, same pitch, I assumed.

The difference shows up once you look at who can move that token and why. WBTC and cbBTC are minted and burned at a custodian's discretion. vaultBTC transfers are restricted to the Aave V4 Hub, the Babylon Core Spoke, and the adapter contract, and redemption back to native Bitcoin runs through a zero knowledge proof of an Ethereum event rather than a custodian's signature. There is no signer consortium and no third party with discretionary control over the underlying BTC. It looks like a wrapped token from a distance. Up close, the minting authority is cryptography, not a company.

Babylon isn't running a custodial wrapper with better marketing copy. vaultBTC only exists as a restricted receipt for BTC that cryptography, not a custodian, agreed to release, and that distinction is the entire point of the design.

@BabylonLabs_io $BANK $ON $BABY #baby
翻訳参照
Trustless gets used as a description of the cryptography in Trustless Bitcoin Vaults, and on that layer it earns the word, the vault's spending conditions are enforced by Bitcoin script and proofs, not a company. I wanted to check whether that same word applies one level up, to whether the vault can actually plug into Aave without anyone's permission. It can't, not yet. Aave v4 organizes liquidity through a Hub that grants credit lines to individual Spokes, and Stani Kulechov has said plainly that new spokes aren't permissionless while the architecture is young, he called it running "in a very controlled training wheels manner" with DAO governance deciding what connects. Babylon's own BTC spokes went through a formal Temperature Check proposal on Aave's governance forum before anything shipped to testnet. Getting listed took a vote, not just a signature. So the vault itself, the part locking your Bitcoin, really does run without a trusted intermediary. The part that lets that vault borrow against Aave's liquidity runs through a DAO that can say no. Both things are true at once, and only one of them is what "trustless" usually implies to someone skimming a headline. Babylon is trustless where custody is concerned, cryptographic conditions replace any custodian. Babylon isn't permissionless where access is concerned, Aave governance still decides which spokes get liquidity. TBV is trust minimized end to end, not permissionless end to end. @babylonlabs_io $ON $BTW $BABY #baby {spot}(BABYUSDT)
Trustless gets used as a description of the cryptography in Trustless Bitcoin Vaults, and on that layer it earns the word, the vault's spending conditions are enforced by Bitcoin script and proofs, not a company. I wanted to check whether that same word applies one level up, to whether the vault can actually plug into Aave without anyone's permission.

It can't, not yet. Aave v4 organizes liquidity through a Hub that grants credit lines to individual Spokes, and Stani Kulechov has said plainly that new spokes aren't permissionless while the architecture is young, he called it running "in a very controlled training wheels manner" with DAO governance deciding what connects. Babylon's own BTC spokes went through a formal Temperature Check proposal on Aave's governance forum before anything shipped to testnet. Getting listed took a vote, not just a signature.

So the vault itself, the part locking your Bitcoin, really does run without a trusted intermediary. The part that lets that vault borrow against Aave's liquidity runs through a DAO that can say no. Both things are true at once, and only one of them is what "trustless" usually implies to someone skimming a headline.

Babylon is trustless where custody is concerned, cryptographic conditions replace any custodian. Babylon isn't permissionless where access is concerned, Aave governance still decides which spokes get liquidity. TBV is trust minimized end to end, not permissionless end to end.

@BabylonLabs_io $ON $BTW $BABY #baby
翻訳参照
Before BitVM3, Babylon's team ran real experiments with BitVM2 for the kind of proof verification its vaults need, and the on-chain transaction costs came back north of $16,000 per operation, a number that kills any hope of retail usage. The team's answer was to rebuild verification around garbled circuits instead of the chunked proof method BitVM2 used, moving almost all computation off chain and leaving Bitcoin with a tiny commitment to check. Independent research on the design puts the efficiency gain at over 1000 times versus BitVM2, with an assert transaction near 56 kilobytes and a disprove transaction near 200 bytes, down from transactions that used to run 2 to 4 megabytes. That is a real engineering win, and it was not free. The old chunked approach kept more of the verification logic legible on Bitcoin itself, even if it was expensive. Garbled circuits compress that logic into an opaque blob that only makes sense during a specific off-chain ceremony between specific parties, which is exactly why critics point to setup honesty as a new assumption. Babylon chose cost first. Babylon is not optimizing for cryptographic purity here, it optimized for cost. Unable to keep verification both cheap and fully legible on Bitcoin, the team turned a $16,000 problem into a roughly $9 one and accepted a new class of off-chain trust in exchange. That is a deliberate trade-off, not an oversight. @babylonlabs_io $BANK $BTW $BABY #baby {spot}(BABYUSDT)
Before BitVM3, Babylon's team ran real experiments with BitVM2 for the kind of proof verification its vaults need, and the on-chain transaction costs came back north of $16,000 per operation, a number that kills any hope of retail usage. The team's answer was to rebuild verification around garbled circuits instead of the chunked proof method BitVM2 used, moving almost all computation off chain and leaving Bitcoin with a tiny commitment to check. Independent research on the design puts the efficiency gain at over 1000 times versus BitVM2, with an assert transaction near 56 kilobytes and a disprove transaction near 200 bytes, down from transactions that used to run 2 to 4 megabytes.

That is a real engineering win, and it was not free. The old chunked approach kept more of the verification logic legible on Bitcoin itself, even if it was expensive. Garbled circuits compress that logic into an opaque blob that only makes sense during a specific off-chain ceremony between specific parties, which is exactly why critics point to setup honesty as a new assumption. Babylon chose cost first.

Babylon is not optimizing for cryptographic purity here, it optimized for cost. Unable to keep verification both cheap and fully legible on Bitcoin, the team turned a $16,000 problem into a roughly $9 one and accepted a new class of off-chain trust in exchange. That is a deliberate trade-off, not an oversight.

@BabylonLabs_io $BANK $BTW $BABY #baby
翻訳参照
Ask anyone who has watched a DeFi position get margin called what a liquidation looks like and you will hear the same story: a price feed ticks past a threshold, a bot notices before you do, and your collateral gets seized in the time it takes to refresh a browser tab. It is reasonable to assume Bitcoin collateral through Babylon's vaults would work the identical way once it lands on a lending market. It does not, at least not by that mechanism. A Babylon vault only releases locked BTC to a liquidator when that liquidator submits a valid zero knowledge proof confirming the loan terms were actually broken, not when an oracle price crosses a line on a dashboard. The proof has to verify against the smart contract state before Bitcoin script will let funds move, and Babylon's design layers in a challenge period so a contested claim can be disputed before it settles for good. The assumption that liquidation always means an automated price race misses what actually gates the outcome here. Price movement can still trigger eligibility on the lending market's side, but the Bitcoin side will not hand collateral to anyone who cannot produce cryptographic proof the breach genuinely happened, and a contested claim gets a window to be challenged rather than settling instantly, a slower and more dispute resistant process than the bot races most DeFi users expect. Babylon's vaults don't liquidate the way most DeFi collateral does, racing a price oracle the instant a threshold breaks. They gate every seizure behind a verified proof and a challenge window, trading the speed of an automated bot for a process that a false claim cannot simply outrun. @babylonlabs_io $AKE $BABY #baby {spot}(BABYUSDT)
Ask anyone who has watched a DeFi position get margin called what a liquidation looks like and you will hear the same story: a price feed ticks past a threshold, a bot notices before you do, and your collateral gets seized in the time it takes to refresh a browser tab. It is reasonable to assume Bitcoin collateral through Babylon's vaults would work the identical way once it lands on a lending market.

It does not, at least not by that mechanism. A Babylon vault only releases locked BTC to a liquidator when that liquidator submits a valid zero knowledge proof confirming the loan terms were actually broken, not when an oracle price crosses a line on a dashboard. The proof has to verify against the smart contract state before Bitcoin script will let funds move, and Babylon's design layers in a challenge period so a contested claim can be disputed before it settles for good.

The assumption that liquidation always means an automated price race misses what actually gates the outcome here. Price movement can still trigger eligibility on the lending market's side, but the Bitcoin side will not hand collateral to anyone who cannot produce cryptographic proof the breach genuinely happened, and a contested claim gets a window to be challenged rather than settling instantly, a slower and more dispute resistant process than the bot races most DeFi users expect.

Babylon's vaults don't liquidate the way most DeFi collateral does, racing a price oracle the instant a threshold breaks. They gate every seizure behind a verified proof and a challenge window, trading the speed of an automated bot for a process that a false claim cannot simply outrun.

@BabylonLabs_io $AKE $BABY #baby
@babylonlabs_io $BANK $DEXE $BABY #baby あるいとこがいて、いつも「兄」のほうと間違えられる。歩き方も、遠目の笑い方も同じだ。けれど間近で見るとまったく似ていない。片方はヴィンテージの腕時計を集める。もう片方は時間を確認することすら面倒がっている。クリプトのTwitterも、ビットコインのブリッジで同じことをやっている。 プロジェクトが「ビットコインを別のチェーンに接続する」と言うたびに、反射的にそれをブリッジと呼んでしまう。そしてブリッジには、足のつくような実績の悪さがある。マルチシグや、ラップドトークンのカストディアが単一障害点になってしまい、大量の資金がエクスプロイトで失われた。バビロンのヴォールトも、デフォルトでそのカテゴリに分類されがちだ。 しかし、その比較は仕組みを見落としている。ビットコインのスクリプト言語には、共謀者(カヴェナンツ)がなく、将来のトランザクションで資金をどう使えるかをネイティブに制限する手段もない。だからこそ、従来型の信託不要ブリッジは、どこかにキーパー集団を置かないと作りにくかった。バビロンのヴォールトは、BTCを、ほかのラップド資産ではなく、ビットコインそのもの上にあるUTXOにロックし、事前に署名された、暗号学的に条件づけられたトランザクションによって制御することでこれを回避する。各ヴォールトは共有されたカストディのアドレスにプールするのではなく、ユーザーごとに分離される。そして、設計全体は今日のビットコインとして動作し、新しいオペコードも不要で、ソフトフォークもなく、コンセンサス変更も必要ない。 それは、マルチシグ・ブリッジのパターンとは正反対だ。攻撃者が1回のトランザクションで引き抜けるような、プールされた準備金がそもそも存在しない。資金が最初からプールされていないからだ。過去のブリッジがヘッドライン級のハックになったことで生まれたリスクの地形は、ここでは同じ形では当てはまらない。もちろん、そこに新しく別のリスクが入れ替わってくる可能性はあるが。 バビロンは新しい名前を着たブリッジではない。ほかのチェーンの状態を読み取るという性質を備えた、自動執行型のロックボックスに近い。 {spot}(BABYUSDT)
@BabylonLabs_io $BANK $DEXE $BABY #baby

あるいとこがいて、いつも「兄」のほうと間違えられる。歩き方も、遠目の笑い方も同じだ。けれど間近で見るとまったく似ていない。片方はヴィンテージの腕時計を集める。もう片方は時間を確認することすら面倒がっている。クリプトのTwitterも、ビットコインのブリッジで同じことをやっている。

プロジェクトが「ビットコインを別のチェーンに接続する」と言うたびに、反射的にそれをブリッジと呼んでしまう。そしてブリッジには、足のつくような実績の悪さがある。マルチシグや、ラップドトークンのカストディアが単一障害点になってしまい、大量の資金がエクスプロイトで失われた。バビロンのヴォールトも、デフォルトでそのカテゴリに分類されがちだ。

しかし、その比較は仕組みを見落としている。ビットコインのスクリプト言語には、共謀者(カヴェナンツ)がなく、将来のトランザクションで資金をどう使えるかをネイティブに制限する手段もない。だからこそ、従来型の信託不要ブリッジは、どこかにキーパー集団を置かないと作りにくかった。バビロンのヴォールトは、BTCを、ほかのラップド資産ではなく、ビットコインそのもの上にあるUTXOにロックし、事前に署名された、暗号学的に条件づけられたトランザクションによって制御することでこれを回避する。各ヴォールトは共有されたカストディのアドレスにプールするのではなく、ユーザーごとに分離される。そして、設計全体は今日のビットコインとして動作し、新しいオペコードも不要で、ソフトフォークもなく、コンセンサス変更も必要ない。

それは、マルチシグ・ブリッジのパターンとは正反対だ。攻撃者が1回のトランザクションで引き抜けるような、プールされた準備金がそもそも存在しない。資金が最初からプールされていないからだ。過去のブリッジがヘッドライン級のハックになったことで生まれたリスクの地形は、ここでは同じ形では当てはまらない。もちろん、そこに新しく別のリスクが入れ替わってくる可能性はあるが。

バビロンは新しい名前を着たブリッジではない。ほかのチェーンの状態を読み取るという性質を備えた、自動執行型のロックボックスに近い。
#baby @babylonlabs_io $DEXE $BANK $BABY 古いアパートの近くに共同ガーデンがあって、共有の道具小屋を置いていました。鍵はかかっておらず、早い者勝ち。輪番制の委員会が運営していて、乾燥した時期には誰が良いシャベルを手に入れられるかを決めていました。道具が共有されていないわけではありませんでした。けれど、委員会こそが実質的なゲートキーパーではない、とも誰も言えません。 計画されている100億BABYトークンのうち15%、つまり15億トークンは、Babylon Foundationが管理するコミュニティ・インセンティブ用のバケットに入っています。チーム分の15億トークンが4年のスケジュール(1年のクリフ付き)に従うのとは別に、初期投資家向けの30.5億トークンは2029年4月までのスケジュールで月ごとに1/36ずつアンロックされます。一方、コミュニティ配分は大半がすでにアンロック済みで、Foundationが望む任意のタイミングで配布できます。そのバケット内の一つのカーブアウトとして、121.6百万BABYがBinanceのマーケティングキャンペーン専用に確保されており、Babylon Genesisのメインネットローンチ(2025年4月)から6か月後にリリースされます。エコシステム構築およびR&Dの割り当ても同様で、総供給のそれぞれ18%を占めます。25%はローンチ時点で即時アンロックされ、残りは3年間にわたって直線的に配信されますが、これもFoundationの裁量のもとです。合計すると、エコシステム、R&D、コミュニティの各カテゴリーは、10億トークン全体の51%に達し、固定された公開ルールというよりは、何らかのFoundation主導のタイミングでのリリースとして確保されていることになります。つまり最大の、まだ確定していない配分(ベスティング未完了分)は、予測可能なルールによってユーザーが請求するのではなく、取引所とのパートナーシップをめぐるタイミングといった要素も含め、Foundationの判断で出されるのです。これはコミュニティによるオーナーシップでしょうか、それともコミュニティというラベルをまとった、Foundation主導の支出でしょうか? どちらの読みも、ある程度は真実を含んでいます。トークンは時間とともにユーザーやビルダーへ届きます。しかし、そのペースと行き先は中央で決められたままで、より明確な継続的なリリース基準がない限り、これを純粋なコミュニティによる所有だと断言するのは誇張です。 {spot}(BABYUSDT)
#baby @BabylonLabs_io $DEXE $BANK $BABY

古いアパートの近くに共同ガーデンがあって、共有の道具小屋を置いていました。鍵はかかっておらず、早い者勝ち。輪番制の委員会が運営していて、乾燥した時期には誰が良いシャベルを手に入れられるかを決めていました。道具が共有されていないわけではありませんでした。けれど、委員会こそが実質的なゲートキーパーではない、とも誰も言えません。

計画されている100億BABYトークンのうち15%、つまり15億トークンは、Babylon Foundationが管理するコミュニティ・インセンティブ用のバケットに入っています。チーム分の15億トークンが4年のスケジュール(1年のクリフ付き)に従うのとは別に、初期投資家向けの30.5億トークンは2029年4月までのスケジュールで月ごとに1/36ずつアンロックされます。一方、コミュニティ配分は大半がすでにアンロック済みで、Foundationが望む任意のタイミングで配布できます。そのバケット内の一つのカーブアウトとして、121.6百万BABYがBinanceのマーケティングキャンペーン専用に確保されており、Babylon Genesisのメインネットローンチ(2025年4月)から6か月後にリリースされます。エコシステム構築およびR&Dの割り当ても同様で、総供給のそれぞれ18%を占めます。25%はローンチ時点で即時アンロックされ、残りは3年間にわたって直線的に配信されますが、これもFoundationの裁量のもとです。合計すると、エコシステム、R&D、コミュニティの各カテゴリーは、10億トークン全体の51%に達し、固定された公開ルールというよりは、何らかのFoundation主導のタイミングでのリリースとして確保されていることになります。つまり最大の、まだ確定していない配分(ベスティング未完了分)は、予測可能なルールによってユーザーが請求するのではなく、取引所とのパートナーシップをめぐるタイミングといった要素も含め、Foundationの判断で出されるのです。これはコミュニティによるオーナーシップでしょうか、それともコミュニティというラベルをまとった、Foundation主導の支出でしょうか?

どちらの読みも、ある程度は真実を含んでいます。トークンは時間とともにユーザーやビルダーへ届きます。しかし、そのペースと行き先は中央で決められたままで、より明確な継続的なリリース基準がない限り、これを純粋なコミュニティによる所有だと断言するのは誇張です。
翻訳参照
The scale at my farmers market has a short lag before it locks a weight. My uncle, selling rare heirloom tomatoes, calibrated his scale to lag longer than the corn stand next door. Rare items attract more price gaming, he said, so he wanted an extra beat before the number settled. GRVT's matching engine runs the same logic at the order book level. Major pairs get a 25 millisecond speedbump before an order can execute, while altcoins get a 50 millisecond speedbump, double the delay, specifically to reduce toxic flow, the kind of ultra fast quote sniping that punishes resting orders on thinner books. Majors carry enough depth to absorb fast-moving flow without much damage, altcoins do not, so the engine slows things down more where the risk of getting picked off is higher. The market maker program applies a similar asymmetry to onboarding rather than execution. A market maker already active on another exchange who migrates to GRVT receives an automatic Bronze tier for fourteen days, with rebate benefits adjusted from there, instead of starting from a zero-volume baseline like a brand new participant would. That removes the cold-start penalty specifically for liquidity GRVT wants to attract quickly. On the fee side, every special tier above Level 9 converges to the same taker fee, so the ladder rewards climbing volume only up to a point and then flattens rather than scaling forever. None of these three mechanics are uniform rules applied everywhere, each one is calibrated to a specific risk or a specific type of participant. GRVT does not apply one uniform speed or one uniform onboarding rule across every market and every trader, it tunes matching delay and rebate treatment by pair-level risk and by whether liquidity is new or migrating. @grvt_io #grvt $LAB $VELVET
The scale at my farmers market has a short lag before it locks a weight. My uncle, selling rare heirloom tomatoes, calibrated his scale to lag longer than the corn stand next door. Rare items attract more price gaming, he said, so he wanted an extra beat before the number settled.

GRVT's matching engine runs the same logic at the order book level. Major pairs get a 25 millisecond speedbump before an order can execute, while altcoins get a 50 millisecond speedbump, double the delay, specifically to reduce toxic flow, the kind of ultra fast quote sniping that punishes resting orders on thinner books. Majors carry enough depth to absorb fast-moving flow without much damage, altcoins do not, so the engine slows things down more where the risk of getting picked off is higher. The market maker program applies a similar asymmetry to onboarding rather than execution. A market maker already active on another exchange who migrates to GRVT receives an automatic Bronze tier for fourteen days, with rebate benefits adjusted from there, instead of starting from a zero-volume baseline like a brand new participant would. That removes the cold-start penalty specifically for liquidity GRVT wants to attract quickly. On the fee side, every special tier above Level 9 converges to the same taker fee, so the ladder rewards climbing volume only up to a point and then flattens rather than scaling forever. None of these three mechanics are uniform rules applied everywhere, each one is calibrated to a specific risk or a specific type of participant.

GRVT does not apply one uniform speed or one uniform onboarding rule across every market and every trader, it tunes matching delay and rebate treatment by pair-level risk and by whether liquidity is new or migrating.

@grvt_io #grvt $LAB $VELVET
記事
翻訳参照
Where Newton's Slashed Funds Actually GoA landlord I rented from years ago had a security deposit policy that seemed unusual at the time. If a tenant damaged something, the deposit didn't just vanish into his general account, it went specifically toward fixing whatever that tenant broke, and if there was money left over it came back. Most landlords I'd dealt with before just kept the whole deposit regardless of the actual damage, treating it as a flat penalty rather than a repair fund. The difference sounds small until you're the tenant who caused twenty dollars of damage and would have lost a full month's deposit under the old system. Where a penalty goes changes what the penalty is actually for. That same design question, where does the punishment money actually go, is worth asking about Newton's slashing mechanism instead of assuming it's a solved, boring detail. When an agent operator misbehaves badly enough to trigger slashing, or a validator acts maliciously in a way that gets caught, the collateral they staked doesn't just get burned into the void or absorbed as generic protocol revenue. It gets redistributed specifically to the users affected by that misbehavior. That single design choice, redirect rather than burn, quietly reframes what slashing is for. A lot of proof-of-stake systems treat slashing purely as a deterrent, burn the offender's stake, reduce total supply slightly, send a message to everyone watching that bad behavior costs money. That works fine as a deterrent mechanism, but it does nothing for the specific person who actually lost money because of the misbehavior in the first place. Newton's redistribution model treats slashing as something closer to a compensation fund automatically triggered by the misconduct that caused the harm, rather than an abstract punishment disconnected from who actually got hurt. Walking through the mechanics helps make this concrete. First, there are two distinct staking roles that can face slashing, validators who secure the Keystore rollup and verify agent execution, and agent operators who stake NEWT as collateral specifically to run agent models for users. Second, operators earn fees from users for running those models, meaning the collateral they put up is functioning as a performance bond tied directly to the service they're being paid for, not a separate, disconnected requirement. Third, the redistribution mechanism requires the protocol to actually identify which users were harmed by a specific instance of misbehavior, which is a nontrivial technical and procedural problem, not just a wallet transfer, since it has to trace the misbehavior back to its actual victims rather than distributing funds arbitrarily. Fourth, this compensation only covers the collateral actually staked by the offending party, which means the redistribution is capped by how much that specific operator or validator had at risk, not by the full scope of damage a bad actor could theoretically cause if their position size exceeded their stake. Fifth, the entire mechanism depends on the TEE attestation and zero-knowledge proof systems working correctly to detect misbehavior in the first place, since slashing can only redistribute funds for violations the protocol can actually prove happened. That last point is where the design gets genuinely interesting rather than just feel-good. A compensation mechanism is only as good as the detection system feeding it. If TEE attestation or zk verification misses a violation, or takes too long to catch one relative to how fast damage compounds, the redistribution promise doesn't help the user who already lost money before detection caught up. The 14-day unstaking cooldown discussed elsewhere in Newton's design exists partly to give this detection process room to work before an offending party's stake can walk out the door. Slashing redistribution and the unbonding period are not separate features, they're two parts of the same compensation pipeline, one guarantees the money stays put long enough to be clawed back, the other decides where it goes once it is. The honest limitation is that this system compensates after the fact, it doesn't prevent the initial loss from happening, and the size of that compensation is bounded by collateral size, not by actual damages, which means a large enough violation from an undercollateralized operator could still leave affected users only partially made whole even when the mechanism works exactly as designed. Newton isn't treating slashed collateral as a punishment that disappears into the protocol's coffers, it built a compensation pathway that traces harm back to the people who experienced it. That's a meaningfully different design decision than the burn-and-deter model most staking systems default to, closer in spirit to my old landlord's damage-specific deposit than a flat penalty, even if that compensation still has real limits worth knowing about before assuming it covers every possible loss a user could face. @NewtonProtocol $NEWT #Newt $LAB $VELVET {spot}(NEWTUSDT)

Where Newton's Slashed Funds Actually Go

A landlord I rented from years ago had a security deposit policy that seemed unusual at the time. If a tenant damaged something, the deposit didn't just vanish into his general account, it went specifically toward fixing whatever that tenant broke, and if there was money left over it came back. Most landlords I'd dealt with before just kept the whole deposit regardless of the actual damage, treating it as a flat penalty rather than a repair fund. The difference sounds small until you're the tenant who caused twenty dollars of damage and would have lost a full month's deposit under the old system. Where a penalty goes changes what the penalty is actually for.
That same design question, where does the punishment money actually go, is worth asking about Newton's slashing mechanism instead of assuming it's a solved, boring detail. When an agent operator misbehaves badly enough to trigger slashing, or a validator acts maliciously in a way that gets caught, the collateral they staked doesn't just get burned into the void or absorbed as generic protocol revenue. It gets redistributed specifically to the users affected by that misbehavior. That single design choice, redirect rather than burn, quietly reframes what slashing is for.
A lot of proof-of-stake systems treat slashing purely as a deterrent, burn the offender's stake, reduce total supply slightly, send a message to everyone watching that bad behavior costs money. That works fine as a deterrent mechanism, but it does nothing for the specific person who actually lost money because of the misbehavior in the first place. Newton's redistribution model treats slashing as something closer to a compensation fund automatically triggered by the misconduct that caused the harm, rather than an abstract punishment disconnected from who actually got hurt.
Walking through the mechanics helps make this concrete. First, there are two distinct staking roles that can face slashing, validators who secure the Keystore rollup and verify agent execution, and agent operators who stake NEWT as collateral specifically to run agent models for users. Second, operators earn fees from users for running those models, meaning the collateral they put up is functioning as a performance bond tied directly to the service they're being paid for, not a separate, disconnected requirement. Third, the redistribution mechanism requires the protocol to actually identify which users were harmed by a specific instance of misbehavior, which is a nontrivial technical and procedural problem, not just a wallet transfer, since it has to trace the misbehavior back to its actual victims rather than distributing funds arbitrarily. Fourth, this compensation only covers the collateral actually staked by the offending party, which means the redistribution is capped by how much that specific operator or validator had at risk, not by the full scope of damage a bad actor could theoretically cause if their position size exceeded their stake. Fifth, the entire mechanism depends on the TEE attestation and zero-knowledge proof systems working correctly to detect misbehavior in the first place, since slashing can only redistribute funds for violations the protocol can actually prove happened.
That last point is where the design gets genuinely interesting rather than just feel-good. A compensation mechanism is only as good as the detection system feeding it. If TEE attestation or zk verification misses a violation, or takes too long to catch one relative to how fast damage compounds, the redistribution promise doesn't help the user who already lost money before detection caught up. The 14-day unstaking cooldown discussed elsewhere in Newton's design exists partly to give this detection process room to work before an offending party's stake can walk out the door. Slashing redistribution and the unbonding period are not separate features, they're two parts of the same compensation pipeline, one guarantees the money stays put long enough to be clawed back, the other decides where it goes once it is.
The honest limitation is that this system compensates after the fact, it doesn't prevent the initial loss from happening, and the size of that compensation is bounded by collateral size, not by actual damages, which means a large enough violation from an undercollateralized operator could still leave affected users only partially made whole even when the mechanism works exactly as designed.
Newton isn't treating slashed collateral as a punishment that disappears into the protocol's coffers, it built a compensation pathway that traces harm back to the people who experienced it. That's a meaningfully different design decision than the burn-and-deter model most staking systems default to, closer in spirit to my old landlord's damage-specific deposit than a flat penalty, even if that compensation still has real limits worth knowing about before assuming it covers every possible loss a user could face.
@NewtonProtocol $NEWT #Newt $LAB $VELVET
翻訳参照
My landlord once gave me a spare key that only opened the mailbox, nothing else in the building. I remember thinking it was overkill for a mailbox. Years later I understood the point: he wasn't handing out trust, he was handing out exactly the amount of access a task required and nothing more. That is the same logic sitting inside Newton's Keystore rollup. Instead of giving an AI agent your wallet's full signing power, the Keystore lets you scope permissions down to specific, narrow rights, spend up to this limit, trade only this pair, act only inside this time window. Those scopes live onchain and get enforced cryptographically, not through a promise the agent operator makes and might break. The rollup also handles cross-chain state transitions, so a permission granted on one chain stays consistent as the agent's actions ripple across others. The tradeoff is real. Fine-grained scoping means more setup, more decisions a user has to make before an agent can even start working, spend limits, time windows, asset lists, revocation rules. A simpler system would just ask for a blanket approval and move faster to the fun part. Newton chose the slower onboarding path on purpose, betting that people delegating financial control to autonomous software actually want the mailbox key, not the master key, even if configuring that scope takes a few extra minutes up front. Session keys built on top of the same scoping logic let a user revoke or update a permission mid-flight without touching the rest of the wallet, which matters once you have more than one agent running at the same time. Newton isn't optimizing for the fastest possible agent setup, it is optimizing for the smallest possible blast radius when something goes wrong, and that says more about who the protocol is built for than any feature list does. @NewtonProtocol $NEWT #Newt $LAB $VELVET {spot}(NEWTUSDT)
My landlord once gave me a spare key that only opened the mailbox, nothing else in the building. I remember thinking it was overkill for a mailbox. Years later I understood the point: he wasn't handing out trust, he was handing out exactly the amount of access a task required and nothing more.

That is the same logic sitting inside Newton's Keystore rollup. Instead of giving an AI agent your wallet's full signing power, the Keystore lets you scope permissions down to specific, narrow rights, spend up to this limit, trade only this pair, act only inside this time window. Those scopes live onchain and get enforced cryptographically, not through a promise the agent operator makes and might break. The rollup also handles cross-chain state transitions, so a permission granted on one chain stays consistent as the agent's actions ripple across others.

The tradeoff is real. Fine-grained scoping means more setup, more decisions a user has to make before an agent can even start working, spend limits, time windows, asset lists, revocation rules. A simpler system would just ask for a blanket approval and move faster to the fun part. Newton chose the slower onboarding path on purpose, betting that people delegating financial control to autonomous software actually want the mailbox key, not the master key, even if configuring that scope takes a few extra minutes up front. Session keys built on top of the same scoping logic let a user revoke or update a permission mid-flight without touching the rest of the wallet, which matters once you have more than one agent running at the same time.

Newton isn't optimizing for the fastest possible agent setup, it is optimizing for the smallest possible blast radius when something goes wrong, and that says more about who the protocol is built for than any feature list does.

@NewtonProtocol $NEWT #Newt $LAB $VELVET
記事
翻訳参照
The Receipt Gap Between Newton and "AI Agents Onchain"A friend of mine hired a freelance bookkeeper years ago who insisted she did not need to send receipts, she would just tell him at the end of each month what she had spent and categorized. He trusted her for almost a year before an audit forced him to actually verify her numbers against bank statements, and the two did not match in several places, nothing criminal, just sloppy self-reporting that nobody had ever independently checked. What struck him afterward was not that she had lied exactly, it was that the entire arrangement had rested on trusting her own account of her own work, with no independent record standing between her claim and his belief in it. That same structural gap sits underneath a lot of projects currently using "AI agents onchain" as a headline phrase, and it is worth pulling apart carefully rather than treating the phrase as one undifferentiated category. Fetch.ai's autonomous economic agents are built to act independently, negotiating and executing tasks on a user's behalf across its network. The system relies substantially on an agent's own reporting of what it did, with no built-in proof tying the agent's offchain reasoning process to the specific onchain execution that followed from it. Sahara AI markets similar language around autonomous agents participating in a decentralized AI economy, again without a standard mechanism proving that a given onchain action actually matched the reasoning or authorization behind it, rather than simply being reported as having done so. Newton's approach targets that exact gap, though only for a narrower slice of what "agent behavior" can mean. Its transaction-layer attestations back every allow, reject, or cap decision with a signed record tied to the specific policy check that ran, verifiable by anyone without requiring them to trust the agent's own account of what it did. Newton's AI agent policies specifically enforce mandate scope and spending caps at the moment a transaction is attempted, meaning an agent acting outside its authorized job gets blocked structurally, not because it chose to self-report accurately. That is a real, checkable difference from a system that simply asks an agent to log its own actions honestly and hopes the log matches reality. The honest caveat is that this closes a narrower gap than the phrase "verifiable AI agents" implies when read quickly. Newton's attestation proves a transaction stayed within its authorized mandate and spending limits at the moment it settled, it does not prove the agent's underlying reasoning was sound, was not manipulated upstream by a prompt injection before the transaction was even attempted, or that the model producing the decision was working correctly in any deeper sense. Fetch.ai's agents can do things Newton's current attestation model was never built to verify either, complex multi-step negotiations, service discovery, and coordination across a broader agent marketplace than Newton's narrower transaction-authorization scope currently covers. Comparing the two directly risks implying they compete head to head on the same feature set, when in practice they are solving overlapping but genuinely different slices of the same broad "AI agents onchain" narrative. So does Newton actually close the receipt gap that projects like Fetch.ai and Sahara AI structurally leave open. Partly, and specifically for the piece of agent behavior it was built to police, whether a transaction stayed inside its authorized bounds. It does not close the upstream half of the problem, whether the agent's reasoning itself was sound before that transaction was ever attempted, a harder and largely unsolved question sitting one layer further back in the pipeline. The bookkeeper's receipts would have caught a miscategorized expense, they would not have caught a decision to spend money on the wrong thing entirely if she was authorized to make that call in the first place. Newton's attestations play a similar role, a real and useful check on one specific failure mode, not a complete answer to the much larger question of whether an autonomous agent should be trusted at all. @NewtonProtocol #Newt $NEWT $LAB $EVAA {spot}(NEWTUSDT)

The Receipt Gap Between Newton and "AI Agents Onchain"

A friend of mine hired a freelance bookkeeper years ago who insisted she did not need to send receipts, she would just tell him at the end of each month what she had spent and categorized. He trusted her for almost a year before an audit forced him to actually verify her numbers against bank statements, and the two did not match in several places, nothing criminal, just sloppy self-reporting that nobody had ever independently checked. What struck him afterward was not that she had lied exactly, it was that the entire arrangement had rested on trusting her own account of her own work, with no independent record standing between her claim and his belief in it.
That same structural gap sits underneath a lot of projects currently using "AI agents onchain" as a headline phrase, and it is worth pulling apart carefully rather than treating the phrase as one undifferentiated category. Fetch.ai's autonomous economic agents are built to act independently, negotiating and executing tasks on a user's behalf across its network. The system relies substantially on an agent's own reporting of what it did, with no built-in proof tying the agent's offchain reasoning process to the specific onchain execution that followed from it. Sahara AI markets similar language around autonomous agents participating in a decentralized AI economy, again without a standard mechanism proving that a given onchain action actually matched the reasoning or authorization behind it, rather than simply being reported as having done so.
Newton's approach targets that exact gap, though only for a narrower slice of what "agent behavior" can mean. Its transaction-layer attestations back every allow, reject, or cap decision with a signed record tied to the specific policy check that ran, verifiable by anyone without requiring them to trust the agent's own account of what it did. Newton's AI agent policies specifically enforce mandate scope and spending caps at the moment a transaction is attempted, meaning an agent acting outside its authorized job gets blocked structurally, not because it chose to self-report accurately. That is a real, checkable difference from a system that simply asks an agent to log its own actions honestly and hopes the log matches reality.
The honest caveat is that this closes a narrower gap than the phrase "verifiable AI agents" implies when read quickly. Newton's attestation proves a transaction stayed within its authorized mandate and spending limits at the moment it settled, it does not prove the agent's underlying reasoning was sound, was not manipulated upstream by a prompt injection before the transaction was even attempted, or that the model producing the decision was working correctly in any deeper sense. Fetch.ai's agents can do things Newton's current attestation model was never built to verify either, complex multi-step negotiations, service discovery, and coordination across a broader agent marketplace than Newton's narrower transaction-authorization scope currently covers. Comparing the two directly risks implying they compete head to head on the same feature set, when in practice they are solving overlapping but genuinely different slices of the same broad "AI agents onchain" narrative.
So does Newton actually close the receipt gap that projects like Fetch.ai and Sahara AI structurally leave open. Partly, and specifically for the piece of agent behavior it was built to police, whether a transaction stayed inside its authorized bounds. It does not close the upstream half of the problem, whether the agent's reasoning itself was sound before that transaction was ever attempted, a harder and largely unsolved question sitting one layer further back in the pipeline. The bookkeeper's receipts would have caught a miscategorized expense, they would not have caught a decision to spend money on the wrong thing entirely if she was authorized to make that call in the first place. Newton's attestations play a similar role, a real and useful check on one specific failure mode, not a complete answer to the much larger question of whether an autonomous agent should be trusted at all.
@NewtonProtocol #Newt $NEWT $LAB $EVAA
翻訳参照
A neighbor of mine drives for a delivery app and swears the whole job is just proving you showed up on time. I asked him once whether anyone checks that he delivered the right order to the right door, and he laughed and said nobody really does, the system only cares that the app says delivered. That distinction between proving something happened and proving it happened correctly stuck with me longer than the conversation did. Keeper networks like Gelato, Keep3r, and Chainlink Automation exist to trigger a predefined action once a condition is met, rebalance a pool, liquidate a position, execute a limit order, and they are genuinely good at that job. What none of them do is prove the underlying decision behind the trigger was itself correct, they confirm the function ran, not that running it was the right call given everything else happening onchain at that moment. Newton's operator network backs every allow, reject, or cap decision with a verifiable proof instead, which is a different question entirely from whether an action fired on schedule. Keep3r's whole pitch has always been paying keepers for gas-efficient, reliable execution, speed and cost are the metrics that matter there, not judgment. Newton's operator network, by contrast, has to reach quorum and produce a proof before a verdict even counts, which is slower by design and priced accordingly. So do these compete? Only partly. A vault could use a keeper network to execute a rebalance and use Newton to decide whether that rebalance should be allowed to happen at all, and neither one replaces the other's job. Whether that distinction actually matters to a builder choosing infrastructure today, or only matters once something goes wrong and someone asks why a technically-successful transaction was still the wrong one, is a question Newton's real world usage has not fully answered yet. I lean toward thinking it matters more the moment real money is on the line, but that is a guess, not a settled fact. @NewtonProtocol $NEWT #Newt $LAB $EVAA {spot}(NEWTUSDT)
A neighbor of mine drives for a delivery app and swears the whole job is just proving you showed up on time. I asked him once whether anyone checks that he delivered the right order to the right door, and he laughed and said nobody really does, the system only cares that the app says delivered. That distinction between proving something happened and proving it happened correctly stuck with me longer than the conversation did.

Keeper networks like Gelato, Keep3r, and Chainlink Automation exist to trigger a predefined action once a condition is met, rebalance a pool, liquidate a position, execute a limit order, and they are genuinely good at that job. What none of them do is prove the underlying decision behind the trigger was itself correct, they confirm the function ran, not that running it was the right call given everything else happening onchain at that moment. Newton's operator network backs every allow, reject, or cap decision with a verifiable proof instead, which is a different question entirely from whether an action fired on schedule.

Keep3r's whole pitch has always been paying keepers for gas-efficient, reliable execution, speed and cost are the metrics that matter there, not judgment. Newton's operator network, by contrast, has to reach quorum and produce a proof before a verdict even counts, which is slower by design and priced accordingly.

So do these compete? Only partly. A vault could use a keeper network to execute a rebalance and use Newton to decide whether that rebalance should be allowed to happen at all, and neither one replaces the other's job. Whether that distinction actually matters to a builder choosing infrastructure today, or only matters once something goes wrong and someone asks why a technically-successful transaction was still the wrong one, is a question Newton's real world usage has not fully answered yet. I lean toward thinking it matters more the moment real money is on the line, but that is a guess, not a settled fact.

@NewtonProtocol $NEWT #Newt $LAB $EVAA
私の友人は、遊び半分でアプリをベータテストしています。彼女にバンキングアプリを渡すと、ログイン画面をいじって脆弱性を探そうとします。コーヒーショップの注文アプリを渡すと、たとえば小さな画面で価格ラベルにボタンが重なってしまう、といった不具合を報告してくるのです。彼女は一度、銀行のセキュリティチームにフォントの不具合を報告するのは、さすがに自分が間抜けに見えてしまう気がすると言っていました。でもそれは当然でもあります。フォントの不具合が属するべきキューは、そこではありません。 GRVTは彼女の勘に同意しているようです。1つの「何でもまとめ箱」ではなく、別々のバグバウンティのトラックを2本走らせています。メインプログラムは機密性・完全性・可用性を対象にしており、資金に関わる発見、認証、あるいはノードの稼働時間に影響するような種類のものが該当します。メインネットの発見にはテストネットより高いティアで報酬が支払われます。これとは別に、GRVTは11月と12月に、UIとUXにだけ焦点を当てた専用のモバイル・バグバウンティを実施しました。アプリのクラッシュ、反応しないボタン、わかりにくいナビゲーション、壊れたレイアウト、さらにはタイポや色の不一致といったものです。視覚的または使い勝手の問題の重大度に応じてUSDTで支払われます。このようにキューを分けることで、見た目の不具合報告が、実際に資金を動かし得る報告とトリアージ時間を奪い合わないようになります。また、セキュリティ研究者のレポートが、ずれたテキストのスクリーンショットの山に埋もれるのも防げます。さらに、GRVTが自社のモバイルアプリを「本番リリース後にWebアプリへ後付けされたおまけ」ではなく、独立したテスト対象として本気で捉えていることも示しています。 GRVTは、区別のない1つのバウンティ箱を回しているのではなく、2種類のリスクに向けた2つのプログラムを用意しています。一方は資金レベルのエクスプロイト、もう一方は日常的な使い勝手の摩擦です。この分離は小さな運用上の選択に見えますが、「誰かがどれだけ声高に報告しているか」ではなく「結果として何が起きるか」で問題を分類するチームの姿勢が見て取れます。 @grvt_io #grvt $LAB $B
私の友人は、遊び半分でアプリをベータテストしています。彼女にバンキングアプリを渡すと、ログイン画面をいじって脆弱性を探そうとします。コーヒーショップの注文アプリを渡すと、たとえば小さな画面で価格ラベルにボタンが重なってしまう、といった不具合を報告してくるのです。彼女は一度、銀行のセキュリティチームにフォントの不具合を報告するのは、さすがに自分が間抜けに見えてしまう気がすると言っていました。でもそれは当然でもあります。フォントの不具合が属するべきキューは、そこではありません。

GRVTは彼女の勘に同意しているようです。1つの「何でもまとめ箱」ではなく、別々のバグバウンティのトラックを2本走らせています。メインプログラムは機密性・完全性・可用性を対象にしており、資金に関わる発見、認証、あるいはノードの稼働時間に影響するような種類のものが該当します。メインネットの発見にはテストネットより高いティアで報酬が支払われます。これとは別に、GRVTは11月と12月に、UIとUXにだけ焦点を当てた専用のモバイル・バグバウンティを実施しました。アプリのクラッシュ、反応しないボタン、わかりにくいナビゲーション、壊れたレイアウト、さらにはタイポや色の不一致といったものです。視覚的または使い勝手の問題の重大度に応じてUSDTで支払われます。このようにキューを分けることで、見た目の不具合報告が、実際に資金を動かし得る報告とトリアージ時間を奪い合わないようになります。また、セキュリティ研究者のレポートが、ずれたテキストのスクリーンショットの山に埋もれるのも防げます。さらに、GRVTが自社のモバイルアプリを「本番リリース後にWebアプリへ後付けされたおまけ」ではなく、独立したテスト対象として本気で捉えていることも示しています。

GRVTは、区別のない1つのバウンティ箱を回しているのではなく、2種類のリスクに向けた2つのプログラムを用意しています。一方は資金レベルのエクスプロイト、もう一方は日常的な使い勝手の摩擦です。この分離は小さな運用上の選択に見えますが、「誰かがどれだけ声高に報告しているか」ではなく「結果として何が起きるか」で問題を分類するチームの姿勢が見て取れます。

@grvt_io #grvt $LAB $B
記事
なぜニュートンの完全希薄化評価額は、どこを見るかによって変わり続けるのか私は、簡単な答えがあるはずの問いに答えようとしていました。つまり、NEWTの現在の完全希薄化評価額(fully diluted valuation)はいくらなのか、ということです。完全希薄化評価額とは、価格に総供給量を掛けたものにすぎず、ニュートンは総供給量をインフレのメカニズムなしで10億トークンに上限設定しているため、分母が固定された数字になります。これは、プロジェクトにおけるより安定した指標の一つであるべきです。ところが、年のさまざまな時点で異なるトラッカーから数値を引いてくると、金額は概ね4,920万ドルから約8,330万ドルの範囲で変動していました。同じ暦年の中で、同じ固定の供給上限にもかかわらず、そうした数値が引用されることがありました。

なぜニュートンの完全希薄化評価額は、どこを見るかによって変わり続けるのか

私は、簡単な答えがあるはずの問いに答えようとしていました。つまり、NEWTの現在の完全希薄化評価額(fully diluted valuation)はいくらなのか、ということです。完全希薄化評価額とは、価格に総供給量を掛けたものにすぎず、ニュートンは総供給量をインフレのメカニズムなしで10億トークンに上限設定しているため、分母が固定された数字になります。これは、プロジェクトにおけるより安定した指標の一つであるべきです。ところが、年のさまざまな時点で異なるトラッカーから数値を引いてくると、金額は概ね4,920万ドルから約8,330万ドルの範囲で変動していました。同じ暦年の中で、同じ固定の供給上限にもかかわらず、そうした数値が引用されることがありました。
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約