See beyond the obvious.
Reverseco is a proposed open-source tool that shows what a Robinhood Chain transaction will do to your wallet, in plain language, before you sign it.
Status: concept stage. This website and the project definition are the only things that exist today. There is no live product, no deployed contract, and no token.
Signing a transaction means trusting what you cannot read.
The concept, in five questions.
Illustration with sample values, not market data. Reverseco starts from the latest result and walks back to the call that caused it.
What is Reverseco?
A wallet-side preview tool. Given a pending transaction, it works backward from the result (which balances change, which permissions are granted) to the call that causes it, and states that result first.
What problem does it address?
Wallet prompts mostly show raw calldata, a contract address, and a gas estimate. Users approve what they cannot interpret, and unlimited token approvals and look-alike contracts exploit exactly that.
Why is the current approach insufficient?
Existing prompts describe the call, not its consequence. Simulation exists in some wallets, but it is closed, inconsistent between vendors, and rarely explains approvals that remain active after the transaction.
How does Reverseco propose to improve it?
By simulating the transaction against current chain state, decoding it against verified contract sources, and publishing the method and the code openly so the output can be checked by anyone.
Who benefits?
Everyday self-custody users who sign without reading, and wallet and dapp teams who want a reviewable preview layer instead of building their own.
Four proposed capabilities. None are live.
Initial target: Robinhood Chain, an Arbitrum-based layer 2 that settles to Ethereum, then other EVM networks. Every statement below describes a design, not shipped software.
Outcome-first preview
Planned- What
- Lists balance changes, approvals granted, and the counterparty before signing.
- How
- Forks current chain state, runs the transaction in a local EVM, and diffs balances and storage.
- Why
- The outcome is what a user actually consents to.
Approval ledger
Planned- What
- Shows every active token approval for an address and prepares a revoke transaction.
- How
- Reads approval events and current allowances from an RPC node; the user signs the revoke in their own wallet.
- Why
- Old approvals are a standing risk that most users never see.
Provenance trace
Planned- What
- Traces where an asset in an address came from, hop by hop.
- How
- Walks transfer logs backward from the current holder, with a stated depth limit.
- Why
- Lets a user check a counterparty or a token before interacting.
Open specification
In development- What
- A written spec for the preview format and the decoding rules.
- How
- Drafted in public documents so wallets can implement it independently.
- Why
- A checkable standard is more credible than a closed score.
What a preview would look like.
Illustrative mockup with sample values. It is not connected to any chain and runs no simulation. Use the switch to see how limiting an approval changes the result.
How a preview would work.
Proposed flow. Not implemented.
- ReceiveA wallet or dapp passes the pending transaction to Reverseco. No keys are shared.
- SimulateThe transaction runs against a fork of current chain state.
- ExplainResults are decoded using verified sources and shown outcome first.
- DecideThe user signs or rejects in their own wallet. Reverseco never signs.
Roadmap. Every milestone is planned unless marked.
Concept and architecture
- Project definition and brand identity: done.
- Landing website: done (this page).
- Preview format specification: in progress.
Initial product development
- Planned: simulation engine on Robinhood Chain mainnet.
- Planned: transaction decoder using verified contract sources.
- Planned: approval ledger, read-only first.
Testing and validation
- Planned: test against a public set of known malicious and benign transactions.
- Planned: independent security review before any release.
- Planned: published accuracy and false-negative results.
Public release and later
- Planned: open-source release and browser interface.
- Planned: integration kit for wallets.
- Under consideration: additional EVM networks. No token is planned or announced.
Documentation and transparency.
The information architecture is set. Full documents are not yet written, and are marked as such.
Documentation
- Concept overview: this page.
- Preview specification: draft outline below, full text unpublished.
- Integration guide: not started.
Technical architecture (proposed)
- Client: browser interface and wallet integration, no key access.
- Simulation service: forked EVM execution and state diff.
- Decoder: verified source and ABI resolution.
- Data: RPC provider; no custom contracts planned for the first release.
Security
No audit has been performed, because there is no code to audit. No verification badges are claimed. Planned principles: no custody, no key requests, read-only by default, open code, and a published disclosure process before release.
Legal
Terms of service and a privacy policy will be published before any product is released. The site currently has no analytics, no cookies, and no wallet connection.
Preview specification, draft outline
DraftWhat the first version of the preview format would define, taken from the examples on this page. Names and wording are not final.
- Input. The pending transaction as a wallet or dapp passes it, plus the network it targets. No keys, no signing.
- Outcome blocks, in a fixed order. Result, balance change, approval, call. Each block states what changes before how it happens.
- Approvals. Whether a permission is granted, to whom, for what amount, and whether it stays active after the transaction.
- Counterparty. The contract being called, and whether its source is verified.
- Limits. Every preview states what was simulated and against which state, and that the result can differ at inclusion.
Open questions: what counts as a verified source, how deep a provenance trace goes, and how simulation uncertainty is shown to the user.
Frequently asked questions
Is Reverseco live?
No. It is at concept stage. Treat any site, account, or token claiming to be Reverseco as unaffiliated.
Is Reverseco affiliated with Robinhood?
No. Reverseco is an independent concept. Robinhood Chain and USDG are named only as the intended network and the stablecoin used in examples. Robinhood and Paxos have not reviewed or endorsed this project.
Is there a token?
No token exists, and none has been announced.
Will Reverseco hold my funds or keys?
No. The design is non-custodial: it only reads and simulates, and signing stays in your wallet.
Can a simulation be wrong?
Yes. State can change between preview and inclusion, and some contracts behave differently under simulation. Accuracy limits will be documented.
Implemented and planned
| Item | Status |
|---|---|
| Project concept and brand identity | Implemented |
| Responsive informational website | Implemented |
| Preview specification | In development |
| Simulation engine, decoder, approval ledger, provenance trace | Planned |
| Smart contracts, wallet connection, onchain data | None. Not part of the first design |
| Security review, legal pages, social channels, documentation site | Not yet available |