So what *were* Oracles, as they related to SMTs?  They're really simple, actually.  They are bots that do evaluation of the chain, then enable the issue of tokens based on certain rules.

Sound familiar?  In some ways, that's what Scotbot does.  Scotbot is an Oracle.  It's not an SMT Oracle.  It's a Steem Engine Oracle.

Scotbot is *one kind* of Oracle.  It's an Oracle that looks at main-chain consensus data as well as side-chain, applies some formulas, then issues tokens.  It does this by mimicking consensus distribution, to some extent, and includes other parameters.

Scotbot has actually two sub-oracle: Scotbot PoB and Scotbot Mining.  PoB is focused on content while Mining is focused on distribution by staking companion tokens.

Usually, we talk about bots and not these fancy Oracles.  The reality is, they are pretty much the same thing.  "Bot" is more of a colloquialism from gaming and IRC while the term "Oracle" comes from computer science and business systems.

---

Back in 2018, Steemit, Inc. was working on a defining SMT based Oracles.  I was helping out with the specification to explore what the blockchain might need to implement in order to make this easier.

The problem to solve: *who gets tokens.*  It's all well and good to issue tokens strictly based on Proof of Brain.  But in addition to that, it'd be great to (optionally) indicate who qualifies before PoB is evaluated.  SMT Oracles link this process so the blockchain is aware of who qualifies.

Here's part of what was in the unpublished SMT Oracle whitepaper draft:

> Oracle-enhance SMTs leverage continually published whitelists of account names and apply them to the respective rewards pool to narrows down who is eligible to receive rewards of the respective SMT. This narrowing-down of accounts makes it possible for community-builders to ensure users are rewarded for very specific, desirable actions. Oracle-enhance SMTs rely on their elected oracles to publish reliable whitelists, and oracles may be incentivized by SMT emissions or their own business models to produce accurate whitelists.

You can see that there was a design emphasis on producing whitelists instead of blacklists.  This is because SMT Oracles were not intended to transfer rewards like Scotbot.  They were intended to inform the blockchain about who was qualified for rewards so that the rewards could then be issued by consensus.  Token emissions were intended to be handled by the particular SMT parameters.

Also part of the draft: *who is qualified to be an oracle?*  This is expressed by election for each oracle position.  An oracle operator who does a good job can continue to operate their position.  Bad oracles are fired.

Basically, if an SMT was created to have an Oracle, it issued no tokens unless a whitelist existed.  The blockchain cannot generate the whitelist itself, primarily because the information is entirely off-chain.  It all boiled down to the goal of SMT Oracles: *to verify facts about who will get rewards.*

