SciPHR

The First decentralized Key Management System (dKMS). Making Blockchain easy and accessible to everyone. Founded by @jarodvyent

[SciPHR @sciphr_]

SciPHR has filed a provisional patent application with the United States Patent and Trademark Office.

Our patent covers a novel decentralized key management system that eliminates the need for users and enterprises to handle private keys directly. Instead, we cryptographically encrypt wallet secrets, store them within NFT metadata on the XRP Ledger, and authenticate users through their device's secure enclave, the same technology that powers Face and Touch ID.

The architecture combines three critical innovations:

NFTs serve as immutable, auditable containers for encrypted credentials.

Dual cryptographic systems ensure that encryption and authentication remain isolated.

Integration with W3C DID standards enables universal identity verification.

Every transaction generates an on-chain audit trail, and authentication happens through hardware-backed biometrics. Private keys remain encrypted at rest and are only decrypted ephemerally during signing operations. Never stored, never exposed, never lost.

This solves blockchain's fundamental paradox: ~$240 billion sits inaccessible due to lost private keys, and enterprises cannot adopt blockchain when key management remains a security and compliance liability.

SciPHR makes blockchain identity as secure as enterprise infrastructure and as simple as unlocking your phone.

Use Face ID like you always do. We'll handle the cryptography.

[SciPHR @sciphr_]

A wallet built in four tiers.

Every wallet has one secret that can move its funds. What matters is which parts can touch it. SciPHR runs each action through four tiers, and only one of them can sign.

The first tier is the security chip in your iPhone. It checks a live Face ID to gate access, but cannot hold the key that signs XRP Ledger transactions. That key lives one tier down, in the keychain, released for the instant of a signature and never leaving the device.

The third tier is the backend. It prepares an unsigned transaction and broadcasts the signed one your phone returns. It holds no key. The fourth is the public ledger, holding the account's identity, its recovery rules, and an encrypted backup that opens only on your device.

Think of a courier who carries sealed envelopes but holds no key to open them. Down the stack, the signing key sits in one place, the device in your hand.

Source: https://t.co/tsbl9jZ1aO

[SciPHR @sciphr_]

Self-custody you can check for yourself.

Plenty of services call themselves non-custodial. Usually that means a promise: the operator could move your funds but says it will not. A promise is only as strong as the breach that tests it.

We remove the ability instead of resting on that promise. Our backend prepares an unsigned transaction and broadcasts the signed one, and that is all it can do. No endpoint signs for you, and none opens your backup, because that code was never written. Disabling such a path would still leave it in the codebase, so the honest answer to "can they sign as me" would stay yes.

Think of a teller who holds no key to the vault, instead of one who holds a key and pledges restraint. There is no key to misuse, so nothing rests on the pledge.

Because the capability is absent, anyone can read the code and confirm it. Non-custody becomes a fact you can verify.

Source: https://t.co/E1NE26UhW9

[SciPHR @sciphr_]

An identity server that never holds a key.

AI agents are starting to act on blockchains, and acting means signing, which means holding a private key. We built xrpl-identity-mcp, an open-source server that lets an agent work with XRP Ledger identity without holding that key.

An MCP server is a tool an AI assistant can call. This one resolves DIDs, reads credentials, and prepares the transactions that change them, each returned unsigned. Signing happens in the user's wallet or the agent's signer, not in the server, which holds no seed and no signing path.

Before anything reaches the ledger, the server decodes the signed transaction and checks it against the intent it prepared. A signature that does not match what was asked for is caught before submission.

An agent can read and write on-chain identity while the authority to sign stays with the person. Custody and automation do not have to be the same thing.

Source: https://t.co/CdkSokRTl8

[SciPHR @sciphr_]

Key hygiene you can read off the ledger.

On a public ledger, every account's key setup is visible. Whether it still has its master key enabled, whether it assigned a separate signing key, whether it set up recovery signers, the whole configuration sits on-chain in the open.

We run a read-only crawler that reads the validated XRP Ledger and reports this posture on a public metrics page. It reads ledger state and holds no key, so the most it can do to an account is describe it.

Think of a building inspector who notes which doors are propped open while carrying no keys. Anyone can look up an account and read its posture straight from the ledger.

