Search Across Six Hops (SASH)

Describe, forward, opt in, and confirm: the successful chain shares a Solana devnet reward.
Illustrative payout: finder-controlled fake hops do not increase the finder’s combined reward.
The prototype connects web and iMessage participation, Tiger Data analytics, and Solana devnet payouts.
Actual dashboard showing synthetic replay: 764 holders, up to eight hops. These are not live participant counts.

Inspiration

The person you need may be a friend of a friend, but you don't know their name, and a search engine can't tell you who to ask.

Inspired by Milgram's small-world experiment and Jon Kleinberg's research on navigating social networks, we built Search Across Six Hops (SASH) to turn "I know someone who knows someone" into a practical way to find people. Our idea was to reward the people who make a successful introduction while preventing the finder from earning more by inventing extra hops.

What it does

SASH is a friend-to-friend search with a reward attached. A poster describes someone through attributes such as city, field, skill, or experience. Each participant passes a personal link to up to three people they think are closer to the match, with chains capped at eight hops.

The matching person opts in by submitting an introduction. The poster reviews and accepts it before payment. Each intermediary in the successful chain receives a flat share, and the match receives the remainder. The poster takes no share.

Users can participate through the website or our Photon iMessage flow. A dashboard visualizes search cascades, tracks branching behavior, and includes an attack slider that demonstrates how fake hops affect different payout rules.

How we built it

We built the web application with Next.js, React, and TypeScript, and used D3.js to visualize the referral network.

Photon's Spectrum SDK powers the iMessage experience. Registered users can describe a search, choose its duration, receive a deposit address, fund it with Solana devnet SOL, and pass personal links to others. After the poster accepts an introduction, one Solana transaction pays the winning chain. Our prototype uses devnet tokens rather than real-money rewards.

Tiger Data stores search activity in a Timescale hypertable, with continuous aggregates supporting analytics. We loaded one million synthetic replay events to study cascade behavior and benchmark queries. PGlite supports local development and lifecycle testing.

We also implemented optional Gemini and Grok integrations for structured hint cards, generated link previews, and voice interaction. These remain feature-gated, with manual input and template previews available as fallbacks. Nessie escrow flows currently run in mock mode.

Challenges we ran into

Designing the reward mechanism was one of our biggest challenges. Paying people for introductions can encourage fabricated participants. Our split gives each intermediary a fixed share and the finder the remainder, so inserting fake hops does not increase the finder's combined payout.

We also had to connect messaging, deposits, personal links, introductions, and payment while keeping each action tied to the correct search and participant. Payment had to wait for explicit poster confirmation.

Messaging registration requirements, network restrictions, and API access added integration challenges. A local database and mock modes let us keep testing the complete flow while connecting external services.

Accomplishments that we're proud of

Completed funded iMessage searches with confirmed Solana devnet payouts to multiple participants.
Implemented and tested a reward split that gives the finder no additional combined payout from fake hops.
Built an interactive attack comparison that makes the incentive design easy to explore.
Loaded one million synthetic events into Tiger Data. Our recorded benchmark answered a selected replay query in 0.334 ms using a continuous aggregate, compared with 86.766 ms for the raw scan.
Connected a mobile website, iMessage conversations, event analytics, and multi-recipient payouts into one prototype.

What we learned

Navigation can mean finding a path through people's relationships and knowledge. Each person only needs to know someone who might be closer.

We learned that incentives and consent are central to that experience. Participants need to understand why they should help, the match needs to choose whether to introduce themselves, and the poster needs control over accepting the result.

We also learned how much a visual explanation helps. Watching the payout change, or stay unchanged, as fake hops are added makes the mechanism easier to understand than a formula alone.

What's next for Search Across Six Hops (SASH)

We want to test SASH with more consenting participants and measure where real searches succeed or stall. Those results will help us improve forwarding prompts, onboarding, and recovery when a conversation gets interrupted.

We also plan to finish validating the optional AI integrations, strengthen privacy checks, and evaluate the reward mechanism beyond synthetic replay and devnet demonstrations. Our next milestone is understanding whether rewarded introductions help people make useful connections in practice.