Here are some examples of what an SMT Oracle would be able to do.  [You might remember the first one](https://steemit.com/steem/@nairadaddy/good-person-token-something-big-is-coming-from-steemit-inc):

> ### Steemit.com Good Person Token
> 
> In addition to STEEM, STEEM Power, and SBD, let's imagine that Steemit, Inc. also issues an additional token that rewards authors and curators for following the community guidelines.  Let's call this *hypothetical* token: `GPT`
> 
> Prior to this, members of the community are not incentivized to avoid certain behavior like politically motivated flagging or repetitive vacuous comments (spam).  When moderators see behavior that is approved of, these authors/curators are added to the whitelist.  If their behavior changes to become inappropriate, the are removed from the whitelist.
> 
> Authors and curators can continue to earn `GPT` by sticking to the general site guidelines.

I came up with this next one.  You can see here that in some ways, SMT Oracles could be used to offer a form of opt-in *KYC-ish*.  Not true KYC because the blockchain account name is the only thing that is broadcasted; no private customer information needed.

Anyway just because you went to an amusement park, in this example, doesn't mean you'd *have to* provide your blockchain identity.  But if you did, you get something in return:

> ### Wally's World
> 
> In this particular example, we're using the fictional Wally's World theme park from National Lampoon's Vacation.  We're assuming that the park operator has launched an SMT called WALLYTOKEN.  At token launch, they also created an oracle position, and provide the oracle updates themselves:
> 
> * Wally's World - Annual Pass Holders / California Residence
> 
> The advantage of this approach is that Walley's World owns and operates the related oracle.  The oracle position is fulfilled by an unpaid oracle because they themselves service the SMT directly.
> 
> When a pass is sold (either annual or day pass), they include the option for identifying the pass holder by Steem account name.  Thus, when they do a periodic update to the blockchain, they include the related pass holder accounts, which whitelists the pass-holder.
> 
> When the pass-holder posts articles to the Walley's World community, they are allowed to earn WALLYTOKEN for posting about their trips to the park and other Walley's World discussions.
> 
> Since most Annual Pass Holders are typically California Residence, they are also included this whitelist.  After a year, the Annual Pass Holders may be removed from the Annual Pass Holders database (off-chain) if they do not renew their annual pass, but remain in the whitelist as California Residence, if applicable.
> 
> Wally's World can also establish a 5-year policy for California Residence that must be renewed by either buying a new Annual Pass or day pass.  In this way, the oracle links off-chain data held by the Wally's World database into the blockchain to enable rewards for these pass-holders.

I also had another idea.  Again, just relaying a single fact to the blockchain:

> ### Yosemite Tokens
> 
> Imagine that the U.S. Department of Parks and Recreation decides to launch an SMT for Yosemite National Park.  The goal is to reward tokens to people who have actually visited Yosemite and blogged about their experience.
> 
> They set up the SMT called YOSEMITE and define an oracle position that publishes a whitelist containing the Steem account names of people who have attended the park and registered at one of the many campgrounds or visitor's center.
> 
> After their trip, they can participate in the community discussions about Yosemite.  They can post articles and photo-journals about their experience or discuss plans about when to visit again, all the while earning YOSEMITE tokens.

Another example that's just looking for off-chain facts so the blockchain can be made aware of them:

> ### Retweeted Token
> 
> The idea for this SMT is to connect behavior on Twitter with the token being offered.  Let's call this token RETWEET.  Authors in this community post articles and then share them on Twitter.
> 
> Over time, the total number of retweets they receive for all of the articles posted are added up and the RETWEET oracle adds them to a whitelist when they reach 50 retweets.
> 
> From then on, they are eligible to receive RETWEET rewards for future articles.

This one explores the idea of fully automating specific data collection sources:

> ### Runner's Club
> 
> The oracle for this *hypothetical* token could implement the Apple HealthKit API to periodically update a whitelist of accounts that opt-in.  When they meet the predetermined criteria (e.g. run 5 miles) as determined off-chain, the oracle will include them in the whitelist for that week.
> 
> If authors slack off during the week, they risk being dropped from the whitelist the next time the oracle updates the blockchain.
> 
> Staying on the whitelist allows authors to earn RUNNER token rewards for posting updates about their workouts.

---

We just want to verify facts maintained off-chain so that consensus can be made aware of those facts.  SMT Oracles would decide if you get certain tokens based on external data.  The actual token emission is still handled by the SMT parameters and consensus.

The question of who can verify the value being generated (and thus have a say in the ongoing validity of the token) is provided by the oracle operator.  There's also the notion of chaining oracles.  Do the Runner's Club intersect with Yosemite?  If so, there's no need to define that specific oracle.

In a sense, all of the above SMT Oracles are a type of tribe, although that terminology wasn't around back when SMT Oracles were being designed.  In theory, a Scotbot could be designed to only issue tokens based on a whitelist, in addition to all the other criteria it already uses.

<center><a href="https://xkcd.com/1782/"><img src="https://imgs.xkcd.com/comics/team_chat_2x.png" /></a><p><sup> 2078: He announces that he's finally making the jump from screen+irssi to tmux+weechat.</sup></p></center>

---

Original post about SMT ORacles by Steemit, Inc.: [Ned Scott and @theoretical of Steemit Explore Oracles on Steem](https://steemit.com/ned/@steemitblog/ned-scott-and-theoretical-of-steemit-explore-oracles-on-steem)