Because the ledger is transparent, how a network holds its keys is a measurable fact rather than a claim. A whole chain's custody posture can be surveyed without touching one key.

Source: https://t.co/foLUda8IZC

[SciPHR @sciphr_]

A wallet's on-chain list of trusted devices.

Using one self-custodial wallet across devices means copying the secret between them, and every copy is another place it can leak.

SciPHR keeps the key on each device and lists the devices instead. Every XRP Ledger account publishes an identity record, a DID document defined by the XLS-40 standard, holding a public key for each enrolled device and nothing that can spend. A new device generates its own key on the phone, and a DIDSet transaction signed by an authorized key adds it. Removing one works the same way.

Think of a directory of which badges open the door, where the badge itself never leaves your hand. The list is public, and only the account can edit it.

Because only an on-chain signature can change that list, a stolen phone or a phished Apple ID cannot add itself. An identity built from public keys lets one account span many devices with no shared secret to lose.

Source: https://t.co/E1NE26UhW9

[Brian Armstrong @brian_armstrong]

When starting a company, most people shy away from truly hard problems and go for base hits thinking it will be easier.

The opposite is true. Fewer people attempt the hard problems so there is less competition, and great people are more likely to join you on an impactful mission. Instead, start with something you feel in your bones must be possible or different in the world, even if it's not a business.

Then work backwards from there toward what steps will be required, and see how you can get your first dollar of revenue on an early step which enables the broader vision.

[SciPHR @sciphr_]

A wallet your phone generates on its own.

Most wallets arrive already made. A server or app generates the keys and passes them down, so something other than your device saw the secret when it was created.

SciPHR generates the XRP Ledger keys on your iPhone, stores them in the iOS Keychain, and releases them only behind a live Face ID. The backend receives no seed and holds no key that can sign. It prepares an unsigned transaction and broadcasts the one your device signs.

Picture a key cut inside your own house, where the locksmith mails you the blank and never sees the finished cut. If the maker never touched the working key, there is nothing on their side to steal or surrender.

A key generated on the device that keeps it makes custody something you can verify, not something you have to trust.

Source: https://t.co/tsbl9jZ1aO

[SciPHR @sciphr_]

A recovery signer that cannot act alone.

If you lose the device that holds your keys, the account still has to recover without handing anyone custody. SciPHR does this with a signer list on the XRP Ledger, a set of accounts allowed to re-key it together.

Each signer carries a weight, and the account sets a quorum, the total weight a group must reach to act. Your other devices and a recovery-code key are signers. SciPHR is one too, but its weight sits below that quorum. Its signature alone never reaches the threshold, so it can help a recovery and can never move funds on its own.

Think of a document that needs two signatures, where SciPHR only ever holds one.

A signer kept below the quorum can assist a recovery without ever being able to move funds. The rule is enforced by the ledger, not by trust in SciPHR.

Source: https://t.co/tsbl9jZ1aO

[SciPHR @sciphr_]

An NFT that carries no secret.

Every SciPHR wallet mints an NFT on the XRP Ledger to anchor its identity. The NFT carries a pointer to an encrypted backup stored off-chain, and nothing that could open it.

An XRPL NFT URI is capped at 256 bytes, too small for the backup itself. So the NFT records only a reference: a content ID and a hash. The content ID is the file's own fingerprint, so changing one byte changes the ID. Before trusting a fetched backup, your device checks it against that hash.

Think of a coat-check ticket that names which sealed trunk is yours and carries its fingerprint, while opening nothing. Anyone can read the ticket. Only your device, your iCloud, or your recovery code opens the trunk.

The ledger proves which backup belongs to your identity, and storage just holds the bytes. A public anchor can settle provenance without ever holding a secret.

Source: https://t.co/zKjonUSasG

[SciPHR @sciphr_]

A signing key you can rotate.

On most blockchains, the key that signs is the account. The address comes from that one key, so losing it loses the account, with nothing to swap in.

The XRP Ledger keeps them apart. An account has a master key tied to its address, and a separate regular key, assigned with a SetRegularKey transaction, that signs day to day. The regular key can be changed or removed, while the account and its history stay put.

SciPHR signs with the regular key on the device, released only by Face ID, and keeps the master key sealed in an encrypted backup it cannot open. Picture rekeying your front door after a copy gets out, without moving house. Expose that key and you replace it, keeping the account.

A key you can rotate makes a compromise a rotation, not a dead account.

Source: https://t.co/tsbl9jZ1aO

[SciPHR @sciphr_]

A wallet backup that is safe to publish.

Every wallet has a recovery secret, and the usual advice is to hide it. SciPHR seals that secret into an encrypted backup envelope using AES-256-GCM, a standard cipher, then pins it to public storage where anyone can find it.

It stays safe because the key that opens the envelope is never stored beside it. That opening key is wrapped three separate ways: by the phone's secure chip, by your iCloud Keychain, and by a recovery code only you hold. Any one restores the backup, and the server holds none of them.

Think of a locked box on a public shelf. The box is inert without a key, and every copy stays with you.

An encrypted backup is only as exposed as the key that opens it. With that key off the server, the backup can live anywhere.

Source: https://t.co/tsbl9jZ1aO

[SciPHR @sciphr_]

What you see is what you sign.

A signature in crypto is final. Whatever transaction a wallet signs, the network executes, and most stolen funds move through signatures their owners approved without reading. A phishing approval works because the screen shows one thing while the transaction says another.

SciPHR closes that gap on the device. Before any signature, the app independently decodes the raw transaction and displays every field that matters: destination, amount, fee, network. The signing key is released only after a live Face ID, and only over the exact bytes shown.

The backend never holds a key, so the worst a compromised server can do is propose a transaction. The device decodes it, shows it in full, and can refuse.

A signature should be an informed decision, and the only place to guarantee that is the device the user already holds.

Source: https://t.co/tsbl9jZ1aO

[SciPHR @sciphr_]

A phishing token approval on Ethereum.

On July 9, Scam Sniffer flagged an Ethereum wallet emptied of 999,999 USDT. The owner signed one message on a phishing site, giving up no password or seed phrase.

The message was a token approval. Spending a token such as USDT takes two steps: You approve a contract to move up to a set amount, then it transfers within that limit. The allowance can be set to unlimited. The phishing page disguised a malicious approval as a harmless click, and the signature gave the attacker's contract standing permission over the balance.

After that the attacker needed no key. A script tried to pull a round million, missed by about $631, then recalculated and swept the exact remainder 36 seconds later.

A token approval stands until the owner revokes it. A wallet can sit in self-custody and still be emptied by a permission signed once and forgotten.

Source: https://t.co/zjWxYg2PAF

[SciPHR @sciphr_]

Ill Bloom's weak seed generation.

On July 6, security firm Coinspect disclosed Ill Bloom, a flaw in how some wallets generated their recovery phrases. About $3.1 million was drained from 431 wallets on May 27, part of nearly $5 million moved from exposed accounts across six chains.

A recovery phrase comes from a random number chosen when a wallet is created, normally impossible to guess. The affected wallets used a weak generator that shrank the possibilities to about four billion. A few graphics cards can run through four billion in under a day.

With the range that small, an attacker can regenerate the phrase without ever seeing it. The wallet worked and the cryptography held. What failed was the randomness at the moment of creation.

A seed phrase is only as strong as the randomness behind it. Seeds generated on a hardware wallet's dedicated chip were not affected. The exposed ones trace to older, lesser-known mobile apps.

Source: https://t.co/MAqMD6s1Cx

[SciPHR @sciphr_]

BonkDAO's governance attack on Solana.

On July 6, an attacker moved about $20 million in BONK tokens out of the BonkDAO treasury by passing a proposal the treasury was built to obey.

BonkDAO's treasury spends on the authority of a token vote, not a signing key. Voting power is the token itself, so anyone who buys enough supply can approve a transfer. The attacker bought roughly $4 million of BONK on exchanges over several days, crossed the quorum alone, and voted through a transfer of 4.426 trillion tokens to a wallet they controlled. Seven addresses voted in total.

Every signature was valid. The contract executed a proposal that passed under the rules written for it.

A treasury governed by token votes treats a majority of the votes cast as the key. When turnout is low and the supply is liquid, that key can be bought on the open market.

Source: https://t.co/QmYAqYOelY

[SciPHR @sciphr_]

[email protected] is live on the npm registry!

[jarodvyent @jarodvyent]

I'm releasing the first identity-focused MCP server for the XRP Ledger, and, of course, it's open source!

It covers DIDs (XLS-40), credentials (XLS-70), multisig signer lists, and prepare, verify, and submit transaction workflows.

The server never takes custody of keys. It simply prepares unsigned transactions, reads ledger state, and verifies signed blobs against expected intent before anything is submitted. Signing happens in the user's wallet or agent, and mainnet submission is blocked by default unless explicitly enabled.

DIDs went live on mainnet in October 2024. Credentials followed in September 2025, and this February, permissioned domains were activated as well.

We're in 2026, and tooling for developers and agents to actually use them is still catching up.

Please check it out and let me know what you think.

https://t.co/jMZzzSAgfG

[SciPHR @sciphr_]

Fake OUSD issuer on the XRP Ledger.

On July 2, XRP Ledger validators flagged a fake issuer account using the Open Standard name, days after the Ripple-backed stablecoin OUSD launched on June 30.

On the XRP Ledger, a token is defined by its currency code and the address that issued it. Two accounts can issue tokens with the same code, so the issuing address is what tells them apart. To hold one, an account opens a trust line to a chosen issuer, and trusting the wrong address means holding a look-alike the project never minted.

The ledger did what it was told. What was missing is proof the address belongs to the project, a two-way check where the issuer names its official site and that site publishes the same address.

On a ledger where anyone can issue a token under any name, a stablecoin is only as safe as its issuing address.

Source: https://t.co/iYwhqcPI48

[SciPHR @sciphr_]

https://t.co/Ch4wTgJ1vd's flash-loan vault exploit.

Today, an attacker drained about $6 million from https://t.co/Ch4wTgJ1vd, the front end for Lazy Summer Protocol, a system that spreads deposits across DeFi lenders like Aave and Morpho to earn yield.

The vault issues shares that track each depositor's stake. A share is worth the vault's total assets divided by the shares outstanding, so its price rests on one number, what the vault believes it holds. The attacker took a flash loan of about $65 million, borrowed and repaid inside one transaction, and used it to distort the pools the vault routes through. Its accounting briefly read the vault's holdings as far larger than they were, and the displayed yield spiked past two million percent.

With the share price inflated, the attacker redeemed for more than was deposited and kept the difference. The contracts ran as written. What failed was the function pricing the shares, which trusted a total it read during a manipulated instant.

Source: https://t.co/LYBDx2FhDV

[SciPHR @sciphr_]

Aptos's Move type-confusion flaw.

On July 4, Hexens disclosed a flaw in Aptos, a layer-1 blockchain, that it estimates could have put $70 billion across bridges and stablecoins at risk. The bug was reported privately in February and patched before funds moved.

Aptos runs on Move, a language that stores permissions as on-chain objects. The right to mint a stablecoin or control a bridge lives on the ledger as one such object, and Move's type system guarantees one kind cannot be read as another. The flaw let attacker code get the network to read one object as another type, and write to storage it should never reach.

Picture a building where each key is stamped with the one door it opens. This let a holder restamp their key as the master. The cryptography was intact. What failed was the check deciding what each object was allowed to be.

Permissions stored on-chain are only as safe as the rules holding their types honest.

Source: https://t.co/8kSegQgWCc

[SciPHR @sciphr_]

Edel Finance's tokenized stock exploit.

On July 1, an attacker drained about $403,000 from Edel Finance, a platform for trading tokenized stocks, by inflating collateral to 78 times its real value.

The collateral was wGOOGLx, a wrapped version of a tokenized Google share. A wrapped token is an asset repackaged to work inside one protocol, meant to track the original one for one. The attacker manipulated the exchange rate between the wrapped token and the share, so wGOOGLx counted as far more collateral than it held, then borrowed real assets against it.

The price feed was accurate. Chainlink oracles, the standard service that reports real-world prices on-chain, showed Google near $357 the whole time. The break was in the wrapping step that turns the share into collateral, one layer below the price the protocol trusted.

Tokenized stocks add that layer between an asset and its price. Each wrapping step is another place a value can be forged, even when the underlying quote is right.

Source: https://t.co/IM0cFA4ywn