💳: rEGGEgg9hQSHLxUwycGnmjW2GKX9thn2yH
🧭
💳: rayZw5nJmueB5ps2bfL85aJgiKub7FsVYN
🧭
These graphs are generated from the CloudWatch Metric data pushed in the contract, the code that generates these images is in the metrics repo
🚧 Gaps indicate the oracle didn't reliably publish during this time see #27 🚧
This is a XRPL Oracle that publishes external data into the XRPL.
This Oracle was inspired by XRPL-Labs/XRPL-Persist-Price-Oracle. Also see the DEV post.
This Oracle is coded in python and built as a Serverless Application Model (SAM).
Take a look at the handler()
in contract.py
— where it's expected to run on any FaaS, such as OpenFaaS.
To deploy to your AWS Account use the aws-sam-cli
.
If you don't have aws-sam-cli
installed, you can grab it from pip or follow the
installation documentation.
pip install -U aws-sam-cli
After installing aws-sam-cli
, you can Build and Deploy.
# zip our function along with it's requirements from requirements.txt
# this also makes a new template pointing at those zips
sam build
# now it's built, you'll be prompted to deploy, do so interactively with:
sam deploy --guided
Don't feel like doing it yourself? Expand me to see termcasts.
- New stack, accepting all the defaults, besides the wallet secret.
- A current stack, getting updated and deployed to
This will walk you through the deployment of the Oracle, name the stack input
the parameters (the wallet seed parameter is
NoEcho
)
You may generate a Testnet wallet at the Testnet faucet: https://xrpl.org/xrp-testnet-faucet.html
Click "Generate Testnet Credentials" and use the Secret as
the input to the WalletSecret
parameter.
Besides the one required parameter without a default (the wallet secret seed), you can accept all the defaults (including the stack name) and you'll be persisting aggregate prices to the XRPL Testnet.
After deployment, you can tail the logs of the function like, where
my-stack-name
is what you chose to name your stack during the --guided
deploy, if you chose the default it's sam-app
:
sam logs --stack-name my-stack-name -n OracleFunction -t
The NoEcho
parameter of the wallet secret seed ensures that the parameter may
not be read or may not be logged during any cloudformation events.
The produced resource that !Ref
's the parameter in use, the function
with it's environment variable. Be aware that any other user able to access
the AWS account used to stand this stack will be able to read the secret on
the lambda function itself.
If you're in a trusted account, and don't provide access to tools or services that would have access to these things you'll be fine.
Otherwise, you'll have a couple options:
One option is to encrypt the Lambda environment vars in transit (they're encrypted at rest by default). This would then require decrypting it in the function using a KMS call. (see Securing Environment Variables)
Alternatively you might want to call some key management service / secrets management service independently. There is two other AWS services that you could use, for managing encrypted secrets in transit.
One is Simple Systems Manager (ssm
, specifically ssm-encrypted
parameter store type).
This includes some additional costs if the function needs to cold start (assuming you're
persisting the client in the outer scope for subsequent executions).
(see Sharing Secrets with AWS Lambda Using AWS Systems Manager Parameter Store)
You'll want to attach a policy to the function like in 5603945
include a policy attached to the OracleFunction
resource under the
Properties
dict.
Properties:
CodeUri: oracle/
Handler: contract.handler
Runtime: python3.8
Policies:
- SSMParameterReadPolicy:
# this should be a path you decide, here's an example:
ParameterName: xrpl-oracle/test/wallet/secret
# you can also use `!Sub`:
# ParameterName: !Sub "xrpl-oracle/${XRPLNodeEnvironment}/wallet/secret"
Another is Secrets Manager aws-secrets-manager
, which is also an additional cost.
(see secretsmanager_basics.py)
There are many options! This is just a minimal example